I’ve been reading a lot over the past few months about child themes in WordPress and how users have found them to be an invaluable resource when creating WordPress themes.
What’s this “child theme” thing?
For those unfamiliar with the concept, the way I’d explain it is as follows:
A user chooses a WordPress theme (or theme framework) which they would like to customise. They then create a new theme with only the files required for the customisation. The main change comes in the style.css file where the theme details are specified. The line “Template” is added to the theme details, which then specifies the folder name of the main theme (chosen above). An example block would like like this:
Theme Name: WordPress Default
Theme URI: http://wordpress.org/
Description: The default WordPress theme based on the famous <a href="http://binarybonsai.com/kubrick/">Kubrick</a>.
Author: Michael Heilemann
Author URI: http://binarybonsai.com/
Tags: blue, custom header, fixed width, two columns, widgets
This allows, as I mentioned above, for the user to customise only the areas of the theme where customisation is required, without disturbing the structure of the main theme. Therefore, if the theme developer upgrades their theme, fixes bugs or develops for a newer version of WordPress, the theme can easily be updated to the latest version.
And, onto the main point of this post…
What about the idea of child plugins for WordPress?
Would it not be useful for users to be able to customise a particular section of the plugin to suit a specific situation, without modifying the main core of the plugin? This way, the plugin can be developed and maintained on a development path in accordance with WordPress and the developer, while allowing the end user more freedom to develop the plugin in their own direction.
I find, often, that a plugin has been coded with the right idea in mind for the task at hand, but that it may be rather bulky and contain code that is unnecessary to achieve the main function of the plugin.
OK, sounds cool… but how would you do it?
At this point, I’d keep the approach simple. Following the same method as with child themes seems to me to be the most logical method. That way, users who are familiar with the concept can easily adapt and begin creating right out of the box.
The one requirement I would say, in order to make things a bit easier in the background, would be to keep the file names the same for the modified files. The main issue I can foresee with child plugins would be the multiple declaration of functions. If this issue can be overcome, using some form of bulk “function_exists()” call, the potential for child plugins could have an interesting impact on development for WordPress. Users could potentially create “addons” for popular plugins, allowing for interesting customisations and to potentially take some of the pressure and workload off of the main plugin developers for that particular plugin.
In closing, I hope this thought sparks off some discussion about the concept. I look forward to hearing everyone’s thoughts on the topic of child plugins.