Customising WordPress Themes and Plugins
WordPress
WordPress is a great platform to use as a CMS (Content Management Scheme) for driving a website. It comes with great built-in functionality and many free and paid-for plugins and themes. Advanced features can be included very easily and quickly by both programmers and non-programmers, by simply installing these themes or plugins.
However, I often find that, while a WordPress plugin provides lots of functionality, it is often not exactly what the client wants. It typically takes 10 minutes to install the plugin and get 90% of the way there, but achieving the last 10% will be difficult. It may take many hours, perhaps researching alternative plugins, customising the WordPress plugin, or writing a plugin from scratch. If compromising between what’s desirable for the website and what’s easy to build is an option, that’s great. If not, we probably need to do some programming.
If the changes required are small, it’s often tempting to just tweak the plugin or theme directly. However, one of the problems of customising WordPress themes or plugins directly is that when the theme or plugin is next updated, the changes will get overwritten and lost. WordPress plugins and themes should be updated regularly, as there are often important security fixes that should be applied.
Cusomising WordPress Themes
If the site is to have a highly customised layout, it may be appropriate to build the theme from scratch, typically using a responsive grid framework or using one of the “blank” WordPress themes. Often though, starting out from an existing WordPress theme such as TwentyTwelve and customising it is a better and quicker way to go. Using “Child Themes” is the best way to do this, as it inherits functionality from a parent and allows altering the styling and functionality. Updates can be installed for the parent theme without wiping out the Child Theme.
Customising WordPress Plugins
Unfortunately there isn’t a “child plugin” mechanism. However, filters and actions can be used. These are written in the functions.php file (within your theme directory) and are used to hook into specific places within the plugin code to change or add functionality.
WordPress Child Themes
To create a child theme for theme such as “twentytwelve”, create a new directly in the themes folder, and create a style.css file within the new theme. Here is the file structure for my new theme “mytheme”:
wp-content/themes/twentytwelve/ wp-content/themes/mytheme/ wp-content/themes/mytheme/style.css wp-content/themes/mytheme/functions.php
The style.css file should contain a comment at the top with the following code. Values should be updated as appropriate and most are optional, but Template must match the name of the parent theme directory. A CSS customisation, such as turning the text red, can be included to check it’s working once the site has been updated to use the new theme via the admin.
/*
Theme Name: My Theme
Theme URI: http://mytheme/
Description: My Description
Author: My Name
Author URI: http://mysite/
Template: twentytwelve
Version: 1.0
*/
@import url("../twentytwelve/style.css");
body { color: red; }
style.css
CSS code can be included in style.css to override the values in the parent theme. If you want to use the parent’s styles, which you typically do, the @import line must be included.
Templates
PHP template files can be copied over from the parent theme and modified. These files will override those in the parent theme. This is useful for major changes in layout.
Using functions.php
The functions.php file in the child theme is run in addition to the functions.php file in the parent theme. Code can be written here to take advantage of “hooks” in the parent theme, plugins, or WordPress itself, to add, or alter functionality.
There are two types of hook called actions and filters. These are defined in the parent plugin code with the functions do_action() and apply_filters(). As of PHP 5.3 we can use anonymous functions (which I like) instead of defining named functions when writing code to utilise these hooks.
Actions
Actions are triggered at specific points, or events, during execution. They are typically used to output some additional text or perform some additional processing. For example, hooking into the twentytwelve_credits action in the TwentyTwelve theme to add another link:
add_action('twentytwelve_credits', function(){
echo '<a href="http://www.senktec.com">Built by Senktec.com</a> | ';
});
Filters
Filters are triggered similarly to actions, but are passed some content and typically perform an operation on the content and return the altered version. For example, this could be used for wrapping extra HTML tags around some content to allow more control over the styling, or perhaps to change the values used such as dimensions for an image or the name of a template. This example hooks into the img_caption_shortcode filter in the WordPress core to override the way the images with captions are displayed:
add_filter('img_caption_shortcode', function($content, $attr, $image_html){
return '<div class="my_image">' . do_shortcode( $image_html ) . '</div><div class="my_caption">' . $attr['caption'] . '</div>';
}, 10, 3);
The two parameters after the function are optional and default to 10 and 1. The first is the priority that this filter is run at. If there are multiple filters defined, they will run in order, lowest first. The second is the number of parameters passed to the function.
Other functions
In some cases functions are defined in plugins wrapped with a function_exists() if statement. For example to render the twentytwelve navigation:
if ( ! function_exists( 'twentytwelve_content_nav' ) ) :
function twentytwelve_content_nav( $html_id ) {
// ...
}
endif;
These functions can be defined first in the functions.php file, which will override the parent’s version. For example:
function twentytwelve_content_nav( $html_id ) {
echo "Nav removed!";
}
Customising WordPress plugins without Hooks
Ideally the author will provide many relevant hooks, so that you can alter the functionality of the parts you need. This way, when the plugin is updated the changes will not be overwritten. If there haven’t been any significant changes to the plugin, the changes will most likely continue to work, but it’s always a good idea to test them before updating a live site.
If the changes would be useful for others too, you could make a request from the original plugin developer, or even submit them the code, so they have the option to integrate the functionally if it’s deemed appropriate. Most of the popular WordPress plugins are hosted in Subversion, but some also are hosted on Github, where it’s easier to fork a plugin and make your changes.
One way often suggested to get round the problem of updating plugins is to set the version number to something like 9999, so that the modified version stays ahead of the original and the changes don’t get overwritten. It’s a bad idea to run out-of-date plugins, so this is not a great solution. If you end up having to do this, perhaps copy the plugin to a new folder where you make the modifications, and keep the original plugin disabled so you are alerted to updates and can merge them into your modified plugin as needed.