BobS

Love those help files. Too bad no one reads them first... Regards, BobS

Well, I was intrigued as to what this looked like, so I downloaded the package and put in on one of my various instances of The Uniform Server, specifically Coral_8.5.2. I created a subdirectory called rssps and unpacked the code into this. I then started the Apache server and navigated to http://localhost/rssps . The RSS code worked perfectly without my doing anything. Remember, this code is six years old, so if there were bugs, I think they would have shown up now. I then copied the same subdirectory to two other server versions: Coral_8.1.2 and Nano_5.5. Not surprisingly, both worked perfectly. The NEXT step was for me to look over the code. I found the variable "$allowdDomains" in scrollerbridge.php (line 34), with the explanation on the preceding lines. Did you put anything in this variable?? For that matter, did you change anything in the package? I suggest you start from scratch and get the demo working before changing anything. Regards, BobS

There's a specific control for this. Server Configuration>General>Root phpMyAdmin - Change access type There are three modes: Local (default) Intranet + passwords Internet + passwords + ssl This means you MUST enable ssl to use this feature via the Internet. We're actually concerned about your online safety Regards, BobS

I guess we all need to realize that every machine is really unique after it's been used a while. Regards, BobS

access.log catches all the non-domain-specific traffic. I believe it may be possible to restrict access to just your domain-specific account, but I'd have to work out how to block the rest of the traffic. I don't know if using a .htaccess file is sufficient, since it would use the IP address. Someone else may know more about how to do this than I. In the meantime, you'll just have to deal with all that toxic traffic. Regards, BobS

Fantastic! Glad that resolved it. Now you can upgrade to Coral_8.5.2 (or wait until 8.5.3) Regards, BobS

Best bet: Use Coral_8.1.2 Much less hassle and will work properly. Regards, BobS

Ric, I see that OpenSSL has been updated to 1.0.1, not 1.0.0e. Regards, BobS

The main reason I suggest Coral_8.1.2 over Coral_8.5.1 is that the latter has two new component releases: Apache 2.4 and PHP 5.4, both of which may pose compatibility problems for your application. Please note that getting a WAMP running and getting it running securely are two different (but connected) matters. Be sure to check out Yoni's articles on securing your server. There area also several other threads on performance and security you should check. Regards, BobS

SEE the UPDATE BELOW. Check out 8.1.2. I've been using it successfully on my Win7-64 system. It uses Apache 2.2 and PHP 5.3. These should give you the least problems. Regards, BobS

A wild guess is this has nothing to do with Apache. However, there are too may factors and too little info to verify this. You may be seeing the result of buffers filling and "buffer bloat." Again, no way for me to be sure. Regards, BobS

I thought 127 was rather suspect!. Thanks, psinnot! Since the Listen directive CAN have both IP and port, your code change may be important. OTOH, using Listen 127.0.0.1:80 will restrict the server to requests ONLY from the localhost, which may be confusing if, for example, you want to allow intranet access (from 192.168.x.x). There are other features that RELY on the Listen directive specifying ONLY the port. huw, it seems that you have used Listen 127.0.0.1:80 Don't do that! Change it to Listen 80 ALSO, while it is permissible to have more than one Listen directive in the httpd.conf, The Uniform Server support code assumes there will ONLY be one. Let's say you have set your main server for port 83 (Listen 83). That should be the only line. If you have two Listen directives, which should be the primary? Other ports can be specified for vhosts, but that's a separate matter. Regards, BobS

These are two totally separate blogs. If you want to put the contents of blog A (on WprdPress.com) into blog B (local), you need to do one of two things. First choice is to use tools>export and import from within WordPress. You'll have to install and activate the import plugin on your local blog. This worked just fine for me, and I'll be using this method from now on. Second choice is to copy and paste individual posts using the post editors of each blog. It's tedious and you're bound to forget some small detail in this process, but it does work. Since there's not an option to get a database dump, we won't even go there. Regards, BobS

Well, I have the same problem, which is interesting because the config.inc.php file for phpmyadmin shows a leading backslash. AHA! There was a code change that must have introduced this bug. Coral_8.1.2 does NOT have the problem. Regards, BobS

Total agreement! We're still busy with all the other problems. Regards, BobS

Did you look at the HOSTS file? If you used the vhosts setup in Coral, this will add an entry corresponding to your domain name that resolves to 127.0.0.1 . It's a feature, not a bug. This is created for TESTING your setup without requiring a domain change. It's just one more thing to remember when setting up for production. Regards, BobS

As I see it, WHMCS is used for managing web hosting accounts. In the grand scheme of things, I fail to see where The Uniform Server would apply. I would expect that WHMCS would be put directly on a Linux host along with cPanel, not on a Windows-based production environment. I'm just rather confused as to why you are using this with The Uniform Server. Leaving that aside, I'm sure that the version of WHMCS you have (which you failed to specify) is restrained to a particular version of PHP. This is apparently older than PHP 5.3. My advice is to download an older version of The Uniform Server that has the PHP version matched to what your WHMCS version requires. The other alternative is to get a more current copy of WHMCS or request their support on this issue. Regards, BobS

Very likely you will. Note this: It's likely that you have to install the Visual C 32 bit libs as well. Check out all the different libs I have on my Win7 64 bit system, courtesy of Microsoft: Regards, BobS

A very engaging and instructive story. Just think how much longer this could have gone on if you hadn't changed the schedule. Because of the connection to the backup, I assume that you want some explanation of how the db_backup could zap the SCO Unix system (even though you're not still using it). However, without seeing just what your backup and cron config contained (not to mention all the other aspects of the offending machine), I don't have enough info to hazard a guess. I see nothing in the default settings that would send anything to another machine. Regards, BobS

Note that what this does is to make your Joomla content the only content for the site, which may be just what you want. This is typically what's desired. Your users type in http://mysite.org and that goes directly to the www directory. The www/index.php file gets executed and they're into the content. Other possibilities include vhosts and subdirectories, like http://mysite.org/online where that subdirectory has the content they want. Note that there are more security considerations if you have subdirectories, since that implies there are other subs for other users.... Regards, BobS

Note 2, concerning APC. It may not be ready for prime-time in version PHP 5.4.0, so it wasn't included in the core package. HOWEVER, the "current" version, which is touted to work with PHPH 5.1 and up, is available in PEAR. See Pecl: http://pecl.php.net/package/APC/3.1.9 NOTE that the PEAR interface comes back with: Hopefully that works. Now, whether or not APC ACTUALLY WORKS with PHP 5.4.0 is still to be determined. I ran across a ref to PHP 5.4 and APC which gives a brief summary of what's up: http://www.phpclasses.org/blog/post/173-PH...HP-Version.html BTW, this blog also has more posts about the status of PHP, probably more detail than you need/want to know. Regards, BobS

So here's a note about eAccelerator. It seems the project is basically dead. The main site(http://eaccelerator.net) shows a server test page. If you use https://eaccelerator.net, it shows an expired certificate warning. If you put in an exception, yo can get to the TracWiki for eAccelerator. Whoopie. They show links to download eAccelerator version 0.9.6.1 from 2010/05/31, but the actual download link is broken. You get "De opgevraagde pagina werd niet gevonden." Same for the SVN link. If you search on Sourceforge.net, you can get version 0.9.6.1. But note that this was last fixed to work with with PHP 5.3. So for PHP 5.4, we can essentially kiss this off. Regards, BobS

When I read the release announcement, I noticed that it stated that BOTH APC and eAccelerator were NOT included, "to be added later" (I just went back and highlighted that). And traxxus, while your image is missing the all-important "X" in the box, showing that neither of the accelerators is active, the control panel only shows the status of the php.ini directive. The basis of the problem is that the dlls are simply missing. So I would say that you'll have to wait for a "more perfectly-formed" release from Ric. Maybe Coral_8.5.0 should have been labeled BETA. Regards, BobS

Yeah, we know. The PEAR folks moved their repository, breaking this installation method, which the also say won't be fixed. Coral series has PEAR preinstalled for just this reason. For all others, there's an alternate method, which you must perform from a command prompt. See this post: http://forum.uniformserver.com/index.php?s...post&p=9818 While it's set for Coral, it solves the same basic problem. You'll have to adjust for the differences between 7-Orion and 8-Coral. Regards, BobS

First off, thanks for pointing out the error on line 48 of disk_start_stop.vbs. Second, I found that the servers start properly using "run_on_drive_w.bat" without any changes. Running "remove_drive_w.bat" worked correctly as well. I copied them to the UniServer directory as specified in the instructions. I also didn't need to do any editing of httpd:conf. Using disk_start_stop.vbs appears to work properly as well, except that I found it sometimes leaves mshta.exe running. The likely problem is that when removing the virtual drive, the mshta.exe is left in limbo, and doesn't terminate, which causes any subsequent scripts to not work. I don't know of a workaround for this, except to use the Task Manager to kill it off. Note that the server path (W:\ in this case) is tracked in uni_con\config_tracker.ini and MUST match all the path statements. If it's out of sync, you end up wit a broken server stack. So editing the httpd.conf to change the paths was probably not a good idea.... Regards, BobS