Tag Archives: gpl article

WordPress 2.7 Plugin Uninstall Methods

The “uninstall” hook runs when the user deletes a plugin that is deactivated. The implementation is basic and doesn’t allow for much in the way of what the original implementation calls for, but hey at least it exists. The point now is that you can do what you want, but WordPress won’t hold your hand while you’re doing it. It isn’t the WordPress way to do so.

Would have been nice, but I’m glad it is in. It will make the uninstall process a lot easier. Not to mention that deleting a plugin isn’t going to be so bad, since you can always use the Plugin Installer to automatically download and activate the plugin again. That should allow for more plugins to support uninstall feature.

Registering the Plugin Uninstaller

There are two ways to register the uninstaller with WordPress.

  1. Create uninstall.php at the base of your plugin folder.
  2. Register your plugin’s uninstall hook.

Uninstall.php Uninstaller Method

This is the preferred uninstall method and if the file exists, then it will be run instead of the uninstall hook. You should do some checking for either the ABSPATH or the WP_UNINSTALL_PLUGIN constants. You would be more secure, if you choose the latter of the two. The WP_UNINSTALL_PLUGIN allows for you to be even more secure or paranoid by checking the path of your plugin. Most cases, all you will need to do is just check for the existence of the constant.

Your plugin will be deleted after the uninstaller is ran should you can clean up all database tables, options, extra files, and take the time to save or delete custom files that the user made. There is no way to stop the process once it is started or that is to say, that you shouldn’t try to stop the process once it is started.

The user wants to delete your plugin and it will be a bad user experience if that person finds their plugin still accessible. Come to think of it, it is probably possible and allow for the user to still delete your plugin, but there are no internal means to do so.

if( !defined( 'ABSPATH') && !defined('WP_UNINSTALL_PLUGIN') )
    exit();

delete_option('my_option');

Register Your Plugin’s Uninstall Hook

This doesn’t work like the other plugin register functions, like activate and deactivate. Your plugin will be deactivated, so it is not going to be possible for WordPress to check for your uninstall functions if it used the same method as the other two functions. Instead it creates an option that lists your plugin and its uninstall hook.

When the plugin is deleted and there is no uninstall.php file, but the uninstall hook exists, then the plugin will be ran one last time in order to run the hook. This is not the preferred method of your plugin runs code during the inclusion of the main plugin file, like some plugins do. If that is the case, then use the uninstall.php, which is the only file that will be called when you plugin is uninstalled.

Special care then should be taken when using this method to ensure that your plugin isn’t doing anything it shouldn’t when uninstalling. Your hook will be called and then your plugin will be deleted.

An example might be:

register_uninstall_hook(__FILE__, 'my_uninstall_hook');

function my_uninstall_hook()
{
    delete_option('my_option');
}

As opposed to the other method using a checkbox or just automatically uninstalling on deactivate, I think this is a far better way of knowing when to clean up after your plugin.

You can provide backwards compatibility, but using function_exists() function before calling register_uninstall_hook().

if ( function_exists('register_uninstall_hook') )
    register_uninstall_hook(__FILE__, 'my_uninstall_hook');

function my_uninstall_hook()
{
    delete_option('my_option');
}

Possibly Related Posts:


Translate Plugin Headers in WordPress 2.7

Improvements that just hit the trunk today allow you to add the plugin headers to the .POT file. There are a few ways of getting the plugin headers into the .pot file, where if it is translated will be displayed in the plugin administration in that language. There are two online tools that will pull the plugin header data out and put it into the .pot file.

The first one is part of Automattic i18n Tools and the second is either part of or will be part of the new Plugin Extend Administration interface online translate tool for your plugins to create a .POT file.

New Plugin Headers

The two new plugin headers for allowing translating the plugin header is “Text Domain” and “Domain Path”. The only one that is required is the “Text Domain”, which is the same as text domain that you have in your plugin.

  1. Text Domain – Unique name to identify your plugin from others.

    < ?php
    /*
    Text Domain: mydomain
    */
    
  2. Domain Path – Optional and only needed if the .mo files are stored in a separate file relative to your base plugin directory. If the directory is located relative to wp-content at plugins/my-plugin/lang_folder, then the “Domain Path” would just be lang_folder.

    < ?php
    /*
    Domain Path: lang_folder
    */
    

PHP Hack to Get Plugin Headers in the .POT File

There is a more hackish way that doesn’t rely on the above two to get the plugin headers in to the .POT file.

/*
Plugin Name: Name Of The Plugin
Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates
Description: A brief description of the plugin.
Version: The plugin's Version Number, e.g.: 1.0
Author: Name Of The Plugin Author
Author URI: http://URI_Of_The_Plugin_Author
Text Domain: mydomain
Domain Path: lang_folder
 */

$plugin_header_translate = array(
    __('A brief description of the plugin.', 'mydomain'),
    __('Name Of The Plugin Author', 'mydomain'),
    __('http://URI_Of_The_Plugin_Author', 'mydomain'),
    __('Name Of The Plugin', 'mydomain')
);

A warning about offering the plugin name to be translated, if you do so, then it is possible that the automatic plugin updater will not recognize your plugin and therefore will probably not check for updates.

Translating the name and other parts will have no negative effects on the plugin updater. This was fixed in revision r8368. No word yet on if this will be in 2.6.1, but I’m crossing my fingers. Well, WordPress 2.7 should be out September-ish and 2.6.1 should be out towards the beginning of next month.

Possibly Related Posts: