MSP WordPress #21 Plugin Intro Summary

Here is an overview of my session on building and translating plugins at last night’s meeting with lots of links to dig in deeper if you’re interested.

Plugins In Your Theme

If you customize the functions.php file of your themes, you’re already building plugins! Many tutorials will advise you to take a snippet of code and paste it into your theme’s functions.php, this isn’t really any different than making a plugin, and often times, this code should be a separate plugin.

It’s all too common for themes to try to substitute for plugins and add custom post types, taxonomies, or shortcodes to a site, but what happens when you switch themes? That content disappears.

What’s a theme? What’s a plugin?

A plugin could change the design of a site as easily as a theme, and any plugin could be crammed into a theme. But really a theme should only be managing the presentation of a site’s content, any new types of content or functionality should be enabled using plugins.

What should be in the theme’s functions.php?

Code to enable built-in WordPress functionality, like custom backgrounds and post thumbnails, sidebar registration, or a theme options page. This would be a good place to customize excerpts or enqueue scripts that are needed by the theme.

Don’t ever edit an existing theme, if you edit a theme in the official directory like Twenty Eleven and then update that theme, you will lose your changes. Instead fork the theme by changing the name to make it unique, or create a child theme for it so that you can safely update the parent theme.

What should be in a plugin?

Any functionality that you want to keep around regardless of which theme you are using. Some themes might not support the custom post types and taxonomies you are using without extra templates or styling, but that content should never disappear from the admin, and if you use a plugin it won’t!

Another thing to consider is how modular the functionality is, if you find yourself adding the same widget to themes again and again, it’s a great candidate for a plugin!

Site specific plugins

One good way to transition from using the function.php file to building plugins is a site specific plugin that acts as a standalone functions file you can use to add functionality specific to that site like a custom taxonomy for blog posts.

There’s a great post on WPCandy which explains why you might want a functionality plugin and how to build one.

General purpose plugins

A good place to start learning how to actually make a plugin is the codex article on writing a plugin. It can be a bit overwhelming at first, but don’t get discouraged. A polished plugin you release to the world might have some extra information and comments, but a simple plugin for your own use could be just a few lines.

I’d suggest watching some videos on building basic plugins. After watching a few and learning how different people are making them the learning curve won’t feel so steep!

When you start building plugins, you’ll start running into a few things that don’t come up very often in theme development, like hooks, actions, filters. Learning how these are used in the plugin API is essential and will save you a lot of headaches!

Another important detail is to prefix everything. You want to make sure that the functions, variables, the rest of the code you write is uniquely named so that it doesn’t conflict with code in WordPress, your theme, or other plugins. It also doesn’t hurt to clearly name everything so that you know what it is for, after all, this isn’t Twitter, there’s no character limit!

Translating your plugin

Supporting translations of your plugin is a good way to improve the usability for non-English speakers and build an international audience for your plugin. The documentation has plenty of information on this topic, but it’s not the most user friendly introduction, try using this tutorial instead.

Basically any text you want to translate needs to be wrapped in a function, the two most common ones are “__” and “_e”. Use the “__” function for returning text to be used in PHP, and the “_e” function for echoing text to output in HTML. In the example I showed the strings being translated were labels for a taxonomy, so it was all being returned rather than echoed.

Notice that in the example the functions contain not just the string to be translated, but also the basename of the plugin. This tells WordPress that the translation files for that string is located in that particular plugin after you have loaded that basename as the plugin domain. Just remember, don’t get clever when adding the basename. The PHP files need to be parsed by GNU gettext to generate the translation file, so don’t try to take shortcuts with variables.

You could download GNU gettext and try to generate a translation file on your own, but there are some easier options. If your plugin is in the repository you can generate this file right from the plugin admin. If the plugin isn’t in the repository, you can checkout the tools from SVN or use poEdit to generate this file.

Once your plugin is ready for translation, I recommend making it easy for translators to find the translation files and get their translation back to you. I have a languages page in the documentation of my plugin with translator credits and info for new translators.


I forgot to mention my favorite WordPress book during the meeting, Professional WordPress Plugin Development. The first couple of chapters really help build a good foundation for starting a plugin. The rest of the book goes deep into different details of plugin development and I have found it handy to reference specific chapters as I need them.

If you have any questions, leave a comment and I’ll try to point you in the right direction. Now get coding, I’m looking forward to seeing the member plugins list grow!

A couple of snapshots from the meeting