8 Things to Check When Reviewing a WordPress Theme (part 1)

1. Error log

First, try enabling WP_DEBUG in your wp.config.php file. These are the settings that I usually use:

This will help to catch a number of PHP mistakes that may not cause problems initially, but could potentially cause unpredictable bugs later. It’ll also log any WP_Errors when you use any WordPress functions incorrectly.

You can also try setting WP_DEBUG_DISPLAY to true, so that PHP notices will display on the front-end. I usually check the debug.log file often enough during the process, though, that this isn’t necessary.

2. Sanitizing/Escaping/Validation

Security is a huge concern for WordPress sites – it seems like another plugin or common theme has vulnerabilities that are discovered every day, and then sites with the compromised version of the plugin get hacked. Much of this can be prevented by handling user input correctly.

When saving user data, such as from an input field in a custom meta box, the data should be sanitized, or if possible, validated. WordPress includes a number of functions such as absint() and sanitize_text_field() to help this process.

When it can be done, input data should be validated in addition to sanitized. For example – if the input field consists of two radio buttons, with values of “yes” and “no”, the input should be checked to see if it is either “yes” or “no”, and if it doesn’t match, it should be discarded. If a number is expected, such as a Zip Code, the intval() or absint() functions should be used to ensure a number value.

Escaping is important when the data is displayed – this is how you prevent any malicious code that could have made it into the database from being output. Functions such as esc_html() and esc_attr() work for escaping data.

Here’s an example of unsafe output:

And the corrected version:

To see the full list of functions that WordPress includes for sanitization and escaping, see the “Data Validation” page in the Codex.

The most comprehensive guide I’ve seen to sanitizing and escaping is WordPress VIP’s – I recommend checking it out and following their guidelines.

3. Namespacing

In a WordPress theme, unprefixed functions all exist in the global space, and could potentially conflict with functions with the same names in plugins or WordPress core itself. For example, your theme may have a function called custom_excerpt_length(), and a plugin that modifies excerpt content could have a function with the same name. This will result in a fatal PHP error.

One solution to this is to prefix function names with either your company name or the theme name – so custom_excerpt_length() would become my_theme_name_custom_excerpt_length(). Alternatively, you could wrap the functions in a class, which can also be a cleaner way to organize them:

If you don’t need to support PHP 5.2 (and you probably don’t or shouldn’t anymore, unless you’re trying to distribute your theme in the wordpress.org repo), you can also take advantage of PHP namespaces, to keep the functions out of the global scope:

For more on seeing how to use PHP namespaces and how to reference the functions, see the namespacing documentation on php.net.

4. Coding standards

WordPress.org has an excellent set of coding standards for PHP, HTML, JavaScript, and CSS.
https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
https://make.wordpress.org/core/handbook/best-practices/coding-standards/html/
https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/
https://make.wordpress.org/core/handbook/best-practices/coding-standards/css/

While a theme may be well-written and not necessarily follow the WordPress coding standards, it’s a pretty reliable indicator that something was done well by an experienced WordPress developer if the code matches the standards.

During the development process, it can be very helpful to run PHPCS with the WordPress ruleset to ensure that your code conforms to the standards. Packages for Sublime Text and PHPStorm exist, so that you can automatically scan the files you work on whenever they’re saved. PHPCS will catch some PHP errors as well, which will save some time if you can see the potential errors in the editor before testing the code.

For more, see part 2.

Leave a Reply

Your email address will not be published. Required fields are marked *