I just pulled down the latest and greatest from WordPress's SVN repository to give the new 3.0 code a whirl. Specifically, I wanted to see what was happening around the WP.org and WPMU merge that is one of the big features of 3.0, since I run a bunch of WP.org blogs that I'd love to have multihosted, and at work we run an WPMU installation and are in the works of three more. Having a single way to do everything is quite compelling, especially if there's a way to transparently "upgrade" from a standalone site to a multihosted one.
I was initially disappointed when I looked at the source, because the MU bits seemed to be missing, but a little more digging showed telltale signs that it was at least partially integrated. After setting up the installation, I found a mysterious "Network" option in my "Tools" menu, clicked it, and was presented with basically the MU installer UI. Sweet!
Submitting that resulted in a page with three simple instructions: create the blogs.dir directory, install this new wp-config.php script (in a TEXTAREA), and update .htaccess with this new config (also in a TEXTAREA). My suspicion is that if PHP had write access it would've done all three automatically.
After following instructions and clearing my cookies (not explicitly mentioned), I had a fully functional multihosted WordPress install with the normal MU site administrator menu and everything. This is awesome. And just in case that was unclear, it's awesome. The database, of course, was refactored behind the scenes. Unfortunately it still uses the tableset-per-blog paradigm (just minus the "_1″ infix for the root blog) rather than a single tableset with foreign keys, but there's no way they could change that without having all kinds of upgrade issues for existing WPMU installations.
There are still a pile of things to update (like the per-blog permalink config shouldn't attempt to write .htaccess) to get the WP.org functionality to morph into the WPMU functionality, but for the "normal" authoring tasks it appears to be as solid as ever. I suspect a careful administrator could, with a bit of patience, produce a security setup that would let authors have the run of their site without breaking anything even before the actual restrictions are put in place by Automattic.
In any case, very exciting to see this integration project already so far along. WordPress.org says 3.0 is slated for March, which is crazy soon, but I'm all for it. I've been waiting to upgrade a pile of WP.org blogs to a WPMU instance for a while now, and this is going to make it much easier.
Hi!
Thanks a lot for the news. I've been waiting for the code merge as well. The BuddyPress that is for now only for WPMU will be available for WP single and that opens new possibilities for the wordpress as a CMS.
Thanks for the write up. Does that mean you did not have to change httpd.conf and add wildcards as you need to do for WPMU (which I assume is a big hurdle for smaller WP isntallations on shared hosts etc)?
How does the server handle things now?
Cheers, Harry
[...] WordPress 3.0 – A deeper look at the WordPress 3.0 [...]
Well, for one, I"m not too excited about the Wordpress mu code merge. If you are wondering why, check out my post at: Wordpress 3.0 – What's Troubling Me.
Frank,
While I understand your criticism, I'm not sure how it applies. MU isn't necessarily about administering a whole pile of blogs as a single unit, it's about serving a whole pile of blogs from a single codebase. The MU architecture is about scalability (for wordpress.com) for a huge number of discrete blogs, not bulk-managing related blogs. I've not seen MU make any admin task harder than it would be if every individual blog was a separate WP.org installation, but it makes upgrades, backups, etc. enormously easier.
But the bottom line is that none of the problems you attribute to MU has are specific to MU's code. Rather they're specific to MU's inherent use as a multihosting solution. You'd have all the same problems if you use WP.org to do multihosting, but without all the benefits of MU.