How to customize a plugin whilst maintaining ability to upgrade

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.

Read More

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?

Related posts

Leave a Reply

2 comments

  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 🙂

  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.)