It is kind of weird to write this, but as of today the bava is no longer powered by WordPress Multi-User. I have upgraded this site to WP 3.0 Beta 2. For almost three years now this site has been running on a multi-site WPMu setup that contained not only this blog, but jimgroom.net, wpmued.org (now a deprecated name space:( ), and several other personal sites. The bava WPMu install became my test bed for UMW Blogs over the last three years, and to see it return back to a straight WordPress site (though it’s not really that anymore with 3.0) is kinda bizarre.
I’ve been working with WPMu for more than four years, and I’ve literally written hundreds of posts on this blog about my work at hacking it. And I’ll be the first to admit I am the worst of hacks—don’t know a lick of code—but that being the case, WPMu made me. I can daydream that my b-movie posts or my tour-de-force toy blogging put me on the map, but it was my sophomoric work with WPMu and UMW Blogs that gave me a reason to blog just about everyday for almost four years. It was a good run, and I couldn’t have done it without Donncha—so thank you kindly. And while I know it’s time to move on, I certainly mourn a chapter of this blog that is effectively closing. I’ll still be blogging through the transition of UMW Blogs from WPMu 2.9.2 to WP 3.0, and there is much to talk about and figure out there yet, but with this post a piece of the bava is dying. But, that said, I wouldn’t trade it for the world because, as William Faulkner says, “Given a choice between grief and nothing, I’d choose grief.” Good bye Mu, I’ll miss you!
On a more prosaic note, the upgrade from WPMu 2.9.2 to WP 3.0 Beta 2 went extremely smoothly following this tutorial (just be careful of the wording in Step 1, what he means to say is replace all files and folders except wp-content, leave that be). Some initial observations:
- Userthemes is further borked after the upgrade (no surprise there), but it looks like WP 3.0 Beta 2 has theme editing built-in across sites. I may be wrong, but when I deleted the Userthemes plugin, an edit button showed up on various blogs. This could be awesome, but it also means I have to find a way to un-usertheme a lot of blogs that were using Userthemes in UMW Blogs. This will take some looking into.
- The various mapped WPMu sites I had on by own WPMu install worked without issue. jimgroom.net is a full blown WPMu site within a site (or the correct terminology now would be network within a network?–not sure.) Those worked fine, as did some straightforward mapped domains, which is nice. But, I am still using the mu-plugins folder with various plugins that control these functions. Need to experiment with how much they bork when I start deleting MU plugins, we’ll see.¹
- Need to test the Sitewide Tag Pages Plugin that Donncha created, this plugin has been key to the syndication framework on UMW Blogs, but I’m not sure it will be managed for too much longer even if it does still work. Need to find out if some global posts/tags/terms are being used across sites. We’ll see.
- On that note, need to see what FeedWordPress is all about in 3.0, that will prove crucial as well.
- Need to figure out the whole Child Theme thing, as well as test out a whole series of plugins while cleaning out my mu-plugins folder.
As you can see my list of things is long, and there is much work ahead and I plan on blogging it all. But as of now a big step 1 is done [sniff].
¹ Turns out mu-plugins will be supported for the foreseeable future reframing the mu-plugins from the association of MultiUser to “Must-Use,” basically making them active across entire installation (which means more than one network). Also, there is another cool feature for keeping WPMu sites like UMW Blogs afloat: “Drop-Ins.” To quote this excellent article on both of these new additions to WP 3.0:
Some core functionality of the WordPress core can be replaced by so called Drop-Ins. Those are PHP files on specific locations that get included if they exist. The inclusion is done for a specific task, for example
db.phpget’s loaded to replace the default PHP database class. So you can replace it with one that is faster, more stable and secure for example. Drop-Ins exist since various versions, depending on them. The Multi-Site since 3.0 naturally.
This means it should square any sharedb.php issues with UMW Blogs, which is mint. It is also why sunrise.php for the Domain Mapping plugging kept working seamlessly. See the article above for a list of WordPress Drop-Ins.
Additionally, as my turn to terminology in comments might have suggested, I went searching for posts about the new terminology being used in WP 3.0 as the merge of WP and WPMu comes to pass. Here is another good post on the new terminology in WordPress 3.0 for blogs, sites, networks, etc., and here is a nice presentation on it as well. The changing terminology is something I am actually really interested in, and may be the basis of a longer series of thoughts about the importance of terminoloy in watching WordPress develop and grow.
Ahhhhh, good ol’ Mu…. being returned to the fold, as it were….
Multisite is now a multiple network. We have to re-do the plguin and yeah, snazzy new name to boot. FUNNY ENOUGH if you remove that plugin the extra networks still work.
The mu-plugins folder is for “must-use” plugins. Imagine MY surprise when I learned that one. huh. Still applicable in 3.0.
Theme editing – hadn’t dug too deep on that one. I think Ron has a post about disabling it.
SWT – shoudl still work, a couple people told me it wasn’t on new setups. There is no new global content aggregation built in.
OK, so multisite =multiple network. And by that logic a single wp domain (with associated subdomains/subdirectory off that domain) is a network.
The move in terminology from blog to site makes a lot of sense to me post facto, though it’s odd how I used to term what they are now calling a network as a site before the new terminology. Gonna need to study up on this lingo.
As for the multi-site plugin, have you and Ron finished the re-worked version for WP 3.0 Beta 2 yet? I’d love to test it out.
Now, as for mu-plugins, I’d be interested to figure out what they consider must-use. I’m gonna guess this is stuff you depended on with MU, but haven’t found a workaround yet for in WP 3.0 🙂 This is a beautiful safety feature for upgrading!!
As for theme editing, I like having that in there, at least on my own personal WPMu install—not so much for UMW Blogs. What I need to do on this is figure how to undo userthemes, or get that working in some kind of kludgy way until I can figure out a fix.
Glad SWT is still a go, I am gonna test it on my setup and see what’s happening there.
I look forward to working with you over the next three months on this 🙂
If it ain’t borked don’t flick it!
I wholeheartedly agree, although my only concern is carrying too many of my bad hacks forward, and in turn making UMW Blogs Windows Vista 🙂
Thanks for blazing the trail for us to move into the WP 3.0 world. And thanks for the clarification about the upgrade tutorial. Knave that one bookmarked and was confused/concerned about that first step when I was reading through it and was wondering how the upgrade would actually work.
We have too many students blogging right now from international studies so my upgrade will have to wait for a while longer…Which is great so I can steal, er, learn from your work!
Yeah no need to move from WPMU 2.xxx just yet, there is still some work to do on several grounds. After this upgrade on my own sites, I am happy to initally report that it promises to be a far smoother transition than I initially imagined, and it keeps so much of the legacy plugins and hacks from Mu around, at least in this version, that I think it will prove rather painless. I’m guessing something you can do in an hour or so if we can figure out userthemes. You using userthemes?
I was asked in an interview recently (hasn’t been published yet) if I had any misgivings/regrets about the merge. Having time to reflect on the question, it’s similar to having a child grow up and move out. While you are excited to see them become independent & pursue their own life, you are losing having them around.
We still have all the MU functionality but it’s not the same :/
On Domain Mapping, SWT, etc. – Those were used extensively in testing the merged codebase 🙂
Yeah, the child analogy is right on, the only issue is that publishing platforms grow up even quicker than kids in this day and age 🙂
As for the SWT and domain mapping, both work like a charm, and I have no doubts tht’s because you were integral to the merged codebase, so let me formally thank you for making my job this Summer million times easier. You rock! And while I’m add it, i am gonna assume you tested ShareDB 🙂
I’ve got major Userthemes anxiety. Gonna roll 3.0 out on our dev server this week and see what I see.
Userthemes seems to be the major issue for me as well I have disabled it throughout the bavatuesdays multi-netowrks, and I think I am going to keep it in UMW Blogs as a deprecated reality and slowly go through the blogs that have it activated and bring those themes into the System themes, make them unavailable, and see if we can;t get off userthemes all together. Reason being, with one small hack, I think the functionality of userthemes can be obtained throughout a setup with little or no issues. And it should be the same idea, uber-admin approves who does and who doesn’t get access ti Userthemes. Shannon and I will have to create a list of sites on UMW Blogs using Userthemes, and then tackle that whole thing this Summer because that is really the only thing preventing me from updating the whole UMW Blogs tomorrow—that is how smooth the upgrade has been. Pretty remarkable, really.
Jim, you should be careful trying to replicate Userthemes with the theme editor. With UT, you and I could have different versions of (say) Kubrick that we could edit independently. I’m pretty sure the 3.0 editor does not work that way – any changes made by one user of the theme will be reflected by all other users of the theme. So you as the admin will have to duplicate a theme manually every time another person wants to customize it.
Yeah, good point, makes the functionality of Userthemes still valuable. Hmmm, need to think about whether pushing @dsader to keep developing it.
I think you can put themes in system theme but hide them from all users pretty easily from what was the uber site admin function–>Themes section. But I could see this making your system themes folder pretty ugly.
Is there a way to limit who sees what themes, so that Boone’s customized K2 sits in wp-content/themes/ and is active on his blog, but does not show in the theme library?
@Luke – disable the theme under Site Admin -> Themes and then Edit your blog attributes so it’s enabled just for you.
And in 3.0, it’s exactly the same, except it’s Super Admin -> Themes.
That’s a good way at this, thanks. I never thought to use the Blog/edit buttton for this, but makes sense. Especially since this is where you canchange the upload space on a blog-by-blog basis, will that still be the case in WP 3.0 ? We’ll see 🙂
Does the new WP still store each blog in it’s own set of tables, or are all posts from all blogs (for example) stored in a single posts table?
As far as I can tell it still reproduces the same database structure from WPMu, which I’m sure your happy to hear 🙂
@Revered – yes, still the case.
Everything works the same way it did in MU.