Category Archives: AZIndex

I just put out another quick version of AZIndex to fix a nasty problem a few users were having when installing v0.7.1. It turns out that upgrading the AZIndex database table was failing for those people who a still using a very old version of MySQL (4.0 and below), which left the plugin dead in the water. The good news is that only a very few users would have been affected.

This new version should get those people up and running again although, unfortunately, their index definitions will have been lost (I will work on a method of upgrading that will prevent that from happening again).

My apologies to those who were adversely affected by this problem.

UPDATE: In my haste to put out a fix for the problem caused to a few people with 0.7.1 I put out a bad version (0.7.2) which, if you installed it, probably irretrievably wiped out your AZIndex settings (unless you had the foresight to make a backup). My apologies to those of you who lost their settings. I need to include a safer way to upgrade which will allow users to retrieve their settings if something goes horribly wrong).

2nd UPDATE: Fixed another bug causing lower case characters to be sorted in the wrong order (in English-only indexes).

I have just released AZIndex version 0.7.1 to the unsuspecting world 8-).

The only significant change in this release is the addition of support for national languages. This means that indexes should now be sorted (collated) in the correct order, and accented characters (and other non-English characters) should appear correctly in the alphabetical titles and links in your index.

My thanks to commenter “K” who took the time to test an early (and not so successful) version of the national language support. Thanks to his perseverance, I have managed to squash many of the bugs that were still in the code a couple of days ago.

To enable the national language support for an index simply select the Turn on additional support for national languages option in the index settings. In the vast majority of cases, that is all you should need to do. There are also options to set different locale and collation tables, but unless you are having problems with items appearing out of order or being grouped incorrectly, then you should not need to use them.

All European languages should be supported, but I am less certain about languages like Chinese and Japanese. It’s also possible that the right-to-left languages (Arabic and Hebrew) may still not work correctly. Feedback on any of these is welcome.

Please note, I have only tested these new options on English Windows XP and Linux systems, so it is possible that some bugs will show up when you run AZIndex on non-English systems. Please report any problems you find by posting a comment on this blog or via email.

Just a quick update on what I have been working on with the AZIndex plugin. I decided it was finally time to do something that I have long been putting off — adding national language support to the plugin. That doesn’t mean I am translating all the English text to other languages (sorry!), but I am looking at fixing the problems to do with sorting indexes with non-English characters in it, and the displaying of non-English characters in the alphabetical links and headings.

But, wow, little did I realize the complexity that is PHP national language support. Unicode support will only appear in PHP 6.0, so I have to rely on the older PHP APIs, and only those which are likely to be installed on a WordPress server (i.e not many!). Not only that, but I discovered that WordPress used something called UTF-8 (which is a multi-byte codepage where characters can be one, two, or even three bytes long) which is fine, but PHP’s collation (sorting) function on Windows doesn’t work with UTF-8 so, on Windows systems, you have to convert every index item into the local codepage before the index can be sorted. Yuck!

Well, that wasn’t too bad. I have made a couple of minor fixes to the AZIndex’s administration interface while should allow you to edit and modify your AZIndex settings as before (prior to installing WordPress 2.7). The changes are backwards compatible with older versions of WordPress (2.5.x and 2.6.x) so even if you haven’t moved up to WordPress 2.7 yet, you can safely install the new version (not that it will do anything for you!).

I will now work through the backlog of comments to see if there is anything else that needs attention. Thanks for your patience — oh, and a belated Happy New Year to everybody.

Whoops, well, I guess when you start something, you really should see it through…

Apologies to those of you who have been looking for feedback and fixes to AZIndex in the last couple of months, I really don’t have much of an excuse save that I got distracted on to a couple of other things (I am writing a book, no less!) and then assiduously avoided the backlog of questions that was building up on the blog.

Anyway, I’m back, and I have had a quick look through the backlog and see that the changes to the Admin User Interface in WordPress 2.7 has done a number on AZIndex (i.e. stopped people from accessing the settings pages). Oops. Please look for a fix and a new version within the next couple of days. It’s been a while since I looked at the code, so I may need a bit of time to get back up to speed (thank goodness for all those comments in the source code, eh?), but I don’t think it will take too long.

Finally, my thanks to those users who have helped others out with answers, solutions, and workarounds. I will post another more detailed thank you notice once I have gone through the comments in detail. You deserve the recognition.

Several users have asked for the ability to remove certain words like “The” and “A”, or even “Le”, “La”, and “Les” from the front of headings in their indexes. While I have already document how you can do that with AZIndex, the solution is not easy for novice WordPress users because it involves adding PHP code to one of your blog’s theme files, and if you accidentally make a mistake when inserting the code, it’s all too easy to crash your entire blog!

So I thought that there has to be a better, safer way to do this… and there is!

The SQL problems a couple of users were reporting are probably not because of they are using an old version of MySQL after all. As I was wondering if there was an easy way to support users on MySQL 4.0.x, I noticed something I should have seen before — I had hardcoded the database table names I added to the SQL query to obtain the post ids to be excluded from the index. Elementary mistake — my bad.

Hopefully the new version should work for those of you who had problems on v0.6 and v0.6.1. If it doesn’t then please let me know which version of MySQL you are using, because users of MySQL 0.4.x will still have problems with the exclude feature.

Well, it seems that in the latest version of AZIndex I might have inadvertently used a feature of MySQL that was not introduced until MySQL version 4.1. When you use the new “exclude categories/tags” feature, the AZIndex plugin constructs a gnarley SQL query that includes something called a “subquery”, and subqueries did not exist in MySQL 4.0.x.

I actually did check to make sure that subqueries were supported in MySQL 4.x, but I didn’t realize that WordPress officially supports all the way back to MySQL 4.0.x.

So… if you find that adding an excluded category or tag to your index causes a nasty SQL error, it is very likely that your server is running a version of MySQL 4.0.x. Now, MySQL 4.1 was released in October 2004, which is almost four years ago, so I can’t imagine that there are very many web hosts who still use an even older version. If you are in that unfortunate situation, it is worth checking with your web host to see if they offer the option of upgrading to a newer version of MySQL. Usually the upgrade process is virtually automatic. I know that my cheap shared web host provides that option, and I am sure that others do also.

I would rather not have to rewrite the AZIndex code to avoid using subqueries if possible. The SQL logical is complicated enough without having to deal with even more cases, so I need to know if there are enough users still on MySQL 4.0.x without the option to upgrade to see if it is worth the risk of complexifying (that’s a word, right?) the code logic even more.