The Smorgasbord of Douglas Bell

WordPress 3.0 “Thelonious” was released eight days ago to much fanfare. Certainly for me, I don’t think I’ve been quite as excited for any other major WordPress release as I was for 3.0. Now granted, at first glance, 3.0 doesn’t actually look that different from 2.9, at least in terms of what meets the eye. Quite frankly, WordPress 2.7, which introduced the modern interface for the WordPress admin screens, had much more impact in terms of new features that were apparent to the eye. By contrast, most of the new features in WordPress 3.0 address more under-the-hood tweaks and improvements, but collectively, they pack a punch.

(As a side-note, the funniest new feature that strikes me is the addition of a filter called capital_P_dangit() that forces any instance of “WordPress” being written without the P being capitalized gets automatically fixed to what it should be. I’d try to demonstrate, but you know, the filter would eliminate that effort!)

After working with WordPress 3.0 very closely for the past week, and also playing with the Release Candidates for a few weeks before that, here is my list of my six favorite new features in WordPress 3.0.

#6: Changeable Admin Username
Finally, one of my biggest pet peeves about WordPress has been addressed. Until 3.0, when you installed WordPress for the first time, the default administrator username was set to “admin” and you couldn’t change it. Not an entirely big deal for single-user blogs, but when I add a bunch of users to a site I generally like to utilize some kind of system for logically managing usernames, and “admin” flew in the face of that effort. Finally, upon installing a fresh WordPress 3.0 site, you are prompted to set the initial admin username to whatever you want. Yay!

#5: Help on Every Screen
Ever since the advent of the new admin interface in WordPress 2.7, there’s been a little “Help” tab on the upper-right that, when clicked, would slide down some information about what the different options on that page did. At least, for some pages. Most pages only showed links to the WordPress Codex and the Support Forums. Finally, WordPress 3.0 ensures that every admin page built-into the default WordPress 3.0 gets a full help treatment.
Now this isn’t really going to be directly helpful to me, because I know my way around WordPress quite easily. But a lot of my sites are soon going to be introducing a lot of brand-new wide-eyed users to the WordPress admin, and so now I’m quite glad that I can finally rely on those collapsible help screens as a resource to help the newbies. Which means I won’t have to spend as much time being a support technician.

#4: Twenty Ten Theme
I first started using WordPress when it was at version 1.5, in 2005. At that time, WordPress had just adopted Kubrick as its new default theme. It was a gorgeous theme, with custom header options, and even custom do-it-yourself gradients! Wow. But then, WordPress evolved, and became more about building a “site” than a “blog.” Site-wide navigation bars became hip. Widgets started moving beyond the sidebar and into new places. Kubrick stopped being so much of a “default’ theme as a “placeholder” theme to use until you found a better one.

WordPress 3.0 finally retires Kubrick (and the even older “Classic” theme, which no one used) with a new theme called Twenty Ten. This theme is loaded with awesome features that set a new standard for other themes to cling to. It comes with a number of custom header images, or you can specify your own. It even integrates the custom header with a featured image for each post, if you’ve set one. It also supports custom backgrounds, while still maintaining a bit of whitespace around the content to make the background look more like a nifty wallpaper. Throw in a navigation bar with great drop-down menus, special styles for asides and galleries, choice of one- or two-columns, support for widgets in the footer alongside sidebar widgets, and enhanced support for printing posts, Twenty Ten is now a default theme that many bloggers would be more than happy to stick with. I’m even using it for the website for my upcoming OSCONvasion 2010 meetup.

Probably most important about Twenty Ten is that it represents the most visible evidence of an official change in methodology for WordPress truly being recognized as a CMS, not just as a blog. Other terminology tweaks throughout 3.0 properly refer to a WordPress installation as a “site” now, not just a “blog,” because that truly is now how WordPress is being used by most people. And my next top 3 feature picks go much further into defining WordPress as such.

#3: Custom Menus
Navigation bars have become all the rage in WordPress themes, but getting them to look right has always been a pain. Navbars for different themes worked differently depending on whether your homepage = your blog posts or a different page. Getting them in the right order required tweaking the “order number” of your pages to be what you want; creating submenus required establishing a hierarchy of pages, which wasn’t always what you wanted (not to mention that it lengthened permalinks). And if you wanted to exclude a page from the navigation, or add a custom link that was unrelated to your pages, time to dive into the PHP code!

Finally, WordPress 3.0 introduces a custom menus interface that is quite slick, and fairly familiar to anyone who knows how customizing widgets works. You can create an unlimited number of different menus, and then boxes listing your site’s pages and categories are provided, which you can use to select the ones you want and add them to the menu. Then, simply drag-and-drop menu items to get the order you want, and create sub-menus by indenting menu items. Expanding the menu item lets you change the display text used in the menu (great for SEO) and add a title attribute (tooltip) if you want. Adding a custom link is also easy, just enter the link in a separate box, provide some display text, and the menu item is added.

Themes that offer support for custom menus will allow you to pick one (or more) of your menus to be displayed in a particular location. You can also display any custom menu of your choice via a new Custom Menus widget as well. However, I actually found that it wasn’t too difficult to add custom menu support to my existing themes using this tutorial. All you have to do is add a few lines of code to the theme’s functions.php file in order to a) let WordPress know that this theme now supports custom menus and b) register the place(s) in the theme where menus can be added. Then, dive into the theme’s header.php (or wherever) and identify where the HTML code for the current navigation bar is located. This is where you have to be clever, by customizing the elements passed to the wp_nav_menu() function so that the custom menu output will properly emulate the <div&rt; (or <nav&rt;) and <ul&rt; elements that are already being used by your theme, with the proper calls to CSS classes and ids. It takes a bit of trial and error, but for each theme I’ve tried I was able to get everything to work in no more than 15 minutes.

Custom menus plugs a big hole in terms of providing customization abilities for key areas of WordPress, and again is a big plus to have for CMS veterans. Now all I need is for WordPress to add customizable footers, and I’m all set.

#2: Custom Post Types
This is a big feature specifically for developers, ripped right out of the feature list of a traditional CMS. It took me a bit of reading to recognize just how powerful this feature can be, but I’m really excited to start working with it.

Here’s the idea. WordPress comes with a number of different types of items that are postable. These include blog posts, pages, links, media, etc. They are each treated differently because they have different metadata and are displayed in unique ways. But as far as the WordPress MySQL database is concerned, all of that info is actually being deposited into the same places alongside each other.

Custom Post Types let developers define additional types of posts that can be created and displayed independently of these other types of posts. For example, let’s say that I enjoyed cooking, and wanted to have a place to post my favorite recipes, but I wanted to display them on a page of my site completely separate from my normal blog posts. I could create a ‘recipes’ custom post type, and this would literally add a completely new tab to my WordPress admin (under Posts/Media/Links/Pages/Comments) called Recipes. I could go there to post a new recipe or manage my posted recipes, just like managing regular posts or pages.

What’s even cooler is that as the developer, I could dictate to WordPress a whole bunch of other options to truly customize my recipes post type, such as:

• Whether my recipes should be public–for everyone to see, or private–just for me to see
• Whether they should appear in search results if someone runs a search on my site
• Whether my recipes should be hierarchical (act like pages in WordPress) or chronological (act like blog posts in WordPress)
• Specific control the types of capabilities and permissions available to users to read/write/edit/delete recipes
• Full control over what posting options are available, such as title, text editor, comments, trackbacks, revisions, author, excerpt, thumbnail, custom fields, page attributes, etc.
• Ability to create custom taxonomies (kind of like categories of tags), which I could use to allow visitors to filter my recipes by types of ingredients, or type of meal, or season–three examples of custom taxonomies–the same way users can filter blog posts by tags
• And lots more.

Then by creating a custom template for my WordPress theme, I can create a completely separate section of my site for browsing and viewing my recipes with a lot of available display options based on the WordPress Loop.

I can see a lot of possibilities for using Custom Post Types–probably the first place I’m going to try them will be on the next version of the ATV website where I’m going to create custom types for video clips and full episodes for the different shows. But I truly believe that as I get more familiar working with Custom Post Types, it’s truly going to change the way that I develop for WordPress going forward.

For more info on Custom Post Types, check out this tutorial, or check out the Custom Post Type UI plugin.

#1: WordPress Multi-Site
WordPress MU has been around for a couple of years now, and I started working with it last fall when I developed the ATV website. Essentially it’s a wrapper around a number installation of WordPress which allowed multiple blogs to spawn off of a single installation of WordPress, either through virtualized subdirectories (example.com/blogname) or subdomains (blogname.example.com). It powers the tens of thousands of blogs running on WordPress.com, and it really offers some nice functionality.

But there were a number of downsides to using WordPress MU:

• WordPress MU was pretty much maintained by a single WordPress developer, who had to pull an all-nighter or two to update the MU package by merging over changes made to the regular WordPress package–this meant that WordPress MU updates would generally come out 2-10 days after their standalone-WordPress counterparts.
• As a separate product, fewer people used it & supported it, and finding plugins specifically to take advantage of MU features was a challenge.
• The instructions for using MU were unnecessarily intimidating and confusing, which is why it took me a long time to get up the nerve to start using it.
• Lots of confusion over the name. MU was supposed to stand for “multi-user,” but really MU’s functionality was to create multiple blogs. The standalone WordPress already supported multiple user accounts. Not to mention that it was intended to be referred to as “mew,” after the Greek letter μ, but many people called it by its initials “emm you”. (The website also suggested that if you were feeling bovine, you could all it “WordPress moooooooooo.”)

WordPress 3.0 takes the brilliant step of formally merging the old MU functionality in with the core WordPress, which fixes all of those downsides. Now, if you want to create a multi-site version of WordPress, you merely download and install the regular WordPress normally. Then, in wp-config.php, you add the line define(‘WP_ALLOW_MULTISITE’, true); — this line magically makes a “Network” page appear under the Tools menu in the admin. From here, you enter some multi-site-specific configuration options, and then WordPress spits out some more code that you should add to wp-config.php and your .htaccess file. And just like that, you magically have a working multi-site version of WordPress!

**A word to the wise: You have to choose right then between subdirectories and subdomains; you can’t change your mind later. If you’re choosing subdirectories, make sure that you’ve setup a “virtual subdomain” through your hosting control panel — usually this is done by adding a *.example.com subdomain, pointing to the root of your WordPress install. Your WordPress install also has to be on the top-level directory of your domain name if you’re doing subdomains, and you need to make sure that your WordPress URL settings DO NOT have “www” included in them.

By merging the multi-site functionality in with the core WordPress, all of those downsides that I mentioned go away. Multi-site users will now get updates at the same time as standalone users (since it’s the same package), and now that this functionality is more readily available to everyone, more people will certainly start supporting it. We may even start seeing multi-site-capable plugins in the Plugins Directory now, hopefully.

There’s also a lovely terminology overhaul for multi-site users. The confusing “multi-user” name becomes “multi-site,” much more appropriately. Whereas you used to have a “site” containing “blogs,” now you have a “network” containing “sites,” also more appropriate. And because of that, the person who has total control over the entire network is no longer a “Site Admin,” but a “Super Admin.” The only terminology that hasn’t changed is the mu-plugins directory, except “mu” now stands for “must-use.” Even better, “must-use plugins” now show up in a special section of the WordPress admin, which is a welcome improvement.

This is my #1 feature of WordPress 3.0 because I’m now heading up three different multi-site based websites, and after maintaining the ATV website under versions 2.8 and 2.9 of WordPress MU for the past nine months, all of these changes have made working with multi-site installs far more intuitive and enjoyable. Think of it like Steve Jobs’ “one more thing” on top of all of the other great features that have been delivered as part of this upgrade.

So thank you, WordPress developers, for all of your hard work that you’ve put into this new release of WordPress. I can’t wait to see how much more I can do as I continue developing under it during the weeks and months to come.