BobS

Yow! It's one thing to change an app on-the-fly (like WordPress and others), but quite a bit more to upgrade the server set on which the app is running. Sort of like changing tractors on a moving semi-trailer. Normally I install a new UniServer and move all my apps over, as you mention. I have been able to upgrade some of my test sites by setting up the new version as a parallel US (rename the old one to keep it from being trashed) and then move the new files to the old one. Example: 1. Rename old UniServer to UniOld, and make a copy as UniSave. 2. Install new Uniserver. Rename it to UniNew. 3. Rename UniOld to UniServer. 3. Move the contents of UniNew over UniServer. This effectively updates all the servers, but trashes some of the config info. The MySQL data will survive. Don't know abut mssql. 4. Use UniSave contents to tailor/restore the specific config files needed. 5. Fire it up and see what's broken. REMEMBER, this is the quick and dirty way, so if it doesn't work be sure you can get back to the old UniServer contents. It's still more reliable to move your apps to the new UniServer. The process is almost like above, but you copy ONLY the apps and MySQL data files, not the whole tree. Good Luck, BobS

Which version of IE are you using (6,7,8)? What kind of jumbling happens? This may be from "interpreting" the HTML requests and mucking up the packets (wild guess). Regarding caching, this is dependent on Apache. I suggest you Google: "apache reverse proxy" and check out some of the results for more information. I saw lots of good material, and I suspect you'll have your answers there. After that, if you find some specific problem with the Mini's configuration, we can probably help more. Regards, BobS

Specifically, ALL PHP-handled date/time constructs depend on the timezone setting in php.ini. Since Ric lives in Cambridge, UK, he sets the file's default timezone to "Europe/London" (which is UTC 0). For 4.5 Mona, look in C:\UniServer\udrive\usr\local\php\php.ini and search for "[date]". Change the setting to reflect where you are, and the time will work correctly. Regards, BobS

If you're on XP, you should apply SP3 (and the 60+ additional fixes) to keep your box secure. The type of error you're getting is not a problem specific to Apache or Uniform Server. Regards, BobS

Just a stab in the dark, but do I see a reference to MySQL4 in the dump? Since US 5.x uses MySQL 5, could it be that the problem is you're using code meant for MySQL 4 instead of MySQL 5? Regards, BobS

I suggest you look at the 5.6 series, which is more likely to have what you want. Check out this Wiki page for a summary of features in chart format: http://wiki.uniformserver.com/index.php/5....o:_Introduction Regards, BobS

Sure. [Adding this answer for others to reference.] Make sure the servers (Apache and MySQL) are stopped and just DELETE the UniServer directory. There's no junk left in the registry or any other directories. Regards, BobS

It might be that the SAME problems with Windows 7 apply to WS 2008, since they share the same code base. Specifically, this would apply to "localhost" being IPv6, which messes up MySQL's connection. However, not having access to WS 2008, it's hard for me to troubleshoot this particular Unitray problem. Sorry, Bob

Just as you said: totally wrong Firebird is a database engine, like MySQL and others, and it has its good points. Quoting from the site (http://www.firebirdsql.org/): "Firebird is a relational database offering many ANSI SQL standard features that runs on Linux, Windows, and a variety of Unix platforms. Firebird offers excellent concurrency, high performance, and powerful language support for stored procedures and triggers. It has been used in production systems, under a variety of names, since 1981." NOTE!!! The instructions for Firebird shown above are two years old. I personally haven't tested any of it, and Ric has been otherwise engaged (like, with MongoDB). The main site shows that version 2.5 has been release, and appears to be MUCH faster for large DBs. We're talking >20GB here. All-in-all, Uniform Server is a pretty good base for testing, but sliding in new DB engines is outside the norm for most users. Hope that gives some background. Regards, BobS

Thanks for the info! It's this kind of note that helps all of us. Regards, BobS

Sorry?? The question isn't clear. IIS is not part of Uniform Server. In fact, if you want to use them both, you need to be sure that IIS and UniServer don't use the same ports. I believe you'll find more information about this by searching the Internet. We'd need to have more explanation of what you're trying to do in order to give more direction. Bob

It appears to me that the most secure solution is to remove apanel when you put your UniServer in production. I'm not sure that changing the passwords alone will resolve XSS in this particular case, but I consider it a "must do" before I would expose UniServer to the Internet. Since the password is acted on via Apache, is that sufficient to thwart the threat? Until I know more about if and how a XSS could circumvent a password, I'd use Ric's solution an blast the apanel directory. The real question is whether the CVE report took into account the requirement for password changes, or just assumed that people would run it as-is. Bob

I commiserate with you on this. I suggest using the 8.3-style names which should work for this; it's worth a try. Instead of "c:/program files" use "c:/PROGRA~1" (I assume you're on a 32-bit system). This has been known to work in other environments where spaces weren't allowed. So now you have two solutions to try Good luck, and PLEASE post back if either solution works. Bob

Your image shows that you're putting this into "My Documents" (or its actual location), which is really not a good choice for a server program. The best choice is to put it directly on the root, C:\. "I know I have just to change location and continue testing but, from the beginning, I don't like that kind of restrictions (specially if I already have a version that doesn't have them). I'm making a web for a friend who doesn't have any idea of how it works computers world in general xD, so I want to make things as easy as possible in order to send the web and execute it with the less steps as possible." Been there, done that. I assume that want you want to do is to just upload via FTP directly from the www directory. If it requires parts from the database, you'll have to provide a procedure for that, too. I found that the more changes I made base on assuming my client was "too dumb," the more my support problems increased. The best solution was to install as straightforward as possible, which translates to "easy." Buena suerte, Bob

Maybe the BEST thing is to be sure what we're talking about. Let's go back to basics. 404 errors happen because something doesn't exist where it's expected. When you added wordpress, where did it go? Is it in C:\uniserver\www\wordpress\ or similar (where it should be)? Or is it somewhere else? If you have C:\uniserver\www\wordpress\wordpress\ that will get you a 404. Secondly, you don't have to preconfigure the wp-config.php file. In fact, WordPress will do that for you. If WordPress is actually in the right place, and there isn't a wp-config.php, WordPress will prompt you with a script to create it. My guess is that you have it in the wrong location. Bob

Of course, if you changed the MySQL password, this must be reflected in your DB params for Drupal. That even applies to the Drupal plugin. But there's another thing to check: Since you're using Vista, does your localhost come back with an IPv6 address? See the Wiki for more info on this topic. Bob

The most likely answer to this problem was that you had installed the servers as services, and hadn't removed them using the UniTray. This could have been verified by looking at the services, or by checking in the task manager. I would hope that you cleaned up your registry after the manual deletes. Bob

Thanks for the tip, but let's get it RIGHT next time! phpMyBackup has been discontinued in favor of phpMyBackupPro, which is at: http://sourceforge.net/projects/phpmybackup/ Note that the link has NO caps. As Ric has pointed out, it hasn't been updated for a loooong while (>3 years). Bob

"Note: New menu and servers work perfectly on XP-Home. Carbo really does require a thorough workout on other Windows OS’s " I have good news and bad news.... Haven't had any problems with XP, but under Win 7, the status-check doesn't work at all (and therefore the service indications and uninstalls all fail). If I get a chance later, I'll attempt to debug why. I'm not currently set up to do that, so it may be a while in coming. There's a good chance that the problem stems from UAC (which is turned on), but I don't get any prompts. Just conjecture.

Most all applications consist of two main segments that need to be transferred. These are the database and the app directory. The most reliable database transfer is from a phpMyAdmin backup, which will include all the commands to create the database tables and populate them. Key problems will be resolved in php.ini for time and memory limits on importing the data with phpMyAdmin. Be sure the limits are high enough to cover your import. The app directory includes all the content in the Joomla directory (unless you put it in the server base, like public_html). You can use a backup from cPanel and 7Zip to extract a copy to www. If you have it in the base, you'll need to select all the appropriate files and directories manually. I have done this operation for a few live Joomla sites. The main problems I encountered were with *ix-to-Win path changes required for plugins. Can't remember if Joomla core required changes. Hope that helps.

I have used the V56_Wordpress_2_9_2.exe plugin, and then kicked off the autoupdate to 3.0. Works great! That plugin was created 30 March 2010, not so very long ago. Bob

First of all, what version of UniServer is giving you this problem? Second, you say there is another version on your system? What are the path names for each instance? As a general comment, if the .htaccess file in www is not set right, you will get a 403 error. A solution may be to change the "Allow from 127.0.0.1" to "Allow from 127.0.0.1 192.168", which will allow other systems on your LAN to access the server. It also will allow you to use the name of the machine, such as "http://mymach". Bob

On the other hand, it seems that the base is just fine. It's the UniTray 2 that's the actual "beta" material. I've had a chance (finally) to install and test it. My system is Win7-64, so it doesn't respond like XP. I feel that we need to look at this as our primary focus for new development. That said, here's what I found: Unitray 2 isn't nearly ready for use. While I believe it's an interesting, and perhaps correct, direction for development, my biggest problem was that the icons didn't indicate the status of the servers, and the menu didn't change to allow the servers to be stopped. I haven't yet had a chance to check if this is only because I'm on Win7. I also have a few VMs that I will load this on to test in the next week. This seems to be resolved now; as usual, it's probably because I finally rebooted. I guess I'll go through the items one-by-one and verify their operation. So, Ric, don't think your efforts are in vain. I applaud your work, and hope you are blessed with abundant patience. Most people steer clear of betas because they just want what's working right now. Series 5-Nano is just fine for them. That leaves a very small group that would even want to play with a beta, so I wouldn't expect a quick response. Bob

Instead of using "localhost", put in "127.0.0.1" for the dbhost. See refs to Windows 7 and MySQL.

It's true! Even the copyright says 2007, so how would anyone REALLY know at first glace the TON of work that went into versions 4 and 5. Maybe you could get a link from the wiki news to the front page? (Ooops, need to update that, too. Actually, I just did). But seriously, the home page has to give an indication of changes, if only to toot the horn. Regards, BobS