WordPress MU

Hello guys,
I tried to upgrade to the newest nightly but there is an error when I uploaded all files.
Then I called my Blogdomain and this errors appeared.

"It doesn't look like you've installed WP yet. Try running install.php."

What can I do to upgrade to the newest nightly?
I hope you will help me :)

Hi Yoshi,
I just upgraded to the 06-05-18 build (that's today!) and it mangled my previous installation. w00t! more fun with unstable softs !
I found that the latest build requires it be installed in the root of the domain (i.e. your webserver's root folder, the default in freebsd is: /usr/local/www/data/ ) this will allow things to proceed normally, thought I'm having a few problems with options not being set (perms error?) but bugsquashing is fun!

Hi swayze,

at first thanks for your answer.
My installation of wordpress-mu is in my root folder.
At Suse 9.3 with Plesk 8 it's "/var/www/vhosts/domainname/httpdocs" and the files of the archive are uploaded there.
My question is now, is it possible to upgrade to the newest nightly without loosing my eisting Blogs?
When I try to run the install.php nothing happens!
It would be much comfortable to upgrade trough an update.php like other scripts.
Can you post a tutorial how to upgrade successfully, because I think not everybody who uses wordpress-mu can code own php-files to fix this errors.
I hope for your help and sorry for my bad english :)

Yoshi,
Your english is far superior to what I'd be able to accomplish in your native tongue so please don't apologize, you're already well ahead of me.
I've only recently been using MU (April build) as it makes sense to me to have only one engine for multiple blogs in that they're all functionally the same (similar)
My installation went terribly so I'm perhaps not the best person to write a tutorial on upgrading as it didn't work well for me. I believe that the best info would be to thoroughly read the changelog and see what's what.

To upgrade is basically to check the change log and overwrite all the files changed. Then run upgrade.php.

This is from what I know. :)

I've tried to upgrade, but after that all Blogs are not reachable it shows me an 404 error within the standart Wordpress Design.

FWIW, here's how I upgrade WordPress MU (and some other piece of software):

- i use two different directories and two apache vhosts to manage both production and development versions of wpmu,
- all my websites live in /usr/local/www/sites/ under the name <service>.domain.tld, so in that case I have blogs.domain.tld and blogs-beta.domain.tld. Those are just symbolic links to actual wpmu directories (extracted snapshots, like wpmu-2006-xx-xx),
- get a list of files you need to keep absolutely when you want to upgrade (plugins, themes, configuration files, .htaccess files, ...) and write a simple shell script to make a backup (tar cfvz blogs-backup.tgz ${files}),
- at a certain time, you should at least have blogs.domain.tld pointing to a working wpmu installation, do the following:
- run the backup script,
- extract the development snapshot,
- do a ln -s wpmu-2006-xx-xx blogs-beta.domain.tld, to create a symlink for the development version,
- drop development database with mysqladmin -u sqluser -p drop wordpressdb
- dump production database mysqldump -u sqluser -p wordpressdb > dump
- do some sed magic (eg. sed -i"" -e 's/blogs/blogs-beta/g' dump),
- import the modified dump with mysql -u sqluser -p wordpressdb < dump
- restore the backup in the development wpmu directory (eg. tar xfvz blogs-backup.tgz -C blogs-beta.domain.tld).
- adjust wp-config.php in the development version to use the development database rather than the production one,
- make sure permissions are correct (especially wp-config.php shouldn't be readable by non-owner or non-www account)
- at this point you should have a working blogs-beta.domain.tld
- test thoroughly
- once you made sure it worked, restore the production wp-config.php in blogs-beta.domain.tld/wp-inst/, remove the blogs.domain.tld symlink and create a new one with ln -s wpmu-2006-xx-xx blogs.domain.tld
- you're done!

I think I didn't forget anything. You can include the database dump in the backup as well, run the backup script at regular intervals, and send the backup archive to another box or just copy the archive to another hard drive, just to make sure you can recover your data in case the hard drive dies.