One of the beautiful things about WordPress is its flexibility. There are many, many ways to accomplish a single task. For example, if you want to publish a draft post, you can click “Edit Post” while you’re viewing the post; you can go to the Posts page within the administrative area and click “Edit” for the specific post; or you can go to the Posts page and “Quick Edit” the post. All three methods have the same end result.
The same is true when it comes to adding functionality to WordPress. New functions and features can be added to a theme, you can create a new plugin that can be activated and deactivated, or you can place the code in a PHP file and add it to your mu-plugins folder to have it automatically fired no matter what.
As with many things in life, just because you can doesn’t mean you should. My aim is to provide you with a few guidelines you can use to determine the best method for adding new functionality to your WordPress site.
Will You Use it if You Switch Themes?
If you only plan to use the functionality with your current theme, you should probably add it within your theme.
Here are some examples of items that tend to be specific to themes:
- Slideshows – Although the concept of a slideshow is used in a lot of different themes and sites, the way the slideshow is actually implemented depends specifically on a certain theme. An argument could certainly be made to say that slideshows should be implemented via plugins but, since you’ll most likely need to make major changes to the implementation when you switch themes, you might want to build that functionality into your theme from the start.
- Accordions, tabbed content and other JavaScript tweaks – As with the slideshows, these items are usually very specific to the current theme. Just because you want your content to be tabbed in your current theme doesn’t mean you’ll want that content to be tabbed in your new theme.
- CSS tweaks – This is somewhat of a no-brainer but it’s rather surprising just how many CSS changes and tweaks are implemented as plugins. Your CSS defines how your website looks, so it should be relegated to your theme.
- Page navigation – Although WP-PageNavi (and other related plugins) include really nice functionality, they generally require changes to your theme in order to get them working. If you have to make changes to your theme in order to implement new functionality, you should probably keep all of those changes in your theme.
It’s a Plugin
If you plan to use the functionality no matter which theme you’re using, it should be a plugin. This becomes especially true when you have a multi-site implementation and you need to make functionality available across all of the sites in the network. Examples of items that should be kept out of themes include:
- Custom post types – Most of the time, tutorials will tell you to add your custom post type registration to your theme’s functions.php file. If you ever switch themes, though, that means the content associated with those custom post types is useless until you re-implement it. Content should be separate from appearance (that’s the basic idea behind a content management system), so the items that govern the appearance of your site — your theme — should not be in charge of making specific types of content available on the site.
- Permalink/title/content manipulation – Again, content and appearance should be separate from each other. Therefore, any new shortcodes ought to be implemented using a plugin rather than registering those shortcodes through your theme. If you register shortcodes in your theme, you’ll have a bunch of missing content after you switch to a new one. For the same reasons, any functions that manipulate the titles of your posts or the links to those posts (such as Page Links To) should be implemented using a plugin.
- Spam, backup and security measures – This is another one that should be kind of a no-brainer. You don’t want to lose any security or protection you’ve implemented on your site just because you switched themes.
- SEO & Analytics information – This is one that is frequently overlooked. A lot of themes will include mechanisms to add your analytics code, set some keywords or a description, modify the titles and menu labels, etc. When you switch themes, though, you lose all of that information.
- External resources – If you want to include external resources like Twitter, Facebook, etc., you should use a plugin to add those items to your site. They are content pieces, not appearance features.
Bonus Round: What’s a MU-Plugin?
The concept of MU-Plugins carried over from WordPressMU when it was merged with WordPress at version 3.0. Originally, the “MU” in the term referred to WordPressMU. However, when it was implemented in WordPress 3.0, the “MU” came to stand for “must use” instead of “multi-user”.
The idea behind a mu-plugin is that the code will be automatically parsed on every page load. These files do not require any type of special header like plugins and themes do; they’re just plain old PHP files. They do not need to be activated; they are automatically active as soon as WordPress recognizes that they exist, and they are active on every site in a multisite installation.
To use mu-plugins, you simply need to create a directory inside of wp-content called “mu-plugins”. Then, any PHP file dropped into that directory will immediately begin to have an effect on your WordPress installation.
Perhaps the most valid use of a mu-plugin is to implement your analytics tracking data. Rather than including that data in your theme (which is a bad idea, as I mentioned above), or using a plugin that has to be activated on each individual site in a WordPress Multisite installation, it might make a lot more sense to place that code in a standalone PHP file that injects the code into the head of your pages.
Essentially, any functionality that needs to be present on all sites all the time, no matter which theme is being used, should be implemented as a mu-plugin.
Need Some Help?
Resources for Writing Plugins
- Writing custom functions for end-users
- Creating a site-specific snippets plugin
- Writing a WordPress plugin
2 replies on “Form Vs. Function: Is that a WP Theme or Plugin Function?”
[…] Form Vs. Function: Is that a WP Theme or Plugin Function? […]
Thanks a lot for a highly enlightening, clearifying and well written article!