Before we go on, here is the reminder for the article published yesterday about upcoming WordPress:
What will we get with WordPress 3.4?

This list is based on the features requested by WordPress community, and things I consider important. This features are in circulation for over a year now, and still most of them are not even mentioned in the future development plans. Problem with most of these features is that they need much more time to do, and current quick development cycles core team insist on are simply not long enough to make these things happen.

• Replacing outdated and no longer maintained ThickBox with jQueryUI Dialog. This is actually something that was in works, and from what I have seen, it should be ready for the next WP 3.5. ThickBox popups are very complicated to control and they lack many features that jQueryUI Dialog popups can do. Replacing them would be great. But, that will also cause all sorts of problems for plugins developers, because most of the code using ThickBox will not be compatible with new popups. Colorbox is also a good way to go to make popups, but I would prefer jQueryUI approach, considering  how much WP relies on jQueryUI already.
• Custom post types posts relationships. This is very, very important feature that will move WordPress in the field of full-fledged CMS systems. Right now, you can’t connect posts directly and with more and more popularity custom post types gain, this is a very important addition. There are several plugins for this, all implementing this differently, but this is something that must be in the WordPress core. This would need additional database table for bridging posts.
• Meta data for taxonomies terms. There was some talk about this, but it was always dismissed when plans for next WordPress were made. Right now all data types in WordPress have meta fields (users, posts, comments) with the exception of terms. It would be very beneficial to have those. This also would require another database table.
• Improved media library. This can be found on most WordPress wish lists on the Internet. I don’t have too many complaints to Media Library, but there are many things that can be improved, including attaching one image/file to more than one post. Other important improvements would include: user controlled folder structure for storing files (not only dates based as it is now), with improved URL rewriting rules that can hide wp-content from the URL. Also, real galleries implementation would be of great benefit for media library.
• Shared resources between sites in multisite. It would be of great benefit to have central media library with assets and images that all multisites can use (logos for instance). Only super admins get to control that, but any site admin can use those resources. Beyond files, sharing can be done for taxonomy terms, maybe even pages and posts to some extent. This can be useful if you have same Terms And Conditions page that any site in the network can use as its own.
• Improved posts management. Right now, posts lists on the admin side are real pain to use when you have large website with thousands of posts. Changing category for hundreds of posts at the time is impossible. We need better system that would allow simpler and more powerful filtering on that page and operations that go beyond current, flawed bulk operations (if you want to bulk edit 10 or 15 posts, you can wait good minute or two before you can do anything, and some browsers can freeze with bulk edit).
• New Taxonomies Terms management. This current is very bad, and if we get meta data for terms, this current interface must be replaced with something that is actually usable for website with large number of taxonomies and terms.
• Real search. Maybe the worst thing in WordPress is absolutely useless search feature. There is no need to explain how bad it is, and how much we need something useful to search posts. We need full text indexing, some search operators, easy set filters for post type, custom fields or taxonomies terms. There are some plugins for this, but this is a feature that should be in the core.
• Remove Akismet from core distribution. Akismet is a commercial plugin, and for most websites, it must be purchased to use. Bundling it with WordPress core is not fair to all the other commercial plugins developers. Considering that many users prefer solutions that work on site only with no remote servers involvement, there are better solutions that Akismet, and also free solutions.

And what we should not see in future WordPress version (for a while at least):

1. We don’t really need new core themes. TwentyTen is great, and TwentyEleven is awful. I would like to see TwentyTen as HTML5 theme and be done with it. From what I have seen of TwentyTwelve, I am not impressed.
2. No more cosmetic admin side changes. We need real changes to posts lists panel, taxonomies terms pages, leave the rest of WordPress admin as it is. It looks great as it is now.

With few teams working only on these features, I think (based on earlier development cycles) that these would take 9 to 10 months (maybe a year) to implement and test properly. Also, having longer beta testing period for it would be beneficial to convince larger group of users to switch to new version when it gets released. And I am sure that powerful set of features would be the best incentive for adopting new WordPress.

What do you think about these features? Would you prefer to wait longer for a WordPress that comes with most of these things, than to waste time on small updates as we have now? Let me know with a comment.

Taxonomies terms filtering can be done only for taxonomies that are registered as public, and have set query variable. Query variable is the same as taxonomy name by default, but it can be registered to be anything as long as it is clean and URL safe (query variables are used in URL, so they can’t contain empty spaces or special characters). For instance, default WP taxonomies – category and post tags have query variables - category_name and tag.

URL Query

Taxonomies query variables can be used in URL like this:

// archive for category with name 'news' //

http://www.example.com/?category_name=news

// archive for category with name 'news' and post tag with name 'latest' //

http://www.example.com/?category_name=news&tag=latest

You can use more taxonomies in the URL like this, and you can even specify multiple terms separated by comma. But, the more terms you try to filter, number of posts will be smaller, and if you specify filter that gives no results, you will be redirected to 404 page (or to empty archive with no posts message).

Override the WP Query

It is useful to be able to override already prepared query and add filters for terms. This way you can modify query for archives by adding additional conditions. To do this, you need to use ‘pre_get_posts’ action, and to modify query arguments with function attached to that hook. Here is the example.

add_action('pre_get_posts', 'example_pre_get_posts_simple'));
function example_pre_get_posts_simple($query) {
  $query->set('tag', 'latest,wordpress,video');
  $query->set('category_name', 'news');
}

This example will expand query with filters for 3 terms belonging to post tags (comma separated strings: latest, wordpress and video) and one term belonging to category. Based on this Query class will generate tax_query object that contains elements that will be used to filter posts by taxonomies you have set and taxonomies that were already in the Query object before you hooked into it with pre_get_posts action. You can even modify tax_query with this hook, but that is not recommended because parsing taxonomies will be done once again after pre_get_posts. Still, it can be done, but you need to make sure you preserve old tax_query variable before adding your own. Tax_query elements are much more complicated than the example above, and you can specify relations for the terms and you can specify terms with ID’s or name, not only slug. Third method bellow shows how to get posts using custom tax_query array.

Using get_posts function

This function has many different ways to filter using terms. Function get_posts has an array of arguments, and there is a long list of parameters you can use with it, so you can specify posts count, post type, tags, categories, post ID’s and much more. First few examples are simple ways to specify terms:

//use category ID:
$posts = get_posts(array('category' => 1));

//use category slug with category query variable:
$posts = get_posts(array('category_name' => 'news'));

//use category slug and post tags slugs for 3 terms:
$posts = get_posts(array('category_name' => 'news', 'tag' => 'latest,wordpress,video'));

You can add more things here including custom taxonomies, using query variables for those custom taxonomies. Full list of parameters you can use can be found here: WP Query Parameters.

Another thing you can do is to specify terms using tax_query array. This allows more flexibility in specifying terms. Tax query is actually array of arrays. Each array is to specify the taxonomy terms and it is in form of array that has few parameters of its own. Each tax_query array can have 5 parameters:

• taxonomy: name of the taxonomy, actual name, not query variable
• field: it can be slug or ID, and it is used to define what is used to specify terms
• terms: single ID or slug, or array with slugs or ID’s based on field parameter
• include_children: should the children of terms be included, only for hierarchical taxonomies, and by default is set to true
• operator: what operator to use in SQL query to link the specified terms: ‘IN’, ‘NOT IN’, ‘AND’

So, here is the example with two taxonomies:

$args = array(
  'tax_query' => array(
    array(
      'taxonomy' => 'post_tag',
      'field' => 'slug',
      'terms' => 'latest,wordpress,video'
    ),
    array(
     'taxonomy' => 'category',
     'field' => 'id',
     'terms' => 1
    )
  )
);
$posts = get_posts($args);

This will filter posts using 3 terms for post tags, specified by slugs, and by one category specified by ID.

There are a lot of possibilities to filter posts by multiple taxonomies and multiple terms. You need to choose method which works best for you, depending on what you need to do and how to filter posts, and be careful with listing multiple terms: more terms in the filter, the less posts you will get, or you will get no posts due to number of filter rules, and you can get to 404 page with no results.