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.
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.
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.
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.
- The theme support functions e.g.
- 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
- Custom post types
- Custom Taxonomies
- Custom functionality for other plugins
- Custom meta fields
- Mostly custom stuff
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
In you new plugin folder create a file with a similar name as the folder,
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.
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.
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.