The goal of this post is to confuse you, and your head will probably hurt by the end. This is a process story on how we came to decide terminology for WordPress 3.0, and why many functions are so detached from the terminology used in the UI.
The main feature of the WordPress 3.0 is the merge of WordPress MU. MU, or multi-user, was a fork of the codebase designed for many blogs and many users, all on one install.
Your WordPress 2.9 install is a blog. WordPress MU hosts multiple blogs in a site, with the site’s subdomains or subdirectories each being a blog. Technically, MU can support multiple sites, whereas each site is a domain, and each site will have more than one blog.
Thus, example.org is a site (and also the main blog for the site), blog.example.org is a blog on the example.org site, and blog.example.com is a blog on the example.com site. All of this can be managed by a single MU installation. The cross-domain aspects require a plugin, but subdirectories or subdomains are out of the box.
Here’s where it got fun. Come WordPress 3.0, there was a UX decision made to call a blog a site, and remove the “blog” terminology.
You can see where this is going.
If a blog is now a site, then what does a site become? “Domain” is one option, but we didn’t want the connotations that came with that. (More on that later.)
When the merge began, the core developers began to use multisite internally to mean many blogs (well, sites), shortened to “ms” where possible, thus removing the “mu” and “wpmu” prefixes on files and functions.
Surely, we can make this more difficult. And so, just as the UX decision was made to call a blog a site, we decided to call a multisite a network.
The function get_option(), as you know, fetches the specified option for the blog (a site, in the new UI parlance). But MU has two other variations of the options API. One is get_blog_option(), which is used to get the specified option for another blog. So we could leave get_option() as is, and rename get_blog_option() to get_site_option().
Right? Nope.
See, the other API that MU has is get_site_option(), which are options for the entire MU site (in 3.0 parlance, that’d be multisite or a network). So get_blog_option() would be for sites (formerly known as a blog), and get_site_option() would be for multisites (or networks). (We also don’t generally rename the underlying functions only when the UI changes for UX reasons.)
A lot of discussion centered around the options API. There are no options across an entire MU multi-domain install, but we still thought about that and it caused plenty of confusion. We also considered get_sitewide_option(), get_domain_option(), get_multisite_option(), and yes, even get_thingieswide_option(). In despair, one suggestion was thing, thingy, and thingies, to replace blog, site, and network. (Edit: I’ve checked the logs, and it was core dev Peter Westwood who proposed this gem.)
Still with me?
We have this other MU function, called is_site_admin(). An MU site admin has complete control over the site’s settings and all blogs. (In 3.0 terms, these users have complete control over the network’s settings and all sites.)
In order to complete the merge, we’d need to make a lot of is_site_admin() calls all over the place. This function should return true if it’s a network admin, but also true if the user is an administrator on a single-blog (single-site?) installation. (MU blog admins have lesser privileges than both MU site admins and single-install admins.)
The problem is, many plugins check for the existence of is_site_admin() to determine whether it’s MU or a single-install, which means we could only use it in files that are only loaded when we’re running multisite. So much for that.
Thus, is_site_admin() was the first MU function to be deprecated. We started a new deprecated file to be included only when running multisite (and we ended up adding 3 more deprecated files for other contexts). Thus, old plugins using function_exists('is_site_admin') will still work. (For reference, you should now use is_multisite() — do not rely on any constants such as MULTISITE.)
Now what? Well, we needed a replacement for is_site_admin(). Since we aren’t changing any terminology in the code, remember, its current name would have been preferred.
Early candidates, is_multisite_admin() and is_network_admin(), pose terminology problems of their own. An MU site admin isn’t necessarily a site admin for another domain on the same install, and there were some concerns that these functions could falsely connotate multiple domains.
This brings up another problem we have yet to address: If a network (an MU site) has many blogs (err, sites), then what is a collection of many MU sites across domains? (We defined “network” as not spanning domains.)
Ultimately, we decided on is_super_admin(), as that is what many will end up referring to it as anyway. This later inspired talk of capes, but I digress.
“Leave API as is and let UI do what it wants,” Ryan Boren said. “Expect devs to be able to bridge the terms.” To do that, I wish you all lots of luck.
This is more or less a summary of an actual IRC conversation among a handful of contributors and developers, including myself. It was mind-numbingly confusing. I would link to the logs, but its contents make a lot of smart people look really silly. Okay, fine, the logs are here — but I’m only sharing it with you because now that I’ve located them, I realize this post has only scraped the surface of the confusion, and you deserve a bigger headache. For reference, Ryan’s quote above came from the IRC discussion.
Hi, I'm Andrew Nacin, 
That’s hilarious. Ironically, when I install 2.9 on client sites, I change the admin to superadmin & make and editor role named admin… aka.. I like it.
Brain = pretty much fried, but I did manage to keep track of what you were saying throughout! Amazing how complicated these things get!
I particularly enjoyed your comments about thingies, and capes – very good stuff
“Leave API as is and let UI do what it wants,” Ryan Boren said. “Expect devs to be able to bridge the terms.”
It’s sad to see that this is an acceptable way of doing things. This equates to make the UI look nice and who cares if the code is messy. What happened to code is poetry?
I disagree. We should not rename functions just for the sake of renaming them. It’s a backwards compatibility nightmare — and we’d always have to keep the old functions anyway.
Where would the renaming end? We would need to rename literally hundreds of functions and variables (some of them globals), and would not only break a lot of core code in the process, but we’d end up breaking a lot of plugins as well. No need, and not even close to worth it. That’s not even to mention problems like renaming get_blog_option() to get_site_option(), which cannot occur, since get_site_option() already exists for a completely different layer.
This post wasn’t about poor practices. Rather, I only posted Ryan’s quote because it was ironic given the situation. I subscribe to what he said 100%.
That maybe so, but it illustrates why merging the existing MU codebase into WordPress itself is problematic. A better alternative may have been to start from scratch rather than merging the MU codebase.
Would things have been backwards compatible? No. But sometimes you have to start over to move forward. Backwards compatibility is great, but sometimes it has to be sacrificed for the greater good of the project.
Is good to know that we have you folks to think about all this “terminology mess” and “compatibility issues” and, when WP 3 comes it will be easier for us “mere mortals”.
Thanks!
Pingback: Sites, Blogs, Networks Oh My
See, I only think it’s confusing for people who were used to the previous WPMU terminology. For most new users, it will be new to them.
As for calling them sites instead of blogs, it’s a step forward and brings WP more towards being a CMS in the eyes of others. (It has been all along, but it may stop the “but I don’t want a blog! I just want to manage some pages on my website.”)
“An MU site admin isn’t necessarily a site admin for another domain on the same install, ”
Unless you’re talking about multiple networks in the same install (possible), a site admin is such across the board. Regardless.
This wasn’t an indictment of the terminology — I’m all for the changes, myself. Also, yes, that’s what I’m referring to — I’m talking about each row in
$wpdb->site(generally each domain in the install) having their own MU site admins. Core itself of course only handles one domain out of the box, so it’s a rare use case.Why did you make blog a site in the first place?
A blog is just a feature of a site. You can have a blog on your site or your site can consist of only your blog.
Then you have Network->Sites->blog/s
Given you don’t even have to have a blog on a wordpress install it makes everything sound stupid. I got sites with no blog feature on them.
A principal reason why we’re no longer calling a WordPress installation a blog is because it has evolved from blogging software to a content management system. (You said it yourself, you have sites with no blog feature on them.)
In your Blog/Site/Network model, I suppose you’re considering a typical MU installation a “site,” as it is now, and multiple MU sites a network (say, an MU install that spans across multiple domains). None of that works. As explained, we’re removing “blog” terminology and calling a single WordPress install a site. A collection of sites is a network. And, the “network” in your model — multiple domains — doesn’t exist. A domain-mapping plugin can run multiple networks on a single install, but there is no out-of-the-box support in MU or 3.0.
“MultiSite mode” is “network” in my model.
Standard installation is just a site.
=)
So you have a bunch of sites in your network which may or may not have a blog feature.
And you really should think about renaming stuff and deprecate. Working with wp 3.0 is confusing. “New” hooks called wpmu_* old hooks not firing when they ought to etc. Same button action equals different results and so on.
Pingback: Sites, Blogs, Networks, Oh My! - WordPress Tavern Forum
Pingback: links for 2010-03-26 | Links | WereWP
…Just a quick “thank you” to all WP devs… core, theme, and plugins. You make my work possible:)
Pingback: 10 Things You Need to Know About WordPress 3.0
I assume you all looked and considered how ‘other’ blog platforms with MU capabilities have achieved what you are trying to do with WP 3.0 ?
Why not write a layer — say wpm_ functions — that matches the new terminology and then calls the underlying wp_ functions internally (a bridge api). This would allow backwards compatibility for plugins and themes while making future development less of a headache. “Let’s see, I call wp_blog_X () to work with the site, and wp_site_X () to work with the network … Honey! Where do we keep the Tylenol?”
Pingback: WordPress 3.0 Walkthrough: Getting Started with Multisite « Weblog Tools Collection
Pingback: WordPress 3.0 Walkthrough: Getting Started with Multisite | Wizpress.com
Pingback: Wordpress 3.0 Roundup | Themergency
Pingback: Wordpress 3.0 Lançado! | Política Externa Brasileira
Pingback: Wordpress 3.0 now is avilable! | Onlinemakeez.com
Pingback: Wordpress 3.0 User Features « Luthfi Emka
Pingback: WordPress 3.0 – christian schorn de
Pingback: WordPress And Giving Credit
Pingback: Confusion at the WordPress Homestead… Terminology Mish-Mash? « Javamancy mini
Pingback: HOW TO: Get Up-to-Date on WordPress 3.0
Pingback: HOW TO: Get Up-to-Date on WordPress 3.0 | RetweetToday.com | News for Us, by Us!
Pingback: HOW TO: Get Up-to-Date on WordPress 3.0 | Free SEO Advice
Pingback: HOW TO: Get Up-to-Date on WordPress 3.0 - White Shaarks - Imagination is your future
Pingback: HOW TO: Get Up-to-Date on WordPress 3.0 | Xiaoqi He ( Harry He ) – Official Blog – 贺孝琦官方博客
Pingback: Binomial Revenue » Blog Archive » HOW TO: Get Up-to-Date on WordPress 3.0
Pingback: Did You Know About WordPress 3.0? « Dolarco's Blog
Pingback: WordPress 3.0 “Thelonious” sudah keluar « ejoeSolutions
Pingback: Source and Code » Blog Archive » WordPress Version 3.0
Pingback: Get Started Using the WordPress 3.0 Multi-site Feature | tripwire magazine
Pingback: SEO Friendly Wordpress Version 3.0 « Banyan Tree SEO