When I initially decided I was going to release a new version of Smart Archives today, I didn’t intend to include so many changes/fixes, but as it usually goes with these sorts of things, I couldn’t stop myself.
Previously, if your weblog was set to a different time zone than the server that hosted it (e.g., you lived in Florida, but your webhost was in California), you probably experienced a delay, equal to the difference between the time zones, in having your new posts show up on the archives page.
While I should have fixed this a long time ago, it was one of those things that didn’t affect me directly and so I kept putting it off. It was rather easy to fix — I basically just looked at my Relative Dates plugin , where I had solved this problem before, and made the necessary changes. Funny thing is, none of the stuff needed for the other plugin was necessary for this fix. I simply added the following line:
$now = gmdate(Y-m-d H:i:s,(time()+((get_settings('gmt offset'))*3600)));
About a year ago I added category exclusion to the plugin because I needed it. At the time, and until now, it only allowed you to exclude a single category, but enough people wrote in requesting multiple-category exclusion that I’ve finally implemented it. Instructions on its use can be found on the project page.
When I released the first version with category exclusion, I wrote the following:
I initially had the code setup such that it would only check the first element of the category array, which meant that the category you were trying to exclude had to be the only category attached to a particular post (in which case it would be the first and only element of the array). While this worked for my situation (and truthfully, I still do it that way because it’s faster), I knew that others would likely have multiple categories assigned to individual posts. Because of this fact, I ended up having to cycle through the array looking for any instance of the excluded category, no matter where it fell. If anyone knows of a faster, better way of doing this, please let me know.
I’m still using that method, and now, given that multiple categories need to be checked against multiple excluded categories, the CPU hit is even greater. I’d like to put this check into the initial SQL queries so as to eliminate the need to do it later in the plugin. However, I haven’t been able to come up with a good implementation because the categories are stored in a table separate from the main posts. If you’ve any ideas, I’d love to hear them.
An extra Dec in the block
I took care of this a few versions ago, but I never liked my admittedly crappy solution. It’s been redone. Well, not so much redone as just not needed any more given the way I now retrieve the post information from the DB.
When I first conceived of this plugin, I used only raw MySQL queries, instead of the built-in WP functions. I can’t remember exactly why I did that, but I think there was something I wanted to do that the WP functions wouldn’t allow. In any event, quite a few months ago I made the change to WP-only SQL functions on the version I use and haven’t noticed any problems. It’s been rolled into this version.
Curiously, a ton of people wrote me about this; I’m not sure their reason for wanting to use the WP functions, but it certainly wasn’t an isolated request (and in fact many people went ahead and changed this themselves).
While you should notice a speed increase from past versions, it still isn’t nearly where I would like it to be. As it stands now, I’m still making more DB queries than I would like. Currently, if you aren’t excluding any categories, it makes number-of-months-with-posts + 1 queries, which isn’t too bad. But, if you are excluding categories, that number goes up substantially (i.e., it’s commensurate with the number of posts you have).
Again, this is another thing I changed in my version a few months ago, but am just now getting around to putting in the public release. I think the way I handled links in previous versions confused people when there was no need for them to even know what I was doing. The way I’ve done it now should eliminate the confusion by not requiring any input from the user regarding their permalink structure.
I should also note that I’ve removed the trailing slashes on all of the year/month archive links (e.g., /2004, 2004/03, etc.).1 This is strictly an aesthetic preference of mine (and I’m trying to pressure everyone else into following suit :). If you’re as anal as I am about your URI structure and want the trailing slashes back, e-mail me and I’ll tell you how to do it. Either way, WP will probably add the slash back once the link has been clicked on (unless you go to great lengths, as I have, to stop WP from doing this).
Your permalinks should show up just as you have them setup in WP.
I haven’t used trailing slashes for years, but I’ve always made sure the public release of the plugin had them in there so as not to incite a riot; I guess I’m now throwing caution to the wind. ↩