By now, you’ve probably heard the hype about WordPress 3.0. You may have even seen the WordPress 3.0 preview webinar I did not too long ago.
This is somewhat of an odd release as I can’t point to 10 individual new features in WordPress. However, I can point to several very large new features that have been hyped enough already. Inside each of these new major things, there are several components. So, let me break the ten things down into three groups. We’re a little behind schedule (thanks to Jane Wells’ cat below) but I think the wait is worth it.
The Merge! WordPress and WordPress Multisite Together At Last
Back at WordCamp San Francisco last year (which is happening this weekend and I will be at), Matt Mullenweg announced that WordPress and WordPress MU would be merging into one singular software package. I covered that shortly after the announcement. The reasoning was that all of the WordPress core was already in sync with WordPress MU and MU simply had a bit more functionality added to it. Most of the code is the same. Why split resources and developers?
WordPress 3.0 is where this merge takes place.
While this is not a new feature in WordPress, existing WordPress MU users may find themselves “thrown” by new terminology involved in WordPress 3.0. In WordPress MU, we had the concept of a “Site” which was an installation of WordPress MU. Within a Site you could have one or more blogs.
In WordPress 3.0, we have the concept of a Network (which was a Site in WordPress MU) and under a Network, we have Sites (which were Blogs). Sites are Blogs. Networks are Sites. Site Admins in WordPress MU are now called Super Admin’s in WordPress 3.0. Making things complicated, we don’t call it WordPress MU anymore. We call it putting WordPress into Multisite mode. Complicated, eh? New WordPress Core Developer, Andrew Nacin, describes this terminology nightmare.
Something that is bound to be confusing for users who expect to simply install WordPress and get all the benefits of Multisite out of the gate are bound to be confused by the fact that there is no apparent “switch” to turn it on. When you install WordPress 3.0, it will be in standard WordPress mode. In order to flip the switch, you have to add a new constant to your wp-config.php file. It’s easy, just add the following and save:
Once this is done, you’ll find a new menu item called “Network” in your Admin under Tools. Visit this page, enable Multisite and follow the instructions. You may need to add new configuration settings to your .htaccess file and wp-config.php, but WordPress will provide these lines for you to copy and paste.
Note: As with WordPress MU, you may need to make server level system changes to enable WordPress to handle subdomains. This is not an easily solved problem and caused heartburn with MU users and will likely continue to cause heartburn with WordPress 3.0 users as well.
Upgrading from WordPress or WordPress MU 2.9 or below
A lot of people, including myself, were concerned about upgrade paths when the Merge was announced. I should have known not to be concerned. WordPress has taken great care for years to ensure backwards compatibility and we’ve done the same thing here. If you’re on WordPress or WordPress MU, you will be able to install WordPress 3.0 and upgrade seamlessly. WordPress MU installs will become WordPress 3.0 with Multisite enabled and single installs of WordPress will retain all the benefits of standard installs of WordPress.
WordPress as a CMS: Custom Post Types and Taxonomies
Developers are already very excited about the new APIs available in WordPress 3.0. Specifically, Custom Post Types (which received initial support in WordPress 2.9). This is a very important set of new features because it finally – finally! – brings CMS support to WordPress. For the first time, we don’t have to simply pretend that WordPress is a CMS…. it can have all the CMS qualities of a Drupal or Joomla.
Custom Post Types
We initially talked about custom post types in WordPress 2.9 but in WordPress 3.0, the feature is fully vetted and able to be utilized. With a simple function in a plugin or theme, developers can create new post types (such as film reviews, podcasts or FAQs), provide entirely familiar UI (similar to posts and pages), etc.
You can find all the possible options under register_post_type() in the wp-includes/post.php file.
Going hand in hand with custom post types, you can also create custom taxonomies. Taxonomies are bits of metadata and most people think of them in terms of ‘categories’ and ‘tags’. Built into WordPress already are three taxonomies – categories, tags and link categories (which most people think about). The difference, from a technical perspective, between tags and categories is hierarchy. Categories have hierarchy so a category can have a child category, etc. Tags are flat and have no hierarchy.
You can create custom taxonomies with the register_taxonomy() function which will create UI automatically. All the options for custom taxonomies can be found in the wp-includes/taxonomy.php file.
Note: I have created a plugin and made it available for download that demonstrates how to use custom taxonomies and post types.
User Facing Enhancements
There are two major user facing enhancements. When I say two major user facing enhancements, I’m not being sensational. These things are killer and I think you’ll be excited.
Wow, this has been a controversial new feature. Mostly because it almost didn’t make it into WordPress 3.0 and users have really, really wanted it. Those familiar with the navigation creator in many of the WooThemes will be familiar with the new Menus feature in WordPress. This is because we worked early on with Woo to adopt their premium theme feature, which was very good, into the WordPress core (a fantastic case study on how premium theme developers can work directly with the WordPress core team).
The idea is really simple: Compose any menu with any hierarchy out of category archives, pages and custom links. Once a menu is created and saved, theme developers can enable support for this feature with the following line:
Dropdowns are automatically created and semantic CSS markup allows style modifications easily. You can also create multiple menus (let’s say, a secondary navigation piece) and use them as sidebar widgets or hardcode them directly into a theme.
Default theme… no, no default theme… no, new default theme!
Well, you know all those free themes over on the theme repository? Yeah, most of theme are heavily modified versions of Kubrick, the default theme for WordPress. Theme people would take the code base, modify it and make it their own. They might upload it to the theme repository. Problem is, they would not be updated with the new stuff that would go into Kubrick. That and Kubrick sucked as a theme.
Well, as of WordPress 3.0, there is no more Kubrick. There also is no more Classic theme. Now, we have a new theme called twentyten. Yes, that means next year, we’ll have twentyeleven.
Twentyten is a very complex theme. It should not just be duplicated and hacked up. We want themers to adopt the child theme method of doing things. This is important because as changes go into twentyten, your child theme will inherit those changes. Here’s a good starter for how to build child themes.
Note: If you are upgrading from previous versions of WordPress and have a child theme based on Kubrick, don’t delete the default theme. If you do, you can still grab the theme from the theme repository.
WordPress Admin Enhancements
The WordPress Administrative interface has also seen enhancements. Jane Wells is our usability expert in the WordPress developers group and has done quite a lot of work. Minor enhancements include an all light-grey style color scheme (as opposed to the dark grey header bar). This does seem to be better on the eyes. Additionally, the themes interface also has a new “tabbed” interface.
Built into twentyten is a new custom background feature. The cool thing is, theme developers can include this feature in their own theme. Simply adding this function to your theme functions.php will add a new menu item to your Appearance menu that allows for quick modification of the background image on the blog.
Of course, not everything can fit into the three main areas of feature adds. Some are important and just don’t fit anywhere else.
Many of the security problems that have occurred in WordPress’ history have been a result of the administrative username being admin. This has not been selectable or changeable without hacking the database and changing the admin username there.
In WordPress 3.0, the username can now be selected on install. Here’s a hint…. don’t name it admin. :)
For a complete list of expected changes, see this Codex page.