Archive for July, 2008

WordPress 2.6 Released

Nice timing!  Just as I am about to go on vacation and don’t have much time (and only a very slow computer) they go and release a major new version of WordPress!  Ah well, I have managed to perform a quick test with both of my plugins on the new version and I am happy to say that:

  1. AZIndex seems to be working fine, and
  2. TinyMCE Entities Patch is obsolete

Yes, it’s actually good news that my TinyMCE Entities Patch plugin is no longer necessary — WordPress has fixed the bug my plugin was designed to fix.  I may get the chance to update the plugin tomorrow so that those who installed it so they could keep the spaces around will still be able to use it, but I can’t promise anything at this point.

UPDATE: Well, I spoke too soon yesterday — there was a problem that many other plugins also seem to have stumbled over thanks to a change in the get_option WordPress function (naughty WordPress!).  I have updated AZIndex to v0.5.4 with a workaround for the problem on WP 2.6.  The plugin should continue to work with WP 2.5 and WP 2.5.1, and with WP 2.6 even if they revert the behaviour of get_option back to the way it was in 2.5.1.

AZIndex 0.5.3 Released

AZIndex LogoAZIndex version 0.5.3 has just be released.  It’s just another interim version as I am gearing up for my summer vacation, mainly to fix a bug where the sorting of the headings was case-sensitive.  I’m not sure how that one escaped detection for so long!

I also took the opportunity to add a filter to the plugin — ‘azindex_heading’ — which, if set, will be called for every heading before the index is sorted.  This allows users to write a filter function that can modify the heading in ways that can’t currently be done using the AZIndex plugin — for example, if you want to strip words like “A”, “An” and “The” from the front of the heading then you can write a simple filter to do that.

Below is an example of such a filter.  It will remove “The”, “An” and “A” (of various cases) and put them at the end of the heading instead — e.g. “The Great Escape” will be transformed to “Great Escape, The”.  Useful for certain types of indexing:

add_filter('azindex_heading', 'my_filter_heading');                  

function my_filter_heading($heading) {
   if (preg_match('/
^(THE |The |the |AN |An |an |A |a )/', $heading)) {
       $split = explode(' ', $heading, 2);
       $heading = $split[1].
', '.$split[0];
   return $heading;

Note that this is just an example and there may be a more correct way to do the same thing, but it works as advertised.  You can add your filter function to the functions.php file in your current theme.  Remember to clear the index cache (from the AZIndexes admin page) once you’ve added the filter so that the altered headings will be sorted in the correct order.

If anyone comes up with a useful filter function of their own, please feel free to post it here.

Incidental Imponderables #2

Why, when I put a clean shirt on just before sitting down for a meal, do I always seems to spill something on it?

AZIndex: Caching In — Update

AZIndex LogoJust a quick update for those who are following developments for my AZIndex plugin (is there anybody out there… there… there… ?).

Anyway, it looks like I have a viable caching solution almost completed, and the speed improvements are quite gratifying.  I have created several test indexes containing over 1100 items and the index pages load anywhere from 4x to 50x faster when they are being cached, depending on the options set for the index.

Obviously indexes with multiple pages see the biggest gains because if you put 1000 items on one index page, the plugin still has to loaded all 1000 items from the database even though they don’t have to be sorted.  Even so, a 4x speed improvement is nothing to sniff at.  But if you have a large number of items in the index, it’s only natural to have them spread over multiple pages, so in most cases you will see at least a 10x improvement over a non-cached index.

I have added an option to disable caching, but I recommend against using it unless you think you might be having problems with caching, and you can reset the cache from the admin page if necessary.

How does AZIndex know when the cache is out of date?  Well, it attaches to the WordPress action hooks which fire when someone saves or publishes a post.  Each index maintains a dirty list of posts and pages that have changed since the cache was last rebuilt, and when the index is next display, it checks though its dirty laundry (if you will) to see if the ordering of the items has been affected by the changes, or if a post needs to be removed from or added to the index.  If it does find the index needs to be updated, then it will rebuild the cache causing a one-time slower load for one very slightly unlucky user.

Hooking changes to custom fields turned out to be a pain, since there are no definitive hooks for them, and you can change them without having to save the post afterwards.  In the end I attach to the Ajax hooks which fire when a user is editing a custom field.  That will probably work for 99% of all custom field changes, but if a blog uses another plugin to change custom fields using the function calls, then there is little AZIndex can do to detected those changes.  But in the worst case, all the blogger has to do is manually clear the cache once all the changes have been made.

So, be on the lookout for AZIndex v0.5 with full caching support sometime this week, just in time for the holiday weekend.