Showing off Your Series: Series List

This entry is part 10 of 10 in the series Organize Series Usage Tips

This series is no longer available on because I’ve moved all posts related to this plugin to the new home at You can read about the move here and here.

Organize Series 2.0.7 released

Some more fixes to the code made it necessary for yet another release of Organize Series.  Incidentally – I noticed that Travis Snoozy made the announcement that he is no longer actively developing his “In-Series” plugin and will only be maintaining it until he can find someone to take over it’s development.  Working on Organize Series has made me painfully aware of just how much time and effort goes into developing these plugins and his work on In-Series certainly “prodded” my development of my own series plugin in some areas.  Thanks for your contributions to the WordPress community Travis!

Without further ado, here’s the changeset for version 2.0.7 of Organize Series (you can download this version by clicking here):

Minor Changes:

  • Removal of extraneous html from series.php and seriestoc.php template files.
  • Updated readme.txt for suggestion to copy customized series.php and seriestoc.php files to theme directory.
  • Added missing < /div > to seriestoc.php file to fix “98%” of the typical default installations of this plugin.
  • fixed a potential bug with the get_series_toc() function/template tag.
  • Fixed a few spacing, code structure errors throughout the files.
  • Changed the “title” attribute for the get_series_toc() link to something a bit more friendly.

Major Changes:

  • Fixed bug affecting installs of Organize Series on blogs with a subdirectory in their blog address (i.e. In these setups the Series Table of Contents page re-direct wouldn’t work. This bug also affected custom seriestoc urls set on the Series Options pages with a multiple slash structure (i.e. the default is \series\, but if you used \series\seriestoc it wouldn’t work). Many thanks to Ken Carlson for his help in getting it fixed.

Series Options Page: Wrap up

This entry is part 8 of 10 in the series Organize Series Usage Tips

This series is no longer available on because I’ve moved all posts related to this plugin to the new home at You can read about the move here and here.

Be careful using the Automatic Plugins upgrades in WordPress 2.5

Well the long awaited sequel to the 2.3 branch of WordPress is almost out the door. Release Candidate 1 of WordPress 2.5 is now available for those brave souls who want to do some testing before the final release. WordPress 2.5 has been covered pretty well on the blogosphere so I’m not going to go into all the details here but I did want to write a post about one new feature that could cause some problems with users upgrading.

WordPress 2.5 comes with the ability for blog owners to upgrade their plugins automatically via the Plugins Page. “Automatic Upgrade” means that instead of having to download the plugin and then ftp it to your server, you can simply click the “upgrade automatically” link and WordPress will take care of everything for you. (click the picture below to see what it looks like)

Example of Upgrade Automatically Link

It’s a great idea and definitely one that will work okay with most basic plugins but here’s the problem(s):

  • The automatic upgrade does not deactivate your plugin first and then reactivate it after upgrading. If the plugin requires activation to run any checks for WordPress version, or do any db fixes, or “activate” any new features then it won’t do this and the plugin won’t work as expected. In most cases this can be simply remedied by remembering to deactivate and then reactivate the plugin after the upgrade is complete.
  • There’s no way for plugin authors to give you special upgrade instructions ahead of your upgrade. Sometimes these instructions might be important for keeping existing data or getting things to work properly. I know of at least one plugin that uses a file to store data rather than the database (bad design imho but still – a reality).
  • If the plugin is in the plugins root directory instead of it’s own directory then the automatic upgrade will change it’s location. For example say you have a plugin named myfunplugin.php and it’s located at ../wp-content/plugins/myfunplugin.php – after automatic upgrade does it stuff the plugin will now be located at ../wp-content/plugins/myfunplugin/myfunplugin.php. This could be a breaker for any plugin that has functions referencing the original location of the plugin.
  • There are other scenarios I haven’t tested yet like, what happens when a plugin changes directory structure from one version to the next?

This is a potentially a serious problem for both plugin authors and users of WordPress 2.5 and I’m posting this because I think people should be aware of it. I have posted a ticket in the WordPress Trac and I’m confident the devs are looking into it but in the meantime I recommend that blog owners use the automatic upgrade feature only if they are confident in fixing things if something goes wrong AND have checked the plugin author’s page first to see if there are any upgrade instructions.

Other than that, I’m really excited about the impending WordPress 2.5 release!

UPDATE: DD32, who is one of the contributors to the automatic upgrade feature going into WordPress 2.5 has been working on the ticket I’ve filed and a patch he created has been applied to the trunk files.  Changes brought with the patch include plugin deactivation before uploading the plugin upgrade and then attempting a reactivation after the upload.  This goes along way to addressing the issues I’ve raised in this post.  Great work DD32!