Oct 03 2006

The Future of Uninstalling GG_Translate

Published by at 3:25 pm under GG_Translate

This is an old article and the information contained within it may be out of date, not reflect my current views and/or contain broken links. If you feel this article is still valid and requires updating, you can use the contact form to let me know. However, I make no guarantee that it will get updated.

Having written a couple of plugins for wordpress, most notibly GG_Translate, I’m starting to get annoyed by some of the features WordPress provides for us plugin writers.

Firstly, I want my plugin to register its default options in wordpress when it’s activated and remove the settings when it’s deactivated. For this purpose, I assume, the wordpress devs have provided activate_[plugin name] and deactivate_[plugin name] action hooks, so I can have my functions executed when these actions happen. The downside is that in order to attach to these hooks I need to use the full folder and file name of the plugin, so for using them with the GG_Translate plugin I need to do the following:

add_action('deactivate_GG_Translate/GG_Translate.php', array('GG_Translate_Admin', 'deactivate'));

Now you may think that this really isn’t a major issue, but what happens if the person installing the plugin decides that they don’t want to put my plugin in a folder called GG_Translate, i that case I then need to start figuring out what folder they have put my plugin in… if in fact they have put it in a folder! Come on guy’s you must be able to think of a better solution.

Surely the fact that each plugin must be uniquely named means that they should be able to use the plugin name, e.g.:

add_action('deactivate_GG_Translate', array('GG_Translate_Admin', 'deactivate'));

Next up, wordpress has a really nice interface for viewing and editing all settings saved by wordpress and installed plugins (http://www.myblog.com/wp-admin/options.php). This interface however only allows for the viewing of settings and doesn’t provide for the deletion of settings. If I want to delete a setting that an untidy plugin has created then I have to either write a quick-and-dirty plugin for the purpose of removing the setting, or I need to dive into the database and delete it by hand… not very user-friendly if you ask me.

Another thing, whilst digging around in the core wordpress code I noticed some inconsistencies. It seems entirely random as to whether or not data being sent to the database will be escaped before hitting the database. It seems too easy for a plugin developer to send a string to the database that could wipe the database clean. I think wordpress needs a much more uniform approach to database access.

Finally, its about time that wordpress started taking advantage of the object oriented features provided by PHP. I’ll give them their due, they are working on it but I’d rather they were working quicker. I also can’t wait for PHP6 to come out (although thats still way over the horizon) as hopefully the namespaces will sort out all the plugin function naming headaches. Although, I’m not about to hold my breath for either of these.

No responses yet