matty.co.za

I’ve been read­ing a lot over the past few months about child themes in Wordpress and how users have found them to be an invalu­able resource when cre­at­ing Wordpress themes.

What’s this “child theme” thing?

For those unfa­mil­iar with the concept, the way I’d explain it is as follows:

A user chooses a Wordpress theme (or theme frame­work) which they would like to cus­tom­ise. They then cre­ate a new theme with only the files required for the cus­tom­isa­tion. The main change comes in the style.css file where the theme details are spe­cified. The line “Template” is added to the theme details, which then spe­cifies 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 men­tioned above, for the user to cus­tom­ise only the areas of the theme where cus­tom­isa­tion is required, without dis­turb­ing the struc­ture of the main theme. Therefore, if the theme developer upgrades their theme, fixes bugs or devel­ops for a newer ver­sion of Wordpress, the theme can eas­ily be updated to the latest version.

And, onto the main point of this post…

What about the idea of child plu­gins for Wordpress?

Would it not be use­ful for users to be able to cus­tom­ise a par­tic­u­lar sec­tion of the plu­gin to suit a spe­cific situ­ation, without modi­fy­ing the main core of the plu­gin? This way, the plu­gin can be developed and main­tained on a devel­op­ment path in accord­ance with Wordpress and the developer, while allow­ing the end user more free­dom to develop the plu­gin in their own direction.

I find, often, that a plu­gin has been coded with the right idea in mind for the task at hand, but that it may be rather bulky and con­tain code that is unne­ces­sary to achieve the main func­tion 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 famil­iar with the concept can eas­ily adapt and begin cre­at­ing right out of the box.

The one require­ment I would say, in order to make things a bit easier in the back­ground, would be to keep the file names the same for the mod­i­fied files. The main issue I can fore­see with child plu­gins would be the mul­tiple declar­a­tion of func­tions. If this issue can be over­come, using some form of bulk “function_​exists()” call, the poten­tial for child plu­gins could have an inter­est­ing impact on devel­op­ment for Wordpress. Users could poten­tially cre­ate “addons” for pop­u­lar plu­gins, allow­ing for inter­est­ing cus­tom­isa­tions and to poten­tially take some of the pres­sure and work­load off of the main plu­gin developers for that par­tic­u­lar plugin.

Closing words.

In clos­ing, I hope this thought sparks off some dis­cus­sion about the concept. I look for­ward to hear­ing everyone’s thoughts on the topic of child plugins.