Archived Comment Thread

Hi Jon, sorry you’re having trouble. I just double-checked to make sure the published version of the plugin works for me, and it does (phew!):

http://englishmike.net/azindex-test-page/

The plugin keeps track of the index page it creates from the pageid that WordPress assigns it. The error your seeing should only happen if the id of the page containing the index doesn’t match any of the index definitions you created.

Anyway, first I would try starting over. Delete the index you created and try again. Don’t change any of the options at first except for entering a title for your index page, and see if that works. If that does works then it’s possible that the combination of the options you chose caused a bug. Let me know what you find.

But if you’re still having a problem with any index configuration that probably means that your WordPress setup is different from mine.

What version of WordPress are you using? And what version of PHP is your WordPress installation using? I have only tested the plugin with WP 2.5 and WP 2.5.1, both of which were using PHP 5. If your installation is using PHP 4.3 and I accidentally slipped in a 5.0 only API (I am fairly new to PHP) then that could be causing the problem.

Mike

Hey Jon, well this is a bit of a head-scratcher since it’s a pretty basic function that’s not working for you. If the plugin wasn’t installed correctly you would be having much worse issues, and you seem to have all the up to date software installed (assuming PHP 5.1 didn’t change anything, which I think is a safe assumption).

I haven’t heard of anyone else having the same problem yet (there have been about 35 downloads so far, but no other feedback), but it is early days (my first day of my first foray into open source software!). So I would like to investigate further, if you are willing to bear with me (I appreciate you willingness to try out the plugin).

I don’t have solutions tonight, but I will do some more digging tomorrow to see why the plugin can’t match the created page’s id with the index you created. The logic is very simple — I call id = wp_insert_post(…); and immediately insert the returned id into the database the very next line. If the page create failed then you would see no new page, and if the database insert failed then you would not see a new index in the table. But you see them both. Very strange.

Unless the post’s ID has been modified in some way (you don’t happen to have any weird plugins installed that might do something like that — do you?), then I am still missing something in my code (which is perfectly possible). I do make the assumption that the id of a post is immutable once it has been created — perhaps I am wrong in that case?

Anyway, enough rambling. I will investigate further tomorrow.

Cheers,

Mike

By the way, I forgot to say this earlier — you should only see [az-index] when you edit the index page — the index is built on the fly when a user accesses it. (or should be anyway!). You can add text in front of [az-index] or after it too (as in the example on this site). But you certainly should not be seeing that error message when you preview the page.

Hi Jon (and Fred) – thanks for the info. I was thinking about the way the plugin links indexes to posts using post-ids, and have come to the conclusion it might be a bit flaky. I am going to make a change to the way I do that — essentially by changing [az-index] to something like [az-index id=3] where the id is the id of the index you created, so the plugin no long relies on the id of a post staying the same.

That will actually help Fred’s situation since you will be able to plug an index into any page (i.e. the Archives page) or even a post, if you wanted to. That sounds like a better solution.

I can’t guarantee it will fix your problem, Jon, but it should. I’ll try to have a new version of the plugin available today.

Cheers,

Mike

Fred — to clarify — you can’t plug the index into another page at the moment, but the next version will allow you to do that.

I agree, Jon. And thanks for persevering with me. I know from personal experience how easy it is to just drop something if you can’t get it to work first time

Anyway, I just uploaded version 0.2 of the plugin, which I am pretty sure will fix your problem. My guess is that one of your other installed plugins was doing something I hadn’t anticipated (which was my problem, not theirs), and the more I thought about it, the worse I realized my assumption was.

Anyway, the cool thing is that as a result of fixing the problem, Fred now gets to put the index anywhere he wants, so it’s a win-win all round (until you find the next show-stopper bug, anyway!).

Hey Mike/Jon, that’s very strange — the demo page on this site is a live demo using the plugin, so it’s tough to know why it’s not working on your web sites when I can’t reproduce the problem.

Yes, the plugin creates a table called “wp_az_indexes” and INSERTS an entry for each index you create. But if the table wasn’t being created, you wouldn’t see the indexes you create being added to the index table on the AZIndex admin page — which I assume you are seeing, right?

If that’s true, then the problem would seem to lie with loading the database table when the short-code (az-index) (in square brackets) is encountered. That code is in az-index-admin.php:

function set_vars_from_table($id) {
  az_trace('fn:set_vars_from_table');
  global $wpdb;
  $indexes = $wpdb->get_results("SELECT * FROM ".AZ_TABLE." WHERE pageid = $id");
  if (count($indexes) != 0) {
  ...
The function returns the count of indexes in the table, which in your case must be zero for some reason. So it looks like this is the query that’s failing, but not always, which is very strange. ( ‘pageid’ is really the id of the index, I just didn’t want to rename the field in v0.2 and break users who didn’t uninstall the plugin between versions). The query is very basic SQL so I wouldn’t think that an older version of SQL is the issue either.

If you wouldn’t mind, I’ve uploaded a debug version of az-index-admin.php which will dump out a couple of debug lines on your screen (in yellow):

http://svn.wp-plugins.org/azindex/branches/debug/az-index-admin.php

If you wouldn’t mind installing this on your system (in plugins/azindex) and let me know what it says.

In the meantime I’ll keep looking. It doesn’t seem to be a plugin interaction issue, since I removed that likelihood with the fix that failed, so it’s probably a bug or incompatibility in my code somewhere.

Thanks again for the continuing feedback.

Mike

Oh, I should just double check. Can you create and edit indexes in the admin panel ok? You know, creating a index, saving it, then clicking on “Edit” again and all the options you set show up ok?

If that’s all working then the database table is ok — it’s just this query in the comment above that’s failing for some reason.

Thanks, Jon, that clears it up. No database table. Weird.

I’m using the API: maybe_create_table(AZ_TABLE, $sql); on activating the plugin, and it doesn’t seem to be working. I guess the function is saying “maybe not!”

(I should also do something about that misleading “index created” message you got. The plugin should notify the user if the database table doesn’t get created).

I will look into why the table isn’t getting created and check back a bit later.

Thanks again for the help.

Mike

Hey Jon, I think we’re down to two possibilities -

a) the plugin’s activation hook isn’t getting called.
b) the database create table is failing

I have updated the debug version of the code with a couple of extra trace statements:

http://svn.wp-plugins.org/azindex/branches/debug/az-index-admin.php

The output won’t appear on the screen so it has to be written to a file on your server. The file is called ‘az-trace’ but I’m not sure where PHP will put it — on my system it’s put in the WordPress root directory.

I also replaced the maybe_create_table function (though it looks perfectly ok to me) with a direct $wpdb->query(CREATE) call, just to see what happens.

Reactivate the plugin and go to the AZIndexes page. That should put enough stuff into the az-trace file to see what’s happening.

The trace output should look something like:

fn:az_plugin_activate : start

CREATE TABLE wp_az_indexes ( name text NOT NULL, pageid int NOT NULL, categories text, tags text, heading text, subheading text, description text, columns tinyint, headingseparator text, itemsperpage smallint, customcsssingle text, customcssgroup text, options set('add-spaces', 'group-subhead', 'alpha-links', 'alpha-links-unused', 'alpha-links-two-rows', 'multipage', 'multipage-links-above', 'multipage-links-below', 'custom-css'), PRIMARY KEY(pageid));

0
fn:az_plugin_activate : end

If you can’t see all that in the az-trace file, then WordPress isn’t calling my activation routine for some reason.

I’m dumping out the SQL statement to see if that’s the issue. You can try cutting and pasting it and running it in PHPMyAdmin to see if that creates the table for you. At least then you’ll be able to play with the plugin!

Thanks, Jon. Well, it looks as though I’m going to have to install MySQL 4.1

I’ll get back to you when I’ve checked it out.

Ugh — I finally figured it out… By process of elimination (and I eliminated just about everything else in the query first!) it turns out that MySQL 4.1 doesn’t like me using “columns” as a field name. Obviously not an issue for 5.0, but 4.1 squeals loudly when you use it. (I’m guessing it’s a reserved word in 4.1 and that 5.0 relaxed the restriction on it.)

Ah well, thanks again to Mike F. and especially Jon for your feedback while I chased bugs down the wrong rabbit holes. I will rename the columns field and upload a new version of the plugin for you all to try out. I will also add some more error checking to the code in the near future so that problems like this are less painful for me and the user to figure out.

One word…. phew!

Thanks for the confirmation that you’re up and running, Jon. You need not have worried about being a pain. I’ve been a software developer and tester for over 20 years, so I can usually tell pretty quickly who the awkward customers are , and you are definitely not one of them.

Thanks again,

Mike

Hi Lionel. I get what you’re saying about custom queries, I struggled with the query_posts() for a while before deciding to use a direct MySQL query instead. There were a couple of bugs in query_posts() that I could not work around easily. So don’t feel bad about not figuring it out!

Anyway, in regards to your questions. First, I figured out how to include an index in a template file (which is what I think you need). You can’t just add the [az-index id="1"] short code because it doesn’t get passed to the AZIndex plugin if it’s not in a post or page. What you can do is add something like this to the template (below the main post loop):

<?php
   query_posts('pagename=index-page');
   while (have_posts()) : the_post();
      the_content();
   endwhile;
?>

where ‘index-page’ is a page containing the [az-index] shortcode. I tested this and it seems to work ok.

Now, regarding your “natural ordering” request. It’s an interesting idea, though not exactly in the spirit of alphabetical indexing . So I’m not sure really sure it’s a good fit for this plugin (though I won’t rule it out yet!).

However, there are a couple of things you could try yourself:

1. Add leading zeros to make the product reference numbers all the same length (I’m sure you’ve considered this one already).
2. The sort comparison function (az_compare) is in the plugin file az-index-content.php. (the file is in wp-content/plugins/azindex in your WordPress installation). You are welcome to replace it with one that meets your needs. For example:
   
   function az_compare($in1, $in2) {
   $result = intval($in1['head']) - intval($in2['head']);
   return $result;
}

   This function compares two integer values in the Heading fields (a custom field you define or the excerpt) and will sort the index into the natural order you’re looking for. If the only thing you’re sorting on is the reference codes, then add those codes to a custom field (or excerpt) and use that field as the heading for the index. You can still define sub-headings and descriptions and they will be displayed but they won’t be used in this simple sort. This should work for you, but you do have to remember that upgrading to a new level of the plugin will overwrite any changes you make and you will have to add it back, so it’s not ideal.

I will add your request to the list, but at the moment I really have to figure out how to cache indexes so the plugin can be used safely with large indexes, and there are a few other issues I have to resolve.

If you have any questions about anything I’ve said here, feel free to ask.

Mike

Lionel, since I wrote the comment above yesterday, I realized that there is a nice way to integrate what you want into the AZIndex plugin. Similar to my second suggestion of replacing the comparison function with one that you need, I see no reason why an “advanced” option (i.e. one requiring a little programming) could not be to specify your own compare function (i.e. a replacement for az_compare() in the plugin) that you add to, say, functions.php in your theme directory. That way anyone can quickly tailor the sort to their own satisfaction.

Now, I haven’t played with that idea yet, so I’m not 100% sure that it’s as easy as that, but I will put it on the list of things to do, so when I finally get to version 1.0 (hopefully later this month) check back and see if you have what you need.

Mike

No worries!

Hey Danny, glad you like the plugin. Thanks very much for the feedback. I do intend to add caching and page support (if that’s what you mean?) in the near future. I had a self-inflicted catastrophe with my new laptop last week which set me back somewhat, but should know in a couple of hours if they fixed it under warranty, so hopefully I will begin to update the plugin again soon.

As for zebra-striping. That’s a very good idea. You are correct in that it’s not something you can add using the custom CSS. I honestly hadn’t considered the idea as something suitable for an index, but I’ll add it to the todo list and take a look. Curiously enough, I recently hacked WordPress to allow the same thing for sidebars — if you notice the sidebar on this blog is “striped” and it’s not hard-coded in the HTML — if I insert another widget into the sidebar, the alternating colors for the widgets still work. It was a bit of a hack, but I might write a post on how to do it at some point.

Hi Graeme,

Thanks for your feedback. It looks as though htmlspecialchars_decode() is a PHP 5-only API (a fact I missed when I added it to the plugin). That means your live production site is probably still using a version of PHP 4.x and the plugin fails. From looking at the comments attached to the API in the PHP manual, it looks as though it might be possible to substitute the offending API for another function which would work.

Now I have my laptop back from the repair shop, I’ll take a look at removing that dependency on PHP 5, but I should warn you that, as I said in the release notes, there might be others. Keep an eye open for a new beta release later this week.

Mike

By the way, depending on who you are using as your web host, you might be able to upgrade your server to PHP5 from the server’s control panel. That’s what I did on the server running this blog. Mind you, that would be a drastic step to take to fix this one problem you’re having, so you should be think carefully before you do it since other aspects of your server might break. However, if you’re just running WordPress 2.5.x and nothing else, then it should be reasonably safe to do it.

Mike

Thanks for the feedback, Graeme, and I’m glad it’s working for you. Feel free to let me know if you run across any other problems. Thanks to your testing, it looks as though my plugin supports PHP4 as well as PHP5.

Mike

Danny, FYI, while the CSS isn’t obvious (those darned “floats” are a real pain!), I figured out a way to do striping of the index entries with a small modification to the plugin code. So look out for it as a new feature in the next version of the plugin.

Mike