WordPress Functionality Plugins

The following is a guest post by Jason Witt. I’ve known for quite a while that I should port a lot of the stuff from my `functions.php` in my WordPress theme into a functionality plugin. But you know, hours in the day and all that. I recently had Jason work on this project for me, and he did a bang up job. If you have no idea what I’m talking about, read on.

Adding new functionality to a WordPress site can be as easy as searching for a plugin in the WordPress Plugin Repository and installing that plugin. But there is some custom functionality you might need that is either too basic or too customized for there to be a plugin for it. That’s where the `functions.php` file comes in. It’s essentially a functionality dumping grounds for a theme.

But some of the code we tend to put there would be better served elsewhere.

The `functions.php` file is an easy place to add things like theme support options, custom post types, enqueue JavaScript, and (really) anything else you can think of. For years this has been the de facto way of adding custom functionality to you WordPress theme. In the past couple of years there’s has been a movement of taking the functionality you’d normally put in the `functions.php` file moving it out into a “functionality plugin”.

What is a Functionality Plugin?

A functionality plugin is just a plugin like any other plugin you’d find in the WordPress Plugin Repository. The main difference is that it wouldn’t be publicly distributed, because it’s specific to your site. It’s one custom plugin that encompasses all your site’s custom functionality.

What’s So Great About a Functionality Plugin?

Why would you want to spend the time building a plugin when putting your functionality in your `functions.php` file is so easy? The big advantage is that you can reuse your functionality from theme to theme. When updating/changing your theme, some code in the `functions.php` will stay the same and some will change. The idea behind a functionality plugin is to take the functionality that will not change from theme to theme, and place it into a plugin. That way instead of sorting through your `functions.php` file for what you want to keep, you can just dive into the design of your new theme.

What Goes Into the Plugin?

This is the million dollar question. What does actually go into a functionality plugin? The best way to approach this is to decide what is specific to the theme and what is specific to the site. For instance, a custom post type would be specific to a site, and adding thumbnail support is specific to a theme.

Let’s pause on that for a moment so it can be super clear.

Imagine your website has a section for meetups on it. You’ve built a custom post type for them, so they can be a special type of content. On the front end of the site, you display them in a special way. On the back end of the site, you collect special information specific to meetups. Like in this CSS-Tricks video. We’ll call that Theme A.

If you change the theme of your site (Theme B), is it likely you’ll want your meetups to go away? Probably not. That is site content that you’ll likely want to transcend any particular theme.

If you had declared all that custom post types stuff (e.g. register_post_type())in your `functions.php` file of Theme A, then switched to Theme B – you might suffer a minor heart attack when you notice that all your meetups information is gone. Theme A’s `functions.php` file is no longer active, so all that code declaring the custom post type no longer runs. The menus are not added to the admin, the content will appear to be gone.

Rest assured, the data is still there, you just need to make sure the custom post types code runs again.

Why go through that at all? Just move that code into a functionality plugin and it will remain active even when switching themes.

Now imagine something different entirely: code in your `functions.php` file that enqueues a JavaScript library. You’re probably using that library do things on the front end of your site. That’s pretty specific to the theme. Another theme might use different libraries entirely, or none at all. That kind of thing makes sense to be in the `functions.php` file as it’s specific to the theme, not the content.

Examples of things that make sense in `functions.php`

• The theme support functions e.g. add_theme_support('post-thumbnails');
• JavaScript related to the front end
• Adding a custom post type to your home page post list
• Registering sidebars and nav menus
• Adding an external CSS file, for instance a custom font

Examples of things that make sense in a functionality plugin:

• Custom post types
• Custom Taxonomies
• Custom functionality for other plugins
• Custom meta fields
• Mostly custom stuff

Getting Started

If you’ve never make a WordPress plugin before, this is a great way to gain some experience.

To start, you’ll make a directory in you plugins directory. Name it whatever you want. Avoid using numbers and special characters; dashes and underscores are OK. I usually go with something mysitename-functionality.

In you new plugin folder create a file with a similar name as the folder, mysitename-functionality.php.

At the top of that file you want to ad the plugin file header information. Here’s an example to get you started.

/**
 * Plugin Name:       Your Functionality Plugin Name
 * Plugin URI:        http://example.com/plugin-name-uri/
 * Description:       This is a short description of what the plugin does. It's displayed in the WordPress admin area.
 * Version:           1.0.0
 * Author:            Your Name or Your Company
 * Author URI:        http://example.com/
 * License:           GPL-2.0+
 * License URI:       http://www.gnu.org/licenses/gpl-2.0.txt
 * Text Domain:       plugin-name
 * Domain Path:       /languages
 */

After that, go nuts and start adding your functionality below.

You can literally just cut-and-paste code from `functions.php` over to this file, and as long as this plugin is activated, it should work.

Modular Design

If you’re like me and like to keep things neat and tidy, this is a great time to use a modular approach to the code you place in your plugin.

One approach to keep things simple is to organize your functionality into similar groups and give each of them their own file. Then, include those files into the main file of the plugin using PHP includes. Make sure you notate your functions so when you return to them at a later date you know what’s going on.

include 'mysitename-functionality-post-types.php';
include 'mysitename-functionality-extra-rss-feeds.php';
include 'mysitename-functionality-remove-unwanted-assets.php';

Another approach is to use Object Oriented Programing (OOP). This involves creating PHP classes and methods. If you are not familiar with Object Oriented Programing there’s a great tutorial by Tom McFarlin called Object-Oriented Programming in WordPress. You should check it out if you’re interested in developing your WordPress coding skills. OOP is a great way to organize your code that’ll allow it grow as your functionality needs change.

Real Example

If you’d like to poke around the CSS-Tricks functionality plugin, here’s a repo on GitHub you can check out.

After this transition here, the only thing left in the `functions.php` file is queuing up jQuery and a hook that overrides the default HTML comment output – both things very specific to the current theme.