Getting Started with WordPress Plugin Development
Plugins are PHP scripts that alter your website – basically, bits (or even lots!) of code that can be uploaded to your WordPress install to extend and expand the functionality of your site, without having to hack the core code.
The great thing about plugins is that they allow you to add features to your site and remain intact, even if you switch themes or upgrade your WordPress install.
Creating a plugin of your own is really not that difficult and can solve a lot of problems. Copying and pasting useful code and additional features into your theme’s functions.php file is great, but these changes may be lost when you update your theme. A plugin is a safe way to try out new things and the way to go if you need to implement cross-theme functions.
This article will walk you through creating a plugin, and we’ll also look at some intermediate/advanced concepts:
- A simple plugin that integrates WordPress with Facebook Open Graph
- How plugins work
- Using hooks
- Getting started with filters
- Adding scripts and styles
- Creating a plugin settings page
- Enabling translations
This post will help level up your dev skills by getting started with plugin development. Having a little knowledge of editing files and some rudimentary HTML and PHP are suggested to best follow along.
A Simple Plugin Project
In this article we’re going to create a plugin that integrates WordPress and Facebook Open Graph. Open Graph tags are special HTML tags, which give Facebook the information it needs to share your page and ensure it looks great.
Here’s a set of example tags, which could be used on the page you are reading right now:
For this project, we need to make sure that whenever a single blog article is shown, Open Graph tags are added to the header of our website. Site heads consists mostly of metadata and other hidden bits of information, and are added between the
</head> tags in an HTML document.
The next part of this article will focus on getting this done. After this example, I’ll venture more deeply into plugin development territory.
The first thing you need to do is create a folder to store your plugin. Go to the
wp-content/plugins/ directory in your WordPress installation and create a folder called
my-facebook-tags. Keep in mind that whatever you name your plugin’s folder will be your plugin’s slug.
A plugin slug should be unique throughout the WordPress Plugin Repository if you want to upload it and make it publicly available. What this means is that no other plugin created by anyone else should have this slug. You can search for existing plugin slugs easily, just use Google!
Keep in mind that the plugin’s name is not necessarily the same as its slug. Take a look at the iThemes Security plugin. The last bit of the URL is the slug:
better-wp-security. The name of the plugin, however, is iThemes Security.
If you’re just making a plugin for yourself it is still important to make sure slugs don’t clash. During the lifetime of your website you will probably use a number of plugins and you don’t want one to accidentally clash with yours and cause problems on your site because of a naming conflict.
Now that you have your
my-facebook-tags folder, create a new file inside and name it
my-facebook-tags.php. This will be your main plugin file and its name should be the same as your plugin’s slug, with the PHP extension tacked on.
Open your plugin’s main file and paste in the following code:
This code is a PHP comment, which won’t be visible directly in the WordPress admin. WordPress does use the data within it to output the plugin’s name and some other data in the Plugins section of the backend. This is tailored to WPMU DEV’s website, so be sure to modify the plugin author and other strings as you see fit.
Once you’ve saved this file, congratulation are in order because you’ve just created your first plugin! It does absolutely nothing, of course, but it should be available in the plugins section and you should be able to activate it – go ahead and do that now.
Let’s pause for a moment to look at how plugins work before we continue with our Facebook Open Graph project.
Plugins provide functionality with hooks, therefore understanding how they work is crucial. Let’s look at a real world analogue for hooks. You know those little diaries where the first sentence says: I am the diary of _________. The empty line is where you put your actual name.
The company could of course go through all the names and create prints of each one but it would not be economical and a lot of people would be left out. Also, what if you want to put “The Master Of The Galaxy” instead of your own name?
That blank line is a hook. Instead of being specifically printed for a person it prompts the user to add his/her own name. Hooks work something like this in WordPress, let’s look at an example.
Themes are required to add the following function to the header file:
wp_head(). Within this function is a bit of code where WordPress says: If a plugin wants to put some code here they may do so. The
wp_head hook allows us to output something in the head section of the page, which is exactly what we need. Let’s test this.
The first line of the snippet above tells WordPress that we would like to attach some functionality to the
wp_head hook using the
The second line of code creates that function and the third line echoes a simple string.
This should now be visible at the top of any theme you activate, as long as it defines that
wp_head() function (defining it is a requirement). We’ll remove that echoed string soon since you should never display text in the head section.
For the sake of correctness let me mention two things. There are two types of hooks: actions and filters. In the case above we used an action which is obvious because we used the
add_action() function. Actions run whenever WordPress detects the hook that calls them.
Filters are similar but they modify a bit of data which WordPress uses. A good example is the logout message that is shown. Instead of performing an action whenever a logout message is shown, a filter allows you to modify the logout message itself. We will not go into hooks in detail here. I recommend taking a look at our article, A Quick (and in-Depth) Guide to WordPress Hooks, or the WordPress Codex if you would like to learn more.
The last thing I want to mention here is that technically a hooked function gets executed when the
apply_filters() function is executed. The
wp_head() function contains calls to these other functions within it – it is not the hook itself.
Completing Our Plugin
Based on the description above it’s pretty clear we need to add our Facebook meta tags using the
Here’s the rest of the code needed for our plugin, followed by an explanation:
I’ve basically pasted our meta tags into the function as-is. The only things I needed to modify were the values to make sure they reflected the currently shown post. I used the
is_single() WordPress Codes (and search for “conditional_tags”) to make sure that the tags are only added when a single post is shown.
In order to use the title, excerpt, image, etc of the current post I used template tags. The only bit of trickery I used was to check if the post has a featured image before displaying the Facebook tag for it.
With this single function in place we’ve created something quite useful. All of the posts on your website should now have Facebook-friendly tags. You can make sure they’re set up properly using the Open Graph Debugger.
And now our plugin is complete. Let’s now look at some other plugin concepts.
Now that you know how to add things to the head section of your website, let’s look at inserting elements into other parts of your site.
Using actions is pretty easy. If you want to perform an action whenever WordPress does something, you are looking for a hook.
What about loading Google Analytics tracking on each page? This should be done in the footer. Perhaps themes define something similar to
wp_head? Indeed they do. Using
wp_footer you can output code at the bottom of the page. WordPress itself uses these two hooks to place scripts and styles in their correct places.
So far this has been easy because these are hooks you can kind of see in the theme. But how about more “hidden” cases? What if you would like to send a post’s author an email once their post is published. This screams “action” because you are saying: When WordPress publishes a post, then do something.
Finding these hooks has become a lot easier these past years. They are usually well named: user_register, publish_post, profile_update, etc. If you type “add user WordPress hook” into Google you will likely stumble upon “user_register” immediately. From there it’s just a matter of reading documentation. Let’s use publish_post to send authors an email when their posts are published. Here’s our code:
Note that when I used the
add_action() function I specified two additional parameters. The third parameter is the priority, which dictates when the action is executed. You may want to add multiple functions into the same hook and WordPress itself might use it too internally. The higher the priority, the later the action is performed.
The fourth parameter states how many arguments are passed to your functions. This is something you need to look up since it is not obvious from the name of the action. You can either look at WordPress documentation, or look into the WordPress source code to see where it is defined – the former is definitely easier if you’re just starting out.
Our best pro WP tools in one bundle
Inside the function I use the attributes of the post to get the authors email address and the title and link to the post. I construct a short message and use WordPress’ built in mailing function
wp_mail() to shoot a quick email.
Again, how did I know this existed? Google! While it is entirely possible to write your own mailer function, a quick search for “WordPress mail” will reveal this function in a jiffy.
I mentioned earlier that filters are similar to hooks, but they allow you to modify data before it is used instead of implementing an additional action. For this example, let’s change the error message you get in the login form when you type an incorrect password at www.example.com/wp-admin
Since there is an error message regardless of our plugin – we just want to modify it – chances are we’re looking at a filter. There is indeed a filter named “login_errors” so let’s leverage it and modify the message:
The first parameter of every function you add to a filter will always be the filtered data. If you return this without modifying it you will end up with the original functionality. In our case let’s always show the same error message. This can be useful if you want to hide the root of the error. If you enter a correct username but incorrect password WordPress actually tells you this, giving hackers a bit of information. By having a single error message this information is hidden.
Filters and actions are used extensively for almost everything in plugins so I urge you to take a look at them in depth and familiarize yourself with their mechanism. You can find out more at the WordPress Codex.
The action we use is horribly named because
wp_enqueue_scripts is actually used to add both scripts and styles to the front-end. In the hooked function we use
wp_enqueue_style() to add our style. The first parameter is the slug or handle of the script (this is up to you), and the second parameter is the URL of the script.
//url.com instead of
http://url.com is a neat trick which allows browsers to grab the appropriate version of the script. If your connection uses https it will retrieve the HTTPS version, otherwise it will use the regular HTTP version.
You can, of course, load assets you’ve made and store within your plugin. Let’s load a custom script we’ve made using the enqueueing method:
The process is much the same but I’ve used more parameters in the
wp_enqueue_script() function. The third parameter defines the dependencies of the script. WordPress makes sure to load all the dependencies properly so even if you enqueue a dependency later they will be loaded correctly. The fourth parameter is a version number you can choose yourself. These additional parameters are available for the
wp_enqueue_style() function as well.
To learn more about enqueueing take a look at our article on Adding Scripts And Styles To WordPress The Right Way.
Many plugins call for some options the user can set. Perhaps you want to disable Facebook Open Graph tags on some posts, or even disable the author email when you publish posts have you written? Both of these these can be implemented using options.
There are a number of ways to go about creating options for yourself, including some options frameworks out there. For simple options its easier to do it ourselves, and we are here to learn, so lets get started.
The best method to use is an object oriented approach, but I will use a simpler approach here. Take a look at the Creating Options in the WordPress Codex for both the simpler and the object oriented approaches.
The first thing we’ll do is create a menu entry in the backend where we can place our settings user interface:
Note that we’re using an action – of course – to do this. Whenever WordPress sees the
admin_menu hook it executes all functions tied to it. We happened to add a function to it ourselves so it will take that into account when building the menu.
add_menu_page() to create a top-level menu entry. This function takes a number of arguments:
- Page title – used in the title tag of the page (shown in the browser bar) when it is displayed.
- Menu title – used in the menu on the left.
- Capability – the user level allowed to access the page.
- Menu slug – the slug used for the page in the URL.
- Function – the name of the function you will be using to output the content of the page.
- Icon – A url to an image or a Dashicons string.
- Position – The position of your item within the whole menu.
I’ve created the empty function
my_plugin_settings_page() (you’ll notice I added this as the fifth parameter). I’ll also add the content of this function in just a moment. At this stage you should be able to see the new menu entry at the bottom of the menu.
Before we create the user interface for manipulating settings, let’s let WordPress know what settings we intend to use. This is called registering our settings. For this example let’s presume we want to create a place to store the contact information of some key staffers who are not a part of our web project, for example our accountant.
As you can see, I hook a function into
admin_init, inside which I use
register_setting() to add our options. The first parameter should be an option group, the second the actual option. I recommend using the same option group if you only have a few options.
So how in the World did I know that I need to use
admin_init here? The WordPress Codex of course! In some cases the hook you need to use is obvious. In other cases you’ll need to look it up. In some cases you can use different hooks while retaining functionality. In these cases there is usually a recommended way of doing things. Always search in the Codex before you implement a hook and you’ll be just fine.
So now that we have our admin menu entry and we’ve registered our settings, let’s create a form to display the user interface. Paste the code below inside the empty
There are three things to keep in mind when building a form like this:
- Use the
settings_fields()function, adding the option group as the first parameter. This outputs some hidden fields WordPress will use to save your data.
- Use the option names you defined while registering them in the name parameter of the inputs.
- Grab the value of a field using the
get_option()function, passing it the option name as the first parameter
With that, you’re all done! WordPress takes care of saving everything since you are using the built-in Options API. Well done!
This is definitely not a priority when you’re creating plugins for yourself, but it is a good idea to get in the habit of translation readiness as it is good practice for any public plugin.
The basics are really very simple. Any time you output some text, wrap it in either the
__() function or the
_e() function. Use the former for returning the string, the later for echoing it. For example:
The first argument of the function is the string to translate, the second is the text domain. This should be the same as your plugin slug.
By using these functions you will allow others to translate your plugin into their own language. This is a simple procedure that can help so many, so why not do it? There is a little more to it than these two functions, but by knowing only the above you are 99% of the way there.
To learn more about translating plugins take a look at our article How To Create A Translatable Theme Or Plugin.
There are tons and tons of things you can do with plugins and almost as many ways you can create them. While I am a very strong advocate of WordPress standards and doing things just right (object oriented approach, in many cases), I urge everyone to experiment.
As long as you’re not creating a product for distribution, feel free to do whatever you like. Don’t worry about complicating your life with methodologies you don’t yet understand. Do your best to research hooks that can help you add your functionality and make things work in whatever way you can.
The knowledge to do things right often comes to you after you are able to do things wrong, so don’t be too bothered about the rules for now.
Good luck with creating your own plugins!
Editor’s Note: This post has been updated for accuracy and relevancy.
[Originally Published: January 2015 / Revised: March 2022]