I’m glad (and relieved) to finally say UMW Blogs has been upgraded to the WP 3.0 merged core files without a hitch. Whew! This was a burner for me, a bit more fear and trembling going into this one than usual, but alas all is good in the UMW Blogs hood. In no small part thanks to Ron Rennick who recently upgraded his SharDB plugin to 3.0.1, which did the trick in terms of making sure all was smooth with the multiple-database setup upgrade. You rule Ron!
As for the rest, it was pretty standard, and only one pretty minor hiccup in regards to the Atalhuapa theme which I will outline below (and the fix below comes care of the inestimable Luke Waltzer).
Basics before upgrade
You know the drill by now: Always back up all files and the database (or in my case databases), and make sure not to copy over wp-config.php as well as the wp-content directory.
OK, done with disclaimers, now for some preliminary steps before copying over the WP 3.0.1 core files, make sure you
delete the wp-content/blogs.php file for those upgrading from WPMu (which is whom this tutorial is for).
You will also need to change the .htaccess file, particularly the line pointing to wp-content/blogs.php, which now needs to point to: wp-includes/ms-files.php
This line in our .htaccess file now looks like this:
RewriteRule ^(.*/)?files/(.*) wp-includes/ms-files.php?file=$2 [L]
You should also delete your wpmu-settings.php file located in the root install directory.
If you are like me and you are using SharDB to spread your sites/blogs across several databases, you need to update to Ron’s Rennick’s latest version of SharDB.
And where ever Ron is, Andrea is not far behind (or is that vice versa?). In order to ensure that all the blogs using the default theme (which was Kubrick) are changed to TwentyTen, include the following call in your wp-config.php file (a tip you can find thanks to Andrea here):
Our default theme define in the wp-config.php file looks like this:
And to contextualize this a bit more, we changed the twentyten theme folder name to default, and moved the old default theme files for Kubrick into a folder called Kubrick for any of the faithful who still want to pursue it (be sure to make it available in Super Admin). Now, all sites on UMW Blogs that once had the default Kubrick theme now have TwentyTen automatically–which also means Menus will work for all those sites, and there are a good number.
Finally, I was sure to upgrade DSader’s More Privacy Options plugin before upgrading given it was throwing errors in the bavatuesdays WP 3.0 setup, I keep the new version of this plugin in the wp-content/mu-plugins directory.
The Actual Upgrade
Now run the upgrade by simply copying all the core files and directories, except wp-content and wp-config.php, into your WordPress install.
After that, go to http://yourinstall.com/wp-admin/upgrade.php and upgrade the database, cross your fingers!
If that works, go to Super Admin–> Update and updates all the individual blogs, this will take a while if you have a lot.
Finally, in the Dashboard you’ll be asked to add a Nonce Salt to your wp-config.php file. Something like:
define( ‘NONCE_SALT’, ‘yoursuppersecretkey’ ); to your wp-config.php file
The Ongoing Aftermath
The upgrade should then be done, but there may be some cleanup. For example, Luke Waltzer pointed me to this fix If you were using Ataluapa in WPMu, you’ll find none of your customized header images in Ataluapa are there, it returns to the default. This is because the theme is looking for the file wpmu-settings.php (now deprecated) instead of wp-settings.php. A quick find and replace of wpmu-settings with wp-settings on the following three files in the Atalhuapa theme did the trick for me:
And, that’s about it thus far, it was all rather smooth in the end. Though I am sure many more issues will emerge over time, I’m sure they will prove resolvable and I am quite relieved—especially given 3 sites within sites (what would now be called multi-networks?) http://greenwoodlibrary.org, http://facultyacademy.org, and http://hamptondigitalhumanities.org all survived unharmed. Saying that, I was also relieved to see that mapped domains were also left intact.
And what’s more, Ken Newquist at Lafayette College sent out the following email to the wp-edu mailing list, and it provides an excellent list of issues and updates on their road to an upgrade to WP 3.0. I’ll reproduce it in it’s entirety below, and it is very good to know new activations of Next-Gen Gallery may have issues:
Back in June there was some talk about WordPress 3.0 and its compatibility (or lack there of) with popular plugins and themes. We’ve recently upgraded our production instances of WordPress to 3.0, and I thought I’d give a rundown of the the problems we encountered.
==More Privacy Options==
The plugin continues to work, but it generates a PHP fatal error when you edit a site’s properties as an admin, making it impossible to save configuration changes. The latest version of the plugin fixes this problem.
==nextGen Gallery: Ignoring MultiSite directory options==
nextGen Gallery has issues with WordPress 3.0 multisite. While existing installations are working ok, folks who add the plugin after the upgrade get this error message:
“Directory wp-content/gallery/ didn’t exist. Please create first the main gallery folder !”
The problem is that Blog Directory Path, which is a network-wide option set under the super admin menu, is no longer being respected at the per site level by nextGen. If you manually set the site’s directory path using the site’s ID (available from the main site directory list in the super admin view), then things work properly, but the default setting is now incorrect.
The plugin author is aware of the problem, and is working on this and other MultiSite-specific issues for the next release.
==nextGen Gallery: Slideshow links don’t work on a static home page==
If you insert a nextGen Gallery into a page, and then make that page your home page, the link to the slideshow will not work.
==Anarchy Media Player==
Anarchy’s settings page no longer loads under WordPress 3.0.
The Mandigo setting page doesn’t load if you’re using Mandigo 1.40.1. It works properly with the current version.
==Mandigo + nextGen + WordPress 3.0==
That’s about it, and I’ll be sure to blog any and all issues, problems, or fixes we come across, and I am sure there will be more than a few. In fact, I have to do this fix for Userthemes, thank you Boone.
Yeah, we’re pretty much a unit. 🙂
tip: you could leave twentyten where it is and put ‘twentyten’ in that config line so it’s the default. 😀
Thanks to the unit again, and I got a bit confused with the define default theme, so just decided to put twentyten in the default directory to keep in clean in my head. Love that every blog starts with TwentyTen, on eof the true benefits of this upgrade.
Thanks for posting this!
Jim, thanks for the play-by-play. I’m in the middle of updating UCalgaryBlogs to WP3.
The one change I made from your list was the wpmu-settings.php file – I moved the existing file out of the way, then created a symbolic link to replace it, pointing to wp-settings.php, like this (if formatting holds…):
`ln -s wp-settings.php wpmu-settings.php`
And from what I know already on twitter it was a success. I a digging WP 3.0 so far, and have had very little in terms of bugs or problems. Google Sitemap seems to have some issues with multi-site, as does Role Scoper, but otherwise it has been beautiful, and neither of those plugins are deal breakers by any means.
And did I tell you I love custom menus? We just need to add tags to the mix I mean why not?
Fantastic play-by-play, I am tweeting this so I can find it when I am ready to make the jump. Thanks for this!
Pingback: links for 2010-08-13 | Aram on Mason
Thanks for this, Jimmy. Just used this as I upgraded six different blogs. Much appreciated.
Thanks for the tip on mandigo/next gen challenge. That’s been bugging me for a long time.
Regarding Mandigo’s theme options page, I discovered that the problem wasn’t fixed in 1.42 — instead, what was happening was that I, as a superadmin, could see the theme options page, but regular admins could not.
The short answer as to why this was happening is that Mandigo (and many other themes) uses the capability “edit_themes” to decided whether or not to display the theme options logic. But under WordPress MultiSite, only the superadmin has that capability; regular administrators don’t (because “edit_theme” actually refers to being able to edit the underling theme files through WP, NOT the theme options).
See this thread for a discussion of the capability: http://wordpress.org/support/topic/capability-manage_options-vs-edit_themes
The fix was to change the theme logic to use “edit_theme_options”, which regular administrators do have.
I alerted the Mandigo author to this, and he’s going to roll the fix into an upcoming release. Be aware though that many other themes have this same logic in them, including Inove, PrimePress, Regulas, Tarski and Viala. Hopefully they’ll be updated to the new logic soon (if they haven’t already) but the fix is the same regardless.