Extending WordPress with Plugins

Bernard Aybout (Virii8)

7 years ago

Extending WordPress with Plugins: The good thing about WordPress is its extensibility. Some of the WordPress lead developers have said that the most exciting WordPress features are the ones that don’t ship with the software. It is possible to make WordPress do just about anything you can think of with plugins.

The framework for this extensibility is made up of a very simple hook system. With hooks, plugin developers can change existing content and hypertext markup language (HTML) before it is actually rendered by the browser, or they can fire off actions when a certain event occurs.

Hooks are places in the WordPress code where plugins have the capability to “hook” into the core and add some bit of functionality. Hooks are an extensive part of the WordPress plugin architecture and are essential to the concept of modifying WordPress behaviour without modifying any core code.

This event-driven architecture gives plugin developers extreme flexibility. In fact, many core WordPress features are implemented through the hooks system, which means that plugins are not second-class functionality, but are on par with the WordPress core.

The WordPress core developers have not been hesitant to add more and more hooks to WordPress. It’s really generally only a matter of asking. Using this hook architecture, WordPress is able to remain small in size and lean in scope. It is not the intention to make WordPress everything to everybody by default.

It is about creating a lightweight blogging platform that has all the necessary framework elements to enable users to extend and modify WordPress to fit their specific needs.

Understanding WordPress Hooks

The bulk of the WordPress plugin application programming interface (API) is made up of two core elements, or hooks: actions and filters. They are conceptually different but very similar in practice.

Actions are event-driven. When specific events occur in WordPress, such as saving a post, loading an admin page, or sending HTML to a browser, plugins have the capability to “hook” into these events and create their own events.

As an example, a plugin might ping a server when a post is saved. Or it might update a social network profile using their API when a WordPress user profile is updated. Filters modify content. The content could be the text of a post, an author name, or an option pulled from the database.

Filters always take data and return data after processing it. An example of a plugin using a filter would be modifying a user avatar with a different third-party avatar solution.

In this scenario, a filter might replace the WordPress default Gravatar-based avatar and replace it with a user’s Twitter avatar. As the name suggests, filters are always Data in, Data out while actions are event-based and do not require any kind of data processing.

The anatomy of a hook

Hooks are generally called using the add_action() or add_filter() function. They can also be removed by using the remove_action() or remove_filter() function. You might consider doing this if there are undesirable (or conflicting) events with another plugin, or if you want to disable a WordPress core feature that is implemented through the hooks system. In their most basic form, these functions take two arguments.

The first argument is the hook name, such as save_post or the_content. The second argument is the callback you want to pass to the hook, such as insert_author_description or add_google_analytics. Generally, the second argument is a custom function provided in a plugin or theme functions.php file, but it can also be a core WordPress function or a class and method name.

If the callback is a function, the second argument will be a string that is the name of the function (for instance add_action(‘pre_post_save’,’function_name’);). If you are using object-oriented programming (OOP) and need to refer to a class and method, do so by making the callback an array with the first member the name of the class and the second member the name of the method (for instance, add_action(‘pre_post_save’,array(‘className’,’methodName’);)

Though most custom functionality comes via plugin files, you can also have code included in a file called functions.php inside a theme. Most themes will already have a functions.php, but if yours doesn’t, you can simply add one. This file exists so that theme authors can provide custom functionality specific to their theme, and it behaves exactly the same way that plugins work. The only difference is that you don’t have to manually activate this file in the same way that you do for a plugin.

It is included automatically when the theme is active. While most of the time it is only necessary to provide the hook name and the callback as two arguments when calling a hook, there are two other arguments that you can optionally use.

The first of these arguments (and the third overall) is the priority. Priority is an integer that designates which order the hook reference is called. The lower the number, the higher its priority, and thus, the earlier it is called. This is particularly useful when you have a number of other plugins or functions hooking to the same hook. The higher priority hook reference will be executed first. The default priority is 10.

WordPress hooks are scattered throughout the WordPress core. Before any HTML is returned to the browser on a page load, WordPress runs through a lot of code determining what the client (browser) needs to see. Throughout this process, hooks are “fired,” or executed.

Plugins and the theme functions.php file add all the necessary callbacks to each hook in a queue, based on priority order. When WordPress fires each hook, it iterates through every callback tied to that hook. All the resulting HTML and Cascading Style Sheets (CSS) in aggregate make up what is ultimately returned to the browser and seen by the reader.

The final argument is the number of accepted arguments you want to pass to the callback. In most cases, a hook only provides a single parameter and so this is not needed. However, some hooks can provide more than one parameter, and your callback might need that extra data. In this case, your hook reference would have an integer designating the number of additional arguments to pass.

Theme hooks

It is becoming standard for theme authors to include hooks in themes. Themes like the popular Avada theme makes it a point of loading many custom hooks into the themes.

Not only does it benefit users to have a lot of different options in the theme they use, but also has a significant benefit of turning themes into extendable frameworks. However, themes are not required to have any extra hooks.

They can operate perfectly fine without them. Three hooks, however, are virtually required for inclusion in any theme because so many plugins use them. Two of these hooks — wp_head() and wp_footer() — actually look like function calls and not actual hooks, but buried beneath the function are action hooks. The third is a more standard-looking hook and is positioned in the comment form:

[html] <?php do_action(‘comment_form’, $post->ID); ?>[/html]

Writing Your Own Plugin

With an understanding of the concept of hooks, it’s time to get your feet wet by writing your own plugin. Doing this is fun and can open up a whole new world of possibilities.

There is a sizable plugin repository already at http://wordpress.org/extend/plugins/, but sometimes you may have to write your own to accomplish a task no one else has or to do it better. Whether you write the plugin for your own use or release it to the world, you are sure to begin to understand the plugin building process better the more you do it.

Every plugin requires a set of headers for use in the plugin. You should try to come up with a unique name for the plugin. WordPress reads these headers and uses them in a variety of ways, including displaying them inside the WordPress administration panel (referred to as the WordPress Admin) and determining whether there are upgrades available for the plugin.

In this text, I walk through the steps to build a plugin that adds copyright text throughout a blog. To do this, you must first create a new folder inside of WordPress’ wp-content/plugins/ folder that you’ll call copyright-notices and then create a new file inside that folder called copyright-notices.php. The headers for this plugin might look like the code shown below:

[php] /*
Plugin Name: Copyright Notices
Plugin URI: http://your-domain-name-here.com/copyright-notices/
Description: A plugin that allows the user to set Copyright text in the
theme and control it from WordPress Admin.
Author: Bernie Aybout
Version: 1.0
Author URI: https://miltonmarketing.com/
*/[/php]

The headers are self-descriptive but it is important to note that only a plugin name is absolutely required. WordPress parses this data out for use in the WordPress Admin.

All plugin files are created with the PHP scripting language. Though PHP files can have HTML in them, unless otherwise specified, every file must begin with the PHP opening tag

[php]<?php[/php]

You can optionally add a closing

[php]?>[/php]

at the end of the file, but if you do, ensure there is no extra whitespace or your blog will break.

Extending the WordPress Admin

Development of administrative interfaces for a plugin is often where plugin development begins. Conscientious plugin developers provide some sort of interface for managing their plugin without having to resort to asking the end user to go in and edit a file.

However, taking this kind of approach to plugin development ensures problems later on when the plugin is upgraded, because any modifications made to the plugin will be overwritten. It’s much better practice to actually store setting data in the database and avoid hard coding it in the plugin itself.

Aside from the upgrade complications involved in not having a WordPress Admin page, there is also a usability question. Most WordPress users are non-technical users.

They don’t know what to do with PHP or object-oriented programming. They don’t know what a curly brace means or why semicolons are important. Making them dive into the code to configure the plugin is a recipe for making sure the plugin doesn’t have a high adoption rate.

Fortunately, WordPress offers a large number of hooks and functions inside the WordPress Admin that assist in creating new administrative plugins.

Creating an admin interface

The first step in creating a Copyright plugin is to create a function that generates the HTML that is going to be used inside the WordPress Admin. Most of the administrative duties will be done in this function, as shown below:

[html] function copyright_notices_admin()
{
?>

<h2>Copyright Notices Configuration</h2>

On this page, you will configure all the aspects of this
plugins.

<h3><label for=”copyright_text”>Copyright Text to be inserted
in the footer of your theme:</label></h3>

</form>

</div>

<?php
}[/html]

The first thing you might notice about the code above is that we have used very specific HTML markup to create an administrative panel. For consistency with the rest of the WordPress Admin, it is a good practice to fall into.

The entirety of the panel should be wrapped in < div class=”wrap” >< /div > to inherit the default formatting for the page. Main titles of sections of the panel should be wrapped in < h2 > tags.

The screen_icon() function inserts an appropriate icon, associated with the section of the WordPress Admin that the page will be loaded under, next to the header. You’ll use a lot of form fields, and so you’ll want to wrap the < label > tags in < h3 > tags.

To avoid the possibility of function names colliding, adopt a naming convention that is unique to you personally.

It could be an abbreviation for the plugin followed by an underscore (like hwp_doit()) or it could mean using a class to “namespace” your functions.

If a user activates your plugin and it has the same function name as a core function or a function provided elsewhere in WordPress, they will get errors and not be able to use your plugin.

Having observed standard formatting (which, of course, you can depart from with varying results), you’ll notice that when you try to activate the plugin on the Plugins page, it will activate, but nothing will happen. Looking further at the code, the second thing you’ll notice is the use of the get_option() function.

Don’t worry about this too much right now. Until you tie the plugin to the database, nothing will actually be displayed here. Later, it will show saved text and can be updated at will.

Adding an admin panel to the WordPress Admin navigation menu

Next you need to hook this function into WordPress itself by adding an Admin panel to the WordPress Admin navigation menu. Right now, this function is merely a standalone function. You need to tell WordPress about it and give it a menu position.

To do this, you will create a new function and use the add_submenu_page() function to register the new panel. The add_submenu_page() function exists to enable you to insert new WordPress Admin pages under top-level navigation items. It takes six parameters:

$parent. The filename of the parent page. In this case, you are using plugins.php, which is the page that controls the Plugins top-level navigation item. Others might be dashboard.php, edit.php, and so on.
$page_title. The name of the page you want to add.
$menu_title. How the page will be displayed in the navigation.
$access_level A capability synonymous with the permission level that should have access (such as edit_options for the blog admin).
$handle. A unique text string (“handle”) to identify your menu item.
$callback. The function that is handling the initialization/execution of this page.

Finally, you’ll want to plug that function into the menu using the admin_menu action, as shown below:

[html] function copyright_notices_admin_page() {
add_submenu_page( ‘plugins.php’,’Copyright Notices Configuration’,
‘Copyright Notices Configuration’, ‘manage_options’, ‘copyright-notices’
‘copyright_notices_admin’);
}
add_action(‘admin_menu’, ‘copyright_notices_admin_page’);[/html]

As an alternative to the add_submenu_page() function, you can use one of the wrapper functions that WordPress provides around this function. These alternative functions are listed below:

Function Name:	Function Syntax:	Function Description:
add_management_ page()	add_management_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Tools primary navigation.
add_options_page()	add_options_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Settings primary navigation.
add_theme_page()	add_theme_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Appearance primary navigation.
add_users_page()	add_users_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Users primary navigation.
add_dashboard_ page()	add_dashboard_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Dashboard primary navigation.
add_posts_page()	add_posts_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Posts primary navigation.
add_media_page()	add_media_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Media primary navigation.
add_links_page()	add_links_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Links primary navigation.
add_pages_page()	add_pages_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Pages primary navigation.
add_comments_ page()	add_comments_page(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback);	Adds a submenu page under the Comments primary navigation.
add_page_menu()	add_page_menu(‘Name of Plugin’, ‘Menu Title’, ‘capability’, ‘handle’, callback, ‘Custom icon URL’);	Adds a new primary navigation menu item with the added benefit of being able to specify an Icon for the menu. If no icon is specified, a default will be used.

Creating unique nonces for plugin form security

Nonces are an important part of plugin security for WordPress. They exist to ensure that a hacker or spammer does not forge data being sent by a form. A nonce is a computer science word meaning “a number used once” and is a unique identifier for a request.

To secure your plugin from cross-site request forgery, or more commonly known as CSRF, you need to ensure that you create a unique nonce in your form. You can do this by passing a distinct and unique string to the wp_nonce_field() function from inside your < form > tags. On the other end of the request, you will also verify that this randomly generated number is authentic. With the nonce included, the code for your form would look similar to the code below:

[html] function copyright_notices_admin()
{
?>

<h2>Copyright Notices Configuration</h2>

On this page, you will configure all the aspects of this
plugins.

<h3><label for=”copyright_text”>Copyright Text to be inserted
in the footer of your theme:</label></h3>

<?php wp_nonce_field(‘copyright_notices_admin_optionsupdate’); ?>
</form>

</div>

<?php
}[/html]

Processing data and interacting with the database

You need to add the form to the database. To do this you first need to verify that the request is authentic by checking the nonce created above using the check_admin_referer() function. After the request is verified, update the database with the plugin API provided by WordPress. The code to do this is shown below:

[html] function save_copyright_notices()
{
if( check_admin_referer(‘copyright_notices_admin_options-update’) )
{
if( update_option( ‘copyright_notices_test’, stripslashes( $_
POST[‘copyright_text’] ) ) )
wp_redirect( __FILE__ . ‘?updated=1’ );
}
}
add_action( ‘load-copyright-notices.php’, ‘save_copyright_notices’ );[/html]

In this listing, you have specifically checked the nonce with check_admin_referer(). In the event of a Cross-Site Request Forgery (CSRF) attack, this check would fail and nothing would happen. Because this works in the context of your plugin, the rest of the code in this listing will also work. After the nonce check is verified, you can use the update_option() to change the value. You are simply using the form data and don’t have to worry about doing a lot of data sanitization. WordPress already does the heavy lifting in this area.

One of the many benefits of staying within the framework of the WordPress API is that you can count on data being sanitized while using add_option() and update_option(). Likewise, these functions will serialize non-string data that you might pass to it, and get_option() will un-serialize data automatically. You get out what you put in.

The final portion of the code instructs WordPress to display a friendly “Options Saved” message if the transaction was successful. Congratulations. You have created your first WordPress plugin. With hooks, though, you can do even more with this plugin.

Loading JavaScript libraries

WordPress comes pre-packaged with a number of JavaScript libraries commonly used in user interface and Ajax development. The most common libraries — jQuery, Prototype, and Scriptaculous — are all bundled with WordPress, with jQuery being the preferred library for WordPress core development.

Ajax is an abbreviation for Asynchronous JavaScript and XML. Ajax is a loose-fitting word that describes highly interactive and transactional programming. It is notable because a Web site using Ajax can load data and perform actions transparently without the need for a refresh of the browser page. WordPress uses Ajax for a number of things, including Quick Edit functionality, category and tag creation from the Write screen, and more.

There are specific mechanisms in place to ensure that scripts are loaded with required dependencies and, of course, you as a plugin or theme developer, have the tools needed to allow your own JavaScript files and libraries to be loaded. WordPress does this using two functions: wp_enqueue_script() and wp_register_script().

Preparing JavaScript with wp_enqueue_script()

The first function used to add a script to the WordPress page load is wp_enqueue_script(). It takes all the JavaScript that it has to load and orders the scripts according to dependency. Typically, this function takes one or two arguments, unless it requires another library. Add-ons or plugins for existing JavaScript frameworks fall into the latter category. The first argument is a friendly name, or a handle, for the script. This handle might already exist if it comes preloaded with WordPress or if it has been registered (using wp_register_script()) somewhere else via the plugin. Otherwise, you can call a new piece of JavaScript anything as long as it is unique.

Using a non-unique name will not break WordPress, but it will replace a previously named script. Likewise, if another wp_enqueue_script() is used in another plugin or later in your own plugin and it uses the same handle, then whichever script is declared last takes precedence.

The second argument is the URL or path to the JavaScript file. It is optional, but if provided, it will also register the script with WordPress (similar to wp_register_script()). The third argument is a PHP array that lists each required library. Note that this list of libraries is by handle, not by URL. Optionally, you could add a fourth argument designating a version number of the library (such as 1.2 for jQuery 1.2), and a fifth argument that you would set to true if you want the JavaScript loaded in the footer or false if not. By default, the version is always the most recent and scripts are not loaded in the footer — they are loaded in the head. An example of loading the jQuery Cycle plugin is shown below:

[html] wp_enqueue_script(‘jquery=cycle’,’scripts/jquery.cycle.all.js’,
array(‘jquery’));[/html]

Creating new Dashboard widgets

One of the longest-standing requests in the WordPress community was to provide a way for users to customize the WordPress Admin Dashboard. This request was not only addressed on a global level; it was also addressed on an individual user level. The Dashboard incorporates the “drag and drop” capability, enabling you to pull widgets around and place them in the Dashboard according to preference. You can also hide widgets. Even more importantly, plugin developers can now make new Dashboard widgets available. Creating new widgets for the Dashboard requires three things: a function that generates the HTML in a widget, a function that registers the widget for the Dashboard, and a line that hooks the second function into the proper hook. An example of this widget creation is shown below:

[html] function example_db_widget_html()
{
?>

A great (but useless) Dashboard Widget

Hello World!

<?php
}
function example_db_widget_init()
{
wp_add_dashboard_widget(‘example-dashboard-widget’,’Example Widget’,
‘example_db_widget_html’);
}
add_action(‘wp_dashboard_setup’,’example_db_widget_init’);[/html]

In this code, the first function, example_db_widget_html(), provides HTML for the widget. Its formatting matches existing WordPress Dashboard widgets for consistency.

While the function in this example is fairly useless, it demonstrates exactly what this type of function should look like. You can use it for anything. Many plugin developers use data from third-party APIs such as Google Data APIs, Google Maps, or anything that fits their purposes.

The second function, example_dv_widget_init(), provides controller code that makes the widget available to WordPress. It only needs the wp_add_dashboard_widget() function. This function requires three arguments.

The first argument is a unique handler for the widget. This name will also become part of the CSS class that wraps around the HTML, so you can apply a custom look and feel for the widget.

The second argument is the display name for the widget. Finally, the third argument is the callback, or function name, that will provide the HTML. In this case, the callback is the name for the first function, example_db_widget_html.

Callbacks are used in programming to refer to an external function, class, or method that handles the actual execution of a code.

The third portion of this code hooks the example_db_widget_init() function into the wp_dashboard_setup hook. However, it is essential for the code to get “hooked” into the WordPress runtime.

Creating Events with Actions

Now that you’ve created your administrative panel and have stored your copyright text in the database, you can use it within WordPress. The most obvious place for this is in the footer of your theme.

Fortunately, most themes come with a wp_footer action that you can use to display the copyright text. But first, you need to write a function that will display the copyright text. See code below:

[html] function display_copyright()
{
if( $copyright_text = get_option(‘copyright_notices_text’ ) )
{
echo ‘

’ . $copyright_text . ‘

’;
}
}

[/html]

Because you are using an action hook to accomplish the task, there is no need to pass any arguments in the function. This is a distinct difference from filters that require an argument to be passed.

Now that you have created a semi-useful function for adding copyright text, you can add it to the theme via an action. For this, we use the action hook wp_footer like this:

[html] add_action(‘wp_footer’,’display_copyright’);[/html]

When you hook the display_copyright() function to the wp_footer hook, the function is added to the queue, to be executed when the wp_footer hook is fired in the header of the theme.

In order for this to work, the wp_footer(); function (which is a wrapper around the wp_footer action hook) must be included in the theme. The final code for this example looks like the code shown below:

[html] function display_copyright()
{
if( $copyright_text = get_option(‘copyright_notices_text’ ) )
{
echo ‘

’ . $copyright_text . ‘

’;
}
}
add_action(‘wp_footer’,’display_copyright’);[/html]

Modifying Content with Filters

The second kind of hook is called a filter. Filters, as their name suggests, take data, do something to it, and return modified data back. They are useful if you want to do something such as add an attribution notice to the end of every post or generate custom content for feeds.

As an example, you’ll see you how to add some copyright text to the end of every feed item to ensure that anyone using the feed cannot do so without some kind of enforced copyright notice (effective in combating spam blogs that scrape content and re-purpose it as their own).

The function for adding this code is shown below:

[html] function display_copyright_feed( $post_content )
{
if( !$copyright_text = get_option(‘copyright_notices_text’) )
return $post_content;
return $post_content . $copyright_text;
}[/html]

This function simply adds the attribution line to the end of the content and, for all intents and purposes, will work fine. Instead, though, you want to ensure that it only displays when the_content() function (which includes the_content filter) is executed in a feed. You do that by using conditional logic with is_feed(), as shown below:

[html] function display_copyright_feed( $post_content )
{
if( !$copyright_text = get_option(‘copyright_notices_text’) || !is_
feed() )
return $post_content;
return $post_content . $copyright_text;
}[/html]

WordPress has several expected coding conventions. They are enforced throughout the core and are often adopted by plugin and theme authors as well. The sample code shown earlier demonstrates one of those coding conventions by checking if the conditional logic is not true.

Checking for false (as in “this post is not in category 4”) is often easier and cleaner than checking for true. In this case, you performed a conditional check to ensure that the content was not in a feed.

If it is in a feed, you return the content exactly as you got it. However, if it is not in a feed, then you proceed to return the post content with the attribution line appended to the end. Finally, you need to hook this function to a hook like this:

[html] add_filter(‘the_content’,’display_copyright_feed’);[/html]

As with an action, hooking the display_copyright_feed() function to the the_content hook causes it to be fired every time the_content is fired in the Loop, the mechanism used by WordPress to generate and iterate over posts. Because this is a filter, the content_attribution() function expects the post content to be passed to it and it returns modified content back into the Loop.

The Loop is an integral part of WordPress. It is where the magic involving printing blog posts and content into a theme happens. For now, just understand that it is where WordPress processes the requirements for the selection of posts, fetches them from the database and returns the data to WordPress for processing. It is, notably, how WordPress is able to have a number of posts on one page, rendering the blog in expected reverse-chronological order.

The final code block for this section looks like the code shown below: (Using a filter to add a copyright notice to the end of every post.)

Using Multi-Argument Hooks

There are certain exceptions to the one-in, one-out nature of most hooks. In some cases, you need to be able to pass arguments to the functions being hooked and traditional hook usage won’t cut it.

The fourth parameter for a hook, which was discussed earlier, specifies the number of arguments the function can take. If, for example, a filter requires three arguments, you have to hook in like this:

[html] add_filter(‘author_link’, $modified_link, 10, 3);[/html]

An action that requires multiple parameters would be hooked into in a similar fashion:

[html] add_action(‘save_post’, ‘notify_google’, 10, 2);[/html]

Multi-argument hooks can sometimes be a difficult concept to understand, particularly if you are familiar with PHP development outside of frameworks and software packages such as WordPress. In a traditional sense, if you invoke a function, you need to also be able to directly pass arguments to it.

WordPress handles all this transparently, but you do need to ensure that the arguments the function is calling for are available in the scope that the hook is fired in.

For example, if you need to pass the $post variable to an action, you also need to ensure that the $post variable is available to be used in that scope. WordPress handles much of this with core hooks, but defining your own hooks in plugins and themes could prove tricky if you don’t understand this concept.

You can add your own hooks with the do_action() and apply_filters() functions. Each function takes a single argument that designates the hook name, while actions take optional additional values to be passed to the function (multi-argument hooks), and filters require a second parameter with the value that is being filtered; for example, do_action(‘below_post_1’) or apply_filters(‘author_name’,’James Boremen’).

Localizing Plugins

WordPress development efforts have put a major emphasis on localization. WordPress has been translated into more than 70 different languages. Beyond the scope of the core, which many international developers rightly provide internationalization support and translation efforts for, many plugins also support multiple languages.

In fact, sometimes efforts go into localizing themes as well. Localization is not a difficult process but it is a bit of work. Functions exist throughout the WordPress core that you can use in plugins as well. The engine that does the hard work of translation is called gettext and is included in PHP by default. The gettext library offers developers an API for localization and is very robust.