Deprecate bloginfo() in favor of siteinfo()

[benbalter]

The function bloginfo() should be deprecated in favor of a more aptly named siteinfo().

The function traces its roots back to version 0.71, and no longer properly describes its use, especially after 3.0's custom post type and custom taxonomy functionality. Put another way, the technology we have created has outpaced the metaphor we use to describe it.

Especially in the buttoned-up context of enterprise installs, “blog” can be a dirty word and helps to perpetuate the perception that WordPress is nothing more than a mere blogging engine (rather than a full-fledged CMS) and should not be considered for "serious" content management needs. Yet, to get the title of any site, regardless of content, the command we all still run is get_bloginfo().

Steps to reproduce:

1. Set up a WordPress site for something other than a blog
2. Attempt to spit out the site title, url, or stylesheet directory
3. Be confused why I'm calling my WordPress site a "blog", when I'm using it to publish other types of content

( Some ​background )

Yes, on paper it's a somewhat trivial issue, and may require a broader, somewhat existential discussion to resolve, but internal terminology ultimately leads to external perceptions, and it is a discussion well worth raising, if it hasn't already been hashed out elsewhere.

[benbalter]

Patch to deprecate bloginfo() in favor of siteinfo()

[nacin]

The problem here is that 'site' means two different things in WordPress. One, it is a synonym for 'blog'. This is primarily prevalent in the UI — we don't use 'blog' anywhere, since 3.0. Anywhere on WordPress.org that uses 'blog' or 'weblog' should/will be converted to 'site' (sadly, many are out of date). At the API level, few particular functions use 'site' to refer to 'blog', but very few do. (See "Two," below.)

Two, WordPress MU really, really complicated things here. (Screwed the pooch, if you will.) It used the word 'site' to mean a collection of blogs. It was reflected everywhere — get_site_option(), get_current_site(), etc. In 3.0 this caused quite a few problems (as that is when we renamed the UI).

The solution wasn't great. A collection of 'blogs' is now a 'network'. Which means the UI now says a collection of 'sites' is a 'network'. The API is therefore consistent that 'blog' (say, blog_id) is always a blog-site, and that 'network' (say, populate_network()) is always a site-network. This of course leaves a number of situations where 'site' is ambiguous. site_id and current_site are both holdovers from MU and mean site-network. But ms_site_check() actually refers to a blog-site.

Now that the merge is two years behind us, what we need to do is do a full accounting of all functions that use 'site' (as in site-network) as a name or argument, deprecate them, and move them to 'network' terminology. Only once we do that can we start to move 'blog' to 'site' in the API.

And of course, with functions get_blog_option() (blog-site) and get_site_option() (site-network) already existing, it's not like get_blog_option() can be renamed to get_site_option(). It's just too messy.

And so, we end up with the status quo — which is to leave everything as is, and hope it doesn't confuse people too much.

[nacin]

I did a write-up on this two years ago. ​http://nacin.com/2010/03/25/terminology-nightmare-blogs-sites-networks/

I quoted ryan at the end: "Leave API as is and let UI do what it wants. Expect devs to be able to bridge the terms." For now, that's what we're stuck with.