Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.