How to customize a plugin whilst maintaining ability to upgrade

Question

I am currently working on a major update to one of my WordPress plugins.

The plugin lets the user choose from several available skins. Quite often I get asked to create a custom skin. To prevent this skin from being deleted on upgrade I have to use a WordPress hook to disable automatic updates for the plugin. This is obviously not ideal as I would want them to still be able to update the plugin. The problem is the way WordPress handles updates - it simply deletes the plugin folder and installs the new version. Thus removing files which were not actually part of the old version.

Currently the only way I can get around it is having two skins folders - one in the plugin folder and one in the uploads folder - is this really the only way I can offer this to my users?

Answer 1

Many plugins use /wp-content/custom-plugin-folder/ to store customized plugin data (WPTouch comes to mind).

Just use the constants WP_CONTENT_URL and WP_CONTENT_DIR ^Docs to check for the existence of your folder and retrieve any available skins.

The following article, although not directly related to this Question, explains the importance for plugins/themes to search for translations first in the wp-content/languages folder before loading its own packaged .mo files. It's a worth read and hopefully you'll apply the concept in your next release :)

Loading WordPress language files the right way
^{http://www.geertdedeckere.be/}
I would like to point out that is important to load custom user language files from WP_LANG_DIR before you load the language files that ship with the plugin. When multiple mo-files are loaded for the same domain, the first found translation will be used. This way the language files provided by the plugin will serve as a fallback for strings not translated by the user.

Answer 2

The other way is to have people add their own sub-plugin. For example, the code in your core plugin that gets the skins could be something like:

function get_available_skins() {
    $skins[] = '/includes/default-skin.css';
    $skins[] = '/includes/2012-skin.css';

    return apply_filters( 'get_available_skins', $skins );
}

Then, users can create a custom plugin that sits alongside yours (activated separately so it won't interfere with your update) that does the following:

add_filter( 'get_available_skins', 'my_custom_skin' );
function my_custom_skin( $skins ) {
    $skins[] = '/my-custom-skin.css';

    return $skins;
}

This is the exact same way WordPress uses hooks to make itself extensible. Don't reinvent the wheel.

_{(Obviously, I don't know what plugin you're working with, what a custom skin looks like, or how you have things coded, so you'll have to use the code above merely as a model for how you can refactor your own code.)}