As described in more detail by others (Otto, WPCandy…), a WordPress theme should only contain that which relates to the look and feel of the site. Any core functionality belongs in a plugin.
A good rule-of-thumb is that anything a user would expect to keep after changing themes belongs in a plugin. This includes custom post types, taxonomies, metaboxes, and shortcodes.
For specific functionality that’s reusable and/or the client might want to selectively disable, it’s best to build as its own plugin. Many times I’ll turn these into public plugins.
For everything else that’s project-specific but should be theme-independent, I put in a plugin called Core Functionality. That’s the base plugin I now use. Of course you’ll want to delete everything that’s not relevant – I have the code for post types, taxonomies, and metaboxes in there because they are used most often.
My base child theme used to have all these in the theme. Over the past few months I’ve been moving them to a core functionality plugin on each project, but it’s about time I finally update the base child theme and pull the functionality out into its own plugin.
For added safety, I use a “must use” plugin rather than a standard plugin. Must Use plugins (mu-plugins), are plugins that cannot be disabled. I like to put my core functionality in these so that a client can’t accidentally disable it and break their site. Must Use plugins go in /wp-content/mu-plugins (you’ll need to create that directory if it doesn’t already exist).
I’ve been doing that for a while. I like to register custom post types and taxonomies in a mu-plugins file so it can’t be accidentally disabled.
http://justintadlock.com/archives/2011/02/02/creating-a-custom-functions-plugin-for-end-users
Yep, I do this as well. The only issue is mu-plugins doesn’t look within folders. So instead of dropping /core-functionality in there, You have to drop the contents of your core functionality plugin directly in the mu-plugins directory.
You can of course include any additional folders / files from that one plugin file in the /mu-plugins/ folder
Ha. Just ignore my last comments. I just saw this post.
Thanks
Bill,
I enjoy your site. I have used your rotator and ‘Rotator Options’ metabox before, so I thought I would give your plugin a try. Sounds like a really good idea. I used your child theme and plugin. The rotator metabox loads and the ‘Instructions’ are saved but do not display with the ‘Featured Image’ on my localhost. I do not want to waste your time, and I do not have the time to look into it further, but I thought at least I should say something. I reinstalled it and got the same result.
Keep On Trucking!
Make sure the field ID’s you’re saving are the same that the rotator is pulling.
WP Rotator uses
wp_rotator_urlandwp_rotator_show_infofor custom field names. The Custom Functionality plugin hasbe_rotator_urlandbe_rotator_show_info.This is just sample data and isn’t designed specifically to work with WP Rotator. But if you change be_ to wp_ it will.
That worked. It did not occur to me to check that. Back to basics.
Thanks
About MU-plugins, it is possible to use a folder for each plugin.If you make an include file in your MU-plugins folder.
Here is the snippet, I’m not sure about how to list code, so I have excluded the tags.
Include.php
?php
include (‘plugin_folder_name/file_name.php’);
?
Yep, that’s definitely an option. But the way I look at it, the plugin.php file in /core-functionality does exactly that. It simply includes all the relevant files. So I drop plugin.php in /mu-plugins which just includes all my files, and everything else is in /mu-plugins/lib
THANK YOU for sharing this!! I’m just learning to clean up my functions files and this is going to help A LOT!!
Great points. I get frustrated with the direction themes seem to be taking, where a ton of functionality is written directly into the theme. And frequently, it’s hard to tease out the functionality due to pieces being in various places – page template, functions.php, header.php, etc. Woothemes makes great themes, but I don’t understand why they don’t create plugins a la faultpress, wikeasi, supportpress, etc. Additionally, they created a decent framework/theme, but haven’t based any of there own themes on that framework. I appreciate you sharing this, as I think this gives a good basis and maybe a step in the right direction for theme developers.
Really nice post Bill. If I might, how do you handle things like single-{post-type}.php, archive-{post-type}.php, taxonomy-{taxonomy}.php. I had thought about moving my custom post-types and taxonomies to a core functionality plugin, but was unsure how to handle these templates since they would be dependent on the core functionality plugin.
Also, the mu-plugins idea doesn’t work so well for a network environment where not all sites require the extra functionality.
The registering of the custom post types and taxonomies belong in the functionality plugin, but their display (the template files) belong in the theme. Besides there not being an easy way to package theme files in a plugin, the idea is that if you change themes you’d need to change those theme files as well.
I don’t work on multisite websites, so that’s not an issue for me
That is kind of what I concluded from my investigations.
I maintain four network installs. All for the same university.
Hi, Bill – just wanted to thank you for this and your other post on Custom Post Types. What you’ve described about a core functionality plugin makes a lot of sense and I’d never thought about it before. I’m about to start experimenting with Custom Post Types for the first time and happened upon your site – great instructions and advice.
How come there are no shortcodes listed in https://github.com/billerickson/Core-Functionality? I always use the url, wpurl, and child shortcodes that I learned from your site and include them in every project. I recently switched to using a Core Functionality plugin (which I also first heard of on your site) for non-theme related things and I just added a shortcodes.php file to the /lib/functions folder. Is that how you do it when you add shortcodes for a client site?
If shortcodes are required, I create a file in /lib/functions/shortcodes.php.
A long time ago I used the url, wpurl, and child shortcodes in sidebar widgets because my find/replace of URLs when migrating didn’t work on serialized arrays (widget content is stored as a serialized array). Now that I use this approach, I use actual URLs instead of shortcodes everywhere. I no longer need those three shortcodes.