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?
Many plugins use
/wp-content/custom-plugin-folder/
to store customized plugin data (WPTouch comes to mind).Just use the constants
WP_CONTENT_URL
andWP_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 🙂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:
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:
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.)