In all the lists bellow, red templates are added by Index module.

When module is active, templates loading is changed to include additional templates. Hierarchy is changed to look like this:

• archive-{post_type}-cpt-mod-index.php
• taxonomy-cpt-mod-index.php
• archive-{post_type}.php
• archive.php
• index.php

By default, WordPress would use ‘taxonomy-cpt-mod-index.php’ or ‘archive.php’ templates. Module added template specific for each post type, and adder post type archive also.

xScape Theme framework includes ‘taxonomy-cpt-mod-index.php’ with display of indexer for active post type.

Index Module Settings

Index is a plugin that adds new taxonomy through GD CPT Tools Pro plugin, and this taxonomy has no UI (no meta box or panel with terms). But, in the background this taxonomy is used to index posts belonging to post types you want to use index. Once the module is activated, each post type will get Index option on the new modules tab. Also, each post type with Index module active has new option to reindex posts and initially set terms (background cron job).

So, each post will get a term based on the first letter (or number) in the post title. You can set module to skip some characters in the start of the title, and module supports unicode. Also, you can control how to handle numbers (under one term or with individual terms), how to create terms (what slugs to use). With each post type settings you can override list of characters to skip from the title beginning.

Since the taxonomy is registered through GD CPT Tools Pro, and module is hooked into many different areas from the plugin, you can modify taxonomy to fit your needs: you can change everything about it, including adding special features, change rewrite slugs and more.

As for the display part, module adds new templates and functions that render index to use inside the theme files. Tutorial on that is coming by the end of this week. You can see demo for the Index module in the Centeral Documentation.

This module is available for free to all users with Developer or Enterprise licenses for GD CPT Tools Pro plugin or Dev4Press Plugins Pack. If you have Personal or Standard license, you can purchase module. Module license is tied to plugin/pack license, and you can download it and get support for it only if the plugin/pack license is valid.

If you have any questions, you can use the comments bellow or the forums (new Modules forums are added).

Term tagger

New GD Custom Posts And Taxonomies Tools Pro version brings integration with OpenCalais API for use with the tagger expansion of the tags/custom taxonomies meta boxes with some other improvements. gdr2 library is updated to latest 2.7.4 and jQueryUI to new 1.8.20.

jQueryUI hasn’t been updated for more than 6 months and new version fixes several display problems with datepicker and popup controls. Also, there was an issues with loading of some of gdr2 classes, and some things were loaded even when they are not needed, causing problems to some of our other plugins. New gdr2 is included and loading issue is gone.

To start using new OpenCalais API to get terms, you need to register for a free account and an API key here: OpenCalais API registration.

If you notice any problems, please leave comment or report them in the forums.

Enhanced search result feature is removed due to the conflict with the search in some cases. And, you can use default ‘Exclude from Search’ option each post type has. This option is on Settings tab, Visibility group of settings.

If you notice any problems, please leave comment or report them in the forums.

Post Types Panel

Image above shows the new layout for the post type editor panel. And, as you can see, it shows information a bit differently with options grouped logically. Taxonomies and meta boxes are listed now with name and label. Similar thing is done with the taxonomies panel.

Tooltip

To help understanding options, tooltips are added for all the links on the panel, like on the image on the right. From the same image here, panel has a new option for templates in the theme for the post type. For now, this shows what templates are needed for this post type, so you will know what file you need to make and customize.

Another new thing is new custom field type for resolution. When in the meta box, it will show X and Y values to enter. More custom fields are coming in future versions.

If you notice any problems, please leave comment or report them in the forums.

Before we go on, here is the previous article on rewriting:
How WordPress URL rewriting works?

Date based archives by default, work only with the default posts post types, and they look like this:

Year archive: http://www.example.com/2011/
Month archive: http://www.example.com/2010/10/
Day archive: http://www.example.com/2012/02/22/
Month archive, feed: http://www.example.com/2010/10/feed/
Year archive, page 2: http://www.example.com/2012/page/2/

But, to get similar URL’s for the custom post types, will not work. Also, each of theses URL’s supports pages and feeds as you can see on the last two examples.

If we have post type names ‘movie’, and for the post type archive slug we have set ‘movies’, you expect to get these date based archives for it:

Year archive: http://www.example.com/movies/2011/
Month archive: http://www.example.com/movies/2010/10/
Day archive, feed: http://www.example.com/movies/2012/02/22/feed/
Year archive, page 5: http://www.example.com/movies/2011/page/5/

Such URL’s will filter posts by post type and date, returning date based archives for a post type. But, it is not that hard to do this. What’s more, there are two ways you can do it: using a plugin and doing it your self with custom coding.

Using GD Custom Posts and Taxonomies Tools Pro

If you prefer to do things from the comfort of the admin interface, and if you need to do this for many post types, my GD CPT Tools Pro plugin is a best solution. You can add and manage any number of custom post types and you get long list of extra features plugin implements, including custom rewriting that includes date based archives.

GD CPTTools Pro: Enable Date Based Archives

For each custom post type, plugin includes many more rewrite options. On the rewrite tab, you can set up permalink structure for single posts, and you can control archives for post type. Simply enable the Date based archives checkbox (like on the image on the right), save post type, and plugin will generate rules for these archives.

If you want to check the rest of this plugin features, you can do it from here:

Do it yourself with example code

If you prefer to do this yourself, here is the code that GD CPT Tools Pro uses for the date based archives. For the year, month and date archives you need one extra rewrite rule. And, if you want to have feeds and pages for them, you need 3 more rules for each one. So, in total there are 12 new rules for each post type for the date based archives. For this to work, we need to hook into action ‘ generate_rewrite_rules ‘:

add_action('generate_rewrite_rules', 'my_datearchives_rewrite_rules');

function my_datearchives_rewrite_rules($wp_rewrite) {
  $rules = my_generate_date_archives('movie', $wp_rewrite);
  $wp_rewrite->rules = $rules + $wp_rewrite->rules;
  return $wp_rewrite;
}

This code attached  ‘my_datearchives_rewrite_rules’ function to ‘generate_rewrite_rules’ action. On line 3, we call another function that will generate rules for a post type ‘movie’. We than add those rules to existing WP rules, and return rewrite object. Now we need the function that generates rules for specified post type.

function my_generate_date_archives($cpt, $wp_rewrite) {
  $rules = array();

  $post_type = get_post_type_object($cpt);
  $slug_archive = $post_type->has_archive;
  if ($slug_archive === false) return $rules;
  if ($slug_archive === true) {
    $slug_archive = $post_type->name;
  }

  $dates = array(
            array(
              'rule' => "([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})",
              'vars' => array('year', 'monthnum', 'day')),
            array(
              'rule' => "([0-9]{4})/([0-9]{1,2})",
              'vars' => array('year', 'monthnum')),
            array(
              'rule' => "([0-9]{4})",
              'vars' => array('year'))
        );

  foreach ($dates as $data) {
    $query = 'index.php?post_type='.$cpt;
    $rule = $slug_archive.'/'.$data['rule'];

    $i = 1;
    foreach ($data['vars'] as $var) {
      $query.= '&'.$var.'='.$wp_rewrite->preg_index($i);
      $i++;
    }

    $rules[$rule."/?$"] = $query;
    $rules[$rule."/feed/(feed|rdf|rss|rss2|atom)/?$"] = $query."&feed=".$wp_rewrite->preg_index($i);
    $rules[$rule."/(feed|rdf|rss|rss2|atom)/?$"] = $query."&feed=".$wp_rewrite->preg_index($i);
    $rules[$rule."/page/([0-9]{1,})/?$"] = $query."&paged=".$wp_rewrite->preg_index($i);
  }

  return $rules;
}

To fully understand this code, you need to understand PHP regular expressions, but if you just want to use it, no worries, it is all here and this function doesn’t need to change. Let’s see what is going on in this function. Function is called with two arguments: name of the post type ($cpt) and the WP rewrite object ($wp_rewrite).

First, we need to find out what is the slug for the archives URL for this post type ($slug_archive). If you have disabled archives for post type, this function will exit on line 6. If the archives are set to use custom slug, function will use that, or it will use post type name (lines 7-9). Lines 11 to 21 are used to set up day, month and year based regular expressions rules and variables to be used in the query. First one is for day and it needs year, month and day, month based needs year and month, and year based only year. After that, we go through these 3 archives types and we generate rules for them. In the rule part we use regular expressions, and it uses ( and ) to separate capture groups. Each capture group provides a value for us to use, and each of these values need query variable in the query part of the rewrite rule.

Line 24 sets up the base for the query using post type name and on 25 we set up base for the rewrite rule using post type archives slug and the rule for the archive. Now, we need to add to the query all the variables needed for the rule (27 to 31). This builds the basic rewrite rule and rewrite query rule point to. Lines 33 to 36 are setting up rules for basic archive rule, feeds and pages. Feeds and pages need extra bits for the regular expression to detect feed or page, and extra query variable for feed or page. If you don’t want to have feeds for these date based archives, you can remove lines 34 and 35. Line 33 adds basic rewrite rule, and line 36 adds pages for archives, and you need to leave these two in place. After all the rules are generated, they are returned back to the rules in ‘ my_datearchives_rewrite_rules’ function, merged with WP rules and ready to use.

Whenever you make changes to rewrite rules, you need to instruct WordPress to rebuild the cached rules. To do this, it is enough to open Permalinks panel on the WordPress admin side under Settings. If you use GD CPT Tools Pro and its rewrite features, this plugin will flush rules on its own when needed.

Conclusion

Adding extra rewrite rules is not that complicated as you can see from this practical example. Depending on what you need, you need to learn (at least basics) PHP regular expressions and to make sure that query for the rule has sufficient number of variables to correspond to the number of capture groups in the regular expression. If you don’t want to lose time over this, and you need these extra rules, get yourself GD Custom Posts And Taxonomies Tools Pro and add new features with just a few clicks.

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.

Meta box displayed on the post editor and in the bbPress integration now use 8 actions: top and bottom of meta box, top, bottom and after each custom field in the box. All these actions will be described in documentation very soon. As for Subscribe2 plugin, just enable the enhanced feature for it, and plugin will register post type for Subscribe2 notifications.

Next 3.5.4 and 3.5.5 version will have several new features that was requested by several users: custom field to select post from any post type. This was planned for this version, but I wanted to release this version sooner since some users required included new features.

GD Custom Posts And Taxonomies Tools Pro:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/

bbPress

bbPress plugin version is quite different than normal bbPress, now it uses post types for forums, topics and replies and adds topic tags as taxonomy for topics. One of the features finished plugin will have is to convert data from old bbPress into new format so that the switch will be done easier to a new plugin based version.

Current version of bbPress plugin uses default TwentyTen theme to add extra templates and rendering elements. I am using same approach for xScape, and framework will contain bbPress elements that will be shared across all themes, and will have a module that will add templates and control other settings as needed. If you use bbPress, this module will add extra templates needed by bbPress and allow for same level of customization as with normal WP based templates. Biggest issue is to create template elements that will use CSS BluePrint layout that will be save regardless of the theme and theme specific BluePrint settings. Also, theme will include styling for bbPress added widgets. Another great thing about this is that upcoming GD Star Rating 2.0 will support bbPress plugin also.

Theme R8 will be used for first integration tests and I will release development snapshot for testing next Monday, but it will take some time to sort it out, and also bbPress plugin is not yet done, so changes will be added along the way. xScape Roadmap is updated, and the integration should be fully done for final release of xScape Theme Framework 1.7.

WordPress 3.1 will include (and it does in current RC versions) support for archives for post types. GD Custom Posts And Taxonomies Tools Pro added support for that a while back and it works with WP 3.0 and WP 3.1. But, if you use WP 3.1 already, you might wanna use official archive support, so you can choose what you prefer. If you used templates supported by GD CPT Tools plugin, they will still be available since plugin will expand support for them in case has_archives is used.

Plugin is tested with WP 2.9.2, WP 3.0.4 and latest WP 3.1 RC3. If you have any more problems, please report them in the forum or in comments. Always include exact version of WP you are running, especially if you are using development versions of WP.

GD CPT Tools

Notice:  GD Custom Posts And Taxonomies Tools 2.6 Pro will be out soon with few new features (including export for taxonomies). But, this new version will drop support for WP 2.9. No new features will be compatible with WP 2.9, so while you are using that version there is no need to upgrade to newer version than this current 2.5.3.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt

Post Type

Changing post type is useful if you need to move some older posts to new post types. But, you need to be careful with it because you can loose data during this depending on the features set for custom post types. Option is disabled by default, so if you need it you need to enable it.

If you have any more problems, please report them in the forum or in comments.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt

Custom Post Types Widget

New widget is very simple, and result is on the image on the right. You can change widget title, display of posts counts and select post types to include in the list.

I am working on the demo website that will showcase changes and customization to a xScape based lightScape theme, this plugin and GD aZon FUSION. It will be ready by the end of this week.

Please, test new features and report problems in the forum or in comments.

GD Custom Posts And Taxonomies Tools:
http://dv4p.com/gdtt