Happy New Year, everyone. WordPress development on version 3.1 is wrapping up (Currently it’s in Release Candidate and should be released early in 2011)…. which means, it’s time for another edition of our 10 Things You Need to Know About posts.

This is a bigger release than was originally planned. It was supposed to stay small and set the stage for a larger WordPress 3.2 release later in the year. That release will require PHP 5.2 (make sure your host supports it now… We do at WP Engine. WP 3.1 did turn into a larger release than expected, but I think you’ll be happy. So without further adieu.

Network Admin

if you’re running WordPress in Multisite mode, or have used WordPress MU for a while, you may find yourself alarmed by the conspicuous lack of a Site Admin/Super Admin menu that has been situated at the top of the Admin menu. Never fear, though it looks like this has gone the way of the dodo, in fact it has been relocated into a separate dashboard area accessible from the new “Network Admin” in the top right of the WordPress Admin. Notably, when you click on this link, you are taken to a new dashboard for Network management (and that link then changes to Site Admin to allow quick access back into the normal WordPress admin. Also note that, like the previous Super Admin menu, this link is only viewable (and by proxy, accessible) to users who have been designated as Super Admins. This change allows for additional separation of content production and administration and allows for blogs (Sites) to be managed individually and the Network to be managed separately.

Post Formats

Perhaps one of the most talked about features in WordPress 3.1 are post formats. Post formats have been implemented in a variety of ways for years. The idea that some content is different (and should be rendered differently as a result) has gone way back. A prime example of this was the concept of “Asides” – or little blurbs that were often simply links or short posts that were off topic, not really worth a full blog post or whatever. Now, with a bit of code in a theme functions.php, you can enable any number of 9 different formats: aside, chat, gallery, link, image, quote, status, video, or audio.

In this paradigm, theme developers can target specific CSS and layout structure to each of these post formats. This enables rich user experience and high quality layout without prejudice toward the most common type of content… text. If you aren’t sure what each of these types of content are, I refer you to the Post Formats section of the Codex which has a list.

In order to enable a theme with one or more of these formats, add the following line to the theme functions.php file:

This line enables new UI in the post edit
screen that allows for you to designate a post with a specified format. For a thorough write-up on this new feature, go read the post format reference from my friend Lisa Sabin-Wilson.

Internal Linking

Have you ever gone through the torturous process of adding links to your own site to a post you’re writing? You have to go find that post from a different tab or window, usually via search or scrolling through potentially pages of content to find exactly what you want? Yeah? Me too. As a result, WordPress has added Internal Linking as a feature to WordPress 3.1.

This feature, only available when using the Visual Text Editor, allows you to add a link as you always have, or choose from already existing content on the same page. Yeah… that easy. Simply click the typical link button, then click on the arrow to
expand the “Link to Existing Content” section of the pop-up window. Pretty neat!

Import Overhaul

In advance of WordPress 3.2 and PHP5 dependence, we see yet another improvement that rewards WordPress users who utilize hosts using PHP5. The import routine has been rewritten from the ground up with efficiency in mind. While the old importer used regular expressions to parse through the WordPress export file (XML), this caused really bad efficiency problems.

Now, using native XML parsers, the WordPress import can process files much more efficiently. Additionally, similar to the file system transport API that is used by the one click installer and upgrade routines, WordPress goes through a series of checks to find the best method for XML parsing available on the server, thus a progressive enhancement for PHP 5. The first check is for SimpleXML (PHP5-only) followed by XML Parser (used in PHP 4) and, if neither of those two libraries are enabled, it falls back on the old, antiquated regex parsing.

Editorial Comment: I was hoping for a rewrite for 3.2 to both the exporter and importer that would handle everything in JSON (a much more lightweight plain text file format), perhaps optionally, instead of XML. XML parsing by nature, regardless of SimpleXML or XML Parser, is quite expensive in terms of CPU cycles and efficiency.

Theme Filter

WordPress.com users are probably familiar with the theme filter that those bloggers have had access to. With Theme Filters, users are able to quickly drill down on possible themes to install and use based on criteria such as number of columns, features, etc. To access this, simply click on the Feature Filter on the right side of the themes page to display all the options that are available. Note for Theme Developers: In order to make this useful for bloggers, please ensure that your theme style sheet headers include a Tags header similar to this:

Advanced Taxonomy and Postmeta Queries

WordPress wouldn’t be complete without enhancements for developers as well. In WordPress 3.1, developers have access to powerful new features that provide for robust querying of both taxonomies and postmeta. In previous iterations, developers could target posts with WP_Query (or the Loop) to only those posts that have meta_key=foo or meta_value=bar.

The problem was, the potential for more granular targeting (i.e. get only posts with meta_key=foo AND meta_key=bar AND published BETWEEN Jan 1 of 2007 and Jan 31 of 2002) was not possible. Now it is. Replace meta_key and meta_value with meta_query and feed it in an array of arrays that contain any of key, value, compare (comparison operator) and type (data type). This will cause the query to automatically drill down with more granularity on the content requested.

The same can be done with taxonomy queries. Instead of meta_query, however, use tax_query and instead of key, value, compare and type you would use taxonomy, terms, field and operator. Otto has a good explanation for that on his site.

User Queries Overhauled and Simplified

Anyone who has done plugin development that has needed access to users have had a hodge podge of functions like get_userdatabylogin(), get_user_by_email(), etc. Not a lot of consistency, and definitely something that required frequent referencing of code. Now, from the “Duh! Why Didn’t I think of that?” file, comes the get_users() function that simplifies that API. It also wraps around a more powerful class for user search and querying called WP_User_Query.

To leverage this new API, you simply pass an array to get_users() and it returns an object based on the dataset retrieved. Arguments in the passed array can be:

• blog_id – defaults to the blog id of the current blog (always 1 when WordPress is in standard mode but maybe another number in Multisite mode.
• role – administrator, author, editor, subscriber, contributor. Defaults to nothing.
• meta_key – allows for usermeta comparison and defaults to nothing.
• meta_value – allows for usermeta comparison and defaults to nothing.
• meta_compare – allows for usermeta comparison and defaults to nothing.
• include – an array of user IDs to search. If empty, it searches all users. By default, it’s empty.
• exclude – similar to include, this is an array of user IDs to not search. By default, it’s empty.
• search – provides a way to target how columns are targeted. If, for instance, *max* is passed, wildcard searching is done in user_login, user_email, etc. By default, it’s empty.
• orderby – specifies which column the results should be sorted on. By default, it is ‘login’ which designates the user_login column.
• order – ASC or DESC. By default, queries are returned in ASC order.
• offset – Designates a number of records to offset in the resulting dataset. If set to 1, for instance, the data will be returned with the first record skipped and begin on the second. By default, this is empty.
• number – Designates how many records to return.
• count_total – if set to true, the number of records returned is included in the dataset. By default, this is set to true.
• fields – designates which fields to search. By default, this is set to ‘all’

Admin Bar

For those of you who have been WordPress.com or BuddyPress users, you’ll be familiar with the admin bar. The Admin bar is a toolbar that goes across the top of the site that allows users quick access to other parts of their blogs. That Admin Bar has now been brought to WordPress 3.1 as a user setting so it can be turned on or off based on preference
in your user profile.

In Multisite, the default is to show the admin bar in both the wp-admin as well as on the front end. In standard mode, the admin bar is set to only display on the front end by default. The Admin Bar, by default, provides quick access to a User menu providing a quick link to the user profile as well as the dashboard and the ability to logout. There is also a My Sites drop down menu available in Multisite that allows users quick access to blogs they have access to. There is also Admin Bar access to other frequently used areas of the blog and plenty of hooks and filters for plugin developers to add additional access.

Improvements to Custom Post Types

In WordPress 3.0, custom post types were introduced and now they have been iterated on. For one, in WordPress 3.0, custom post types could be declared but a standard set of UI was added to the admin menu. This set of UI was fashioned with an edit menu (called Posts for the standard Posts UI), Add New and, if custom taxonomies were assigned, Categories and Tags (or
whatever those taxonomies were designated as).

Now, developers can add a show_in_menu argument when registering a post type, and designate which menu to display limited UI in. This allows for custom post types to be used with the flexibility of eliminating potentially unwanted UI that would clutter the menu. Andrew Nacin has a great writeup on admin menu changes with post types that is worth the read for any developer working in this area.

Related, when declaring a post type, you have traditionally had to pass an array of labels that designate a singular version of a name (i.e. Post vs Posts) as well as a common name (i.e. Posts). You can now add menu_name to that list of labels if you want to target a specific way of displaying the post type in the admin menu.

Finally, theme developers can now create template files named archive-{post_type}.php to target specific post types to specific templates. Utilize a new has_archive() function to determine what should be displayed when there are actually posts that match the criteria of the query or not. This gives a good way of providing some kind of 404ish or other content if no content for the post type exists.

Filterable Template Hierarchy

Speaking of template files, it’s now possible to designate different template file orders and hierarchy depending on need. The original ticket, patches and ultimate core addition, uses the following example:

Take the author template hierarchy: author-{nicename}.php > author-{id}.php > author.php

Say I want to add author-{role}.php before author.php.

With an ‘author_template_candidates’ hook, I could manipulate the actual hierarchy.

Thus was born the ‘{$type}_template_hierarchy’ filter which can be used by developers to insert author-{login} before author.php in the hierarchy by hooking on the filter ‘author_template_hierarchy’. Pretty Neat!

Conclusion

While WordPress 3.1 is not the biggest release in the history of WordPress major releases, it does add quite a few new toys for bloggers, as well as developers. Remember when upgrading that you should, if you can, test your site in a development area before doing the upgrade. Plugins should most likely work, but you never know. And if something is broke, you can email me a aaron@technosailor.com and, for a fee, I may be able to help you out.

Finally, the second edition of the WordPress Bible will be out sometime this spring and it does, in fact, cover WordPress 3.1. However, the 1st edition is available now and is a great resource if you’re trying to get under the hood. You can buy that today on Amazon.

Credit: Andrew Nacin (@nacin), a Core WordPress Developer, slapped me with a trout several times during the course of writing this article. While I take credit for the article, any inaccuracies are entirely his fault. ;-) #blamenacin