Site-Specific Plugins: When, Why, and How To Use Them in WordPress

If you’ve ever built your own WordPress theme (or customized/added to someone else’s), you’re almost certainly familiar with the functions.php file. In many cases, this file (included with each theme) can be an excellent place to write some PHP snippets which affect the behavior of your site. But your theme is not always the best place to place PHP snippets, and here’s why.

What belongs in a theme?

As a general rule, anything that has more to do with how your site looksbelongs in your theme. That is, themes are all about presentation.

If you’re enqueuing theme stylesheets or scripts, need to call a function from multiple template files, or want to enable support for theme features like sidebars and post thumbnails, then functions.php is the place for you. You can even use the functions.php file to add custom fields to the WordPress Theme Customizer (using the Theme Customization API), then retrieve the saved theme settings when you need them in your theme.

I’d also suggest that other presentational(ish) items can go inside functions.php, such as filtering your post excerpts to be a certain length when they’re rendered. But there are some things that should work independently of a theme. In other words, if you switched to a different theme tomorrow, the important features of your site should still be there, functioning the same way they do now (even if they look different). In such a case, it’s time for a plugin.

What belongs in a plugin?

If themes are about presentation, plugins are about logic. A plugin isn’t really concerned with how your site looks, only how it functions. While many plugins will contain CSS and Javascript that are essential to a feature looking/working OK on the front-end, their primary purpose is to do something (rather than show it). Some things that are better-suited for a site-specific plugin include:

  • Registering custom post types or taxonomies
  • Adding and saving meta boxes
  • Modifying the Wordpress dashboard/admin
  • Creating options/settings pages
  • Adding tracking codes (such as Google Analytics or conversion pixels)
  • Building out custom features that should work independently of the theme (e.g., a calculator or a fancy calendar)
  • Doing anything that would still need to work if you changed to a different theme

Again, that last bullet point is probably a good rule of thumb. You don’t want your post types, meta fields, tracking scripts, and so forth to disappear whenever you change your theme. So put it in a plugin!

Writing a site-specific plugin is not as hard as it sounds

I don’t want to advocate cargo cult programming here, but if you’re well-accustomed to copying and pasting PHP snippets straight into your functions.php file, you can almost just as easily paste those same snippets straight into a plugin file. WordPress itself offers a useful guide to writing a plugin, and while some plugins are intended for use across many sites (e.g., those in the official WordPress plugin repository), it’s perfectly acceptable to write a plugin that’s specific to just one site’s functionality.

In fact, a plugin can technically be as simple as a single file that looks just like this:

<?php
/*
Plugin Name: Ryan's Awesome Example Plugin
Description: Adds a happy ending to every post/page
*/

defined( 'ABSPATH' ) or die( 'No direct file access allowed!' );

// Modify post content
function myplugin_filter_content( $content ) {  
  return $content . '<p>And they lived happily ever after. The End.</p>'; 
} 
add_filter( 'the_content', 'myplugin_filter_content' );

If your plugin is going to be complex, of course, I highly recommend using the WordPress plugin boilerplate as a starting point. It will help you organize your code (especially if you have multiple components) and assist you in taking an object-oriented development approach. But it may be overkill for just including a couple of filters.

But what if I don’t plan on changing the theme?

Now, I know what some of you are thinking: “I (or my client) will never change the theme, so I don’t have to worry about writing a plugin.”

And, if it’s really true that the theme will never be changed, then you’re half-right. The functions.php file functions just like a plugin. It will still “work.” That said, separating your logic from your presentation is nevertheless best practice for web developers, because it makes everything much cleaner and easier to understand (and thus less prone to human error).

Admittedly, the built-in structure of the WordPress software isn’t always the best at keeping logic separate from presentation, and it’s sometimes a bit difficult to decide where a piece of code really belongs (e.g., a custom breadcrumbs function). Keep in mind that these are meant as general guidelines rather than strict, clear-cut laws. But you can (and should) still strive to keep your theme free of functions that clearly belong in a plugin, and vice-versa. To review:

  • Plugins are about logic, features, and functionality. They should do the real behind-the-scenes “work” on your site and be primarily comprised of PHP code (with some supporting HTML, CSS, and Javascript as needed).
  • Themes are about presentation, design, and appearance. If your plugins are the car engine and electronics, your theme is the body, interior, and paint color. You theme should consist mostly of HTML, CSS and Javascript, with some bits of PHP sprinkled in wherever it’s required.

Of course, what constitutes perfectly-organized code will always be somewhat subjective. Still, if you can discipline yourself to try to adhere to these general rules, you’ll end up making things a little easier on yourself (and a heck of a lot easier on any other developer who has to work on your code in the future). So go on, download the WordPress plugin boilerplate (or use this handy generator) and get to it!

(And they lived happily ever after. The End.)