Having worked with child themes for some time, it was great to learn something new today, one that will cause a paradigm shift in the way I work with themes. The epiphany came from Dave Clements, who built on Ryan Mel‘s WPCandy article How to create your own WordPress functionality plugin and essentially tells us to use a plugin to introduce custom functionality instead of putting (most) of the code into the theme functions.php file.
The basic premise is this:
Create custom functionality for your site but don’t tie it down to a theme
What do you mean?
To clarify: we all know what happens when we switch themes – custom taxonomies disappear, shortcodes cease to be of use and Favicons are no longer – unless we build them in, again.
Why waste time and energy doing this when you can retain all these by creating your own custom functionality plugin? Then you or your client can switch themes at will.
Then when should I use functions.php?
Both Dave and Ryan maintain that not everything should be put into the plugin; some things should still remain in the theme file’s functions.php, for example registering sidebars and custom nav menus, which are specific to your theme.
Others, including custom image sizes are more open for debate and will be up to your discretion.
Ryan produced a helpful table to provide some examples, reproduced below:
More content is available by clicking on the image or link above, which will take you to the full article (with even more discussion and recommendations) but hopefully this gives both you (and me) a better idea of what to put in our functionality plugins.
So how do I create a custom functionality plugin?
It’s as simple as taking the relevant codes from your functions.php and placing it into a plugin-name.php file. Both articles – WPCandy and Dave – kindly provide blank templates, and Ryan (on WPCandy) actually goes a step further to advise maintaining a readme.txt file.
I have not included a blank file here since that would be duplicating the good work done by both; direct file linkage is not ideal either.
Effectively, much like a style.css file, the header in your plugin-name.php is very important:
/* Plugin Name: Site Name Functionality Plugin Description: Summarise the key elements of your site functionality plugin. Version: 0.1 License: GPL Author: Your Name Author URI: Your URL */
This file then goes into /wp-content/plugins/plugin-folder-name. Then you simply activate your new custom functionality plugin.
Further comments
It might be reassuring to know that heavy weights like Otto, Michael Fields, PTah Dunbar and Konstantin Obenland have all stated in the comments that they agree this to be good practice and some of them use it on their own sites.
Dougal Campbell also suggested the following:
If I switched themes, and this functionality disappeared…
…would I miss it?
…would it ‘break’ my site in some way? (I’m using ‘break’ loosely here, subject to interpretation)If I installed this theme on somebody else’s site…
…would they need this?
…would it expose any of my account info?
Last but not least, Justin Tadlock also wrote a post about this as well and advises us to ask ourselves two questions:
Is this something I only want to happen when using my current theme?
Is this functionality I want to keep regardless of the theme I’m using?
