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>.
Version: 1.6
Author: Michael Heilemann
Author URI: http://binarybonsai.com/
Template: parent_theme_folder_name_here
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.
Closing words.
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.
3 Comments
This is exactly what I was just thinking, which is why I stumbled upon your post.
I was thinking of the specific example that is WP e-Commerce.
The plug-in is great, but I want to make some changes to integrate some extra features. In order to make these changes, I currently have to change the files themselves. What happens when I want to update it though?
I will likely lose my changes, which means I can no longer update.
Hi Craig,
Thanks for checking in.
I’ve been thinking about the concept of child plugins and I think I’ve got one or two ideas as to how this could be done. It would require a specific approach from the plugin developer though.
The first could be using an OO (Object Oriented) programming methodology. This would allow developers to create plugins with a class that extends (read: uses) the class of the plugin they want to customise and override the functions where changes are required, as well as adding their own.
The other method would be a bit more intensive, perhaps, and would also allow for easier customisation of the plugins. Rather than simply running functions, the functions would be constructed in such a way that lends themselves to the use of filters or action hooks. Thus, a user could simply add a filter to the function to make a customisation.
Possibly, a combination of both would be ideal. As I mentioned above, it would take a fair bit of discussion and adjusting of coding style on the part of the (many) plugin developers out there.
What are your thoughts?
I was just thinking about this. or have been for a while, ever since i made a tiny tweak to a plugin i liked. now that plugin has been upgraded and i find myself having to re-do my tweaks. i dont really want to write my own plugin, or even fork the one i was building off of. if plugins could behave like child/parent themes that would be perfect!