WordPress MU 2.9.2 has just been released and is mostly a security and bugfix release based on WordPress 2.9.2. Grab it from the download page.
As well as the security fix mentioned above, this version also fixes a few bugs, makes the blog signup process much faster and adds a new “Global Terms” Site Admin page.
The “Global Terms” page is one I should have added years ago. Currently it’s fairly bare, but hopefully in future versions of WordPress it will be expanded. It allows the Site Admin to “fix” the terms (tags and categories) used in MU blogs. These terms are normally synced with the “sitecategories” table but sometimes they go astray. This can happen if you “import” a blog using PHPMyAdmin without going through the WordPress importer, or if a plugin manipulates the terms table directly.
WordPress MU forces the “slug” used by terms to be a sanitized version of the “name”, which isn’t the case in WordPress. This page can optionally rename the terms so they match the slug. It doesn’t do the opposite because that would break public facing URLs on the site. (I must extend a big thank you to Deanna for helping debug that page)
Enjoy!
Today is the first I installed MU,
and now there are updates, I’m lucky ~~ =)
Are there any issues with the update and the current version of BuddyPress?
Nobody has reported any, but it was released only an hour or two ago.
I’m getting a lot of people already using WordPressMU asking how the merger is going to impact them. Will they have to upgrade to the new WordPress or will an MU specific branch still be supported? It’d be nice to have a post explaining the difference and the process for MU moving to the new WordPress/MU merger.
Thanks!
I have upgraded to the new version, but I had just installed 2.9.1 yesterday. I installed it in the root directory at http://www.lensflarelive.com. No matter WHAT I do (including downloading and installing buddypress) I cannot get any themes to show. Not on the main site, or on a second blog that I created (jackhollingsworth.lensflarelive.com). I’m pretty much at a loss, since I’m running about 14 other wordpress sites. This is my first MU installation, and I can’t figure this one out!
You need to activate them on the site admin themes page first.
@Lorelle – This is 2.9.2… the merger is at 3…
when v3 comes out, keep an eye on the big ones like edublogs. see how they fair. You can always just NOT upgrade for a time..
-Erik
I did activate them first… Have gone back and forth – activating different ones, then trying to activate one on the child blog – no luck!
Is there any reason why there ist no release-tag 2.9.2 in svn yet? Are there any changes to svn? Probably there will be from 3.0?
I forgot, I’ll get around to it later but there won’t be any changes to the 2.9 branch before I do.
It keeps showing the message “new themes should be activated in the Themes Admin” even though they are activated. The thumbnails do not show up on the themes page of the main blog, nor the child that was created. The info does, but not the images.
tnx for keeping it updated 😀
Donncha – I solved the problem. I was reading through your blog and one of your postings WAY back talked about file permissions in the themes directory. You had them all at 444 for some reason and they should have been 644. However, all mine were fine! But the FOLDER permission for the wp-content directory was not. When I fixed that, everything worked! Well…at least I can see the themes 🙂 Thanks for your help!
WordPress MU 2.9.2 リリース。
http://ocaoimh.ie/wordpress-mu-292/
Holy heck, it looks like something relating to cron jobs got fixed in our upgrade from 2.9.1! This may simply be isolated to our install, but upon upgrading, our CPU load went to about 40 on a 2 cpu dedicated while wp-cron updated what appears to be cron related activities that were queued or otherwise neglected.
These activities ranged from plugin activities and routines, to a flood of pingbacks and even wp super cache updated a bunch of garbage collection activities that had been neglected all began dated as soon as we upgraded. After about 20 minutes everything settled down and load went back to normal…. just a heads up in case anyone else’s server load goes into overdrive, once wp-cron does it’s work, everything will be back to normal!
Trace, I’m pretty sure that would have been caused by this change:
http://trac.mu.wordpress.org/changeset/2065/
There was a bug with WordPress v2.9 which broke WP cron on some setups (see http://wordpress.org/development/2010/01/wordpress-2-9-1/).
This bug was fixed in WordPress 2.9.1.
However WPMU 2.9.1 (and 2.9.1.1) didn’t include this change.
So I suspect your WPMU setup has had a broken cron since upgrading to WPMU 2.9.1 (and 2.9.1.1).
This would have caused a back log of cron jobs that hadn’t been run.
WPMU 2.9.2 fixes this cron issue (see the above changeset), so after upgrading your back log of cron jobs would have been executed.
Good work – I’ve been running it without a hitch since last night.
Just a note in favor of using a version control system and staging area to mitigate problems like the one Dave mentioned above:
We have a wpmu staging area that’s also the working directory of a mercurial hg repository. We also use a custom theme in the themes/default/ folder. When we upgraded to 2.9.2 yesterday, our customized, default theme was replaced with the WordPress default theme. All of a sudden, all of our blogs had lost all of their customizations and were using the default WordPress theme.
No big deal. Since we performed the update on our staging installation first, nobody outside of our staff saw the problem, and since the staging area is a mercurial working directory, it took us about a minute to revert to WPMU 2.9.1, giving all of our blogs the correct appearance again immediately. We figured out the source of the problem, came up with a solution for it, and had WPMU 2.9.2 installed again within a matter of minutes, this time with our custom theme correctly in the default folder.
Had we not used a staging area, the problem would have been visible to the world. Had we not used a version control system, it would have taken longer to figure out the source of the problem and fix it, and the problem would have remained visible until it was fixed.
Long story short: If you’re managing a professional wpmu setup for paying customers, you should really consider making use of a staging area and a version control system 🙂
Kurt
@TexInWien: instead of customizing the default theme in the same default directory, copy the files to another directory and give the theme a new name. It won’t be changed when wordpress is updated.
@Christopher: Thanks for the tip. We’ve moved our customized theme to the default folder by design. At this time, we’re using the single customized theme for all existing and new blogs. Placing it in the /default/ folder makes it the default theme for all of the blogs in our wpmu installation.
You could hook into the signup process and modify the theme options too. I can’t remember the hook but it’s in wpmu-functions.php and would save you trouble in the future!
I totally agree about a staging area and svn.
@Donncha: Thanks, I’ll look into that option for the long term. With the staging area and version control, it only costs us an extra minute or so to make the current setup work when upgrading WordPress MU, so it’s not a huge problem yet.
@TexInWien: You can use the “new blog defaults” plugin to set a different theme as default when a new blog is created. 🙂
http://wordpress.org/extend/plugins/wpmu-new-blog-defaults/
@Christopher: Thanks – we installed the plugin last week but haven’t finished configuring it yet. It’s got a lot of options!
In case it wasn’t clear, I’m not complaining that my default folder is overwritten when I upgrade WPMU. The point is more that a staging area and version control system can help you hide problems and back them out quickly, whatever the problems are…
Didn’t even know there was going to be another release for WPMU!
Glad to finally see a global terms admin page. I ran into the wp_sitecategories problem myself!
Also question about the signup procedure in 2.9.2, how does this affect BuddyPress?
had the same problem but didn’t understand the source of it. while upgrading to 2.9.2 the server started swapping like crazy and didn’t respond for several hours. Could only get it back running by restarting most of my services like mysql…
Now this makes more sense to me but isn’t there a possibility to slow this process down while upgrading?