Following on from his article that shows how you to write perfect Wordpress themes, expert developer Corey Ellis highlights 4 problems to avoid when building them.
These are arguably the two most important hooks in a WordPress theme. You will break everything if you remove them. They basically perform the same function, but do it in different locations.
The wp_head() hook should be included right before the closing </head> tag (usually in your 'header.php' file) and
wp_footer() should be included right before your closing </body> tag (usually in your 'footer.php' file).
In the WordPress tips feature we talked about loading files in the header or the footer. These hooks are how WordPress includes these enqueued stylesheets and scripts on the page.
Not only does your theme need them to function correctly, but plugin authors also use them to add stylesheets and scripts.
When I was a freelancer and a client would tell me a script or plugin was not working correctly, the first thing I would check for was calls to these hooks in the theme. A huge number of times, I found these hooks missing.
02. Don’t fill up functions.php
Everyone on my team knows I am very particular about how we structure and architect our projects. If your theme is simple and your 'functions.php' file is under around 100 lines or so, then you can skip to the next section. Still with us? Good.
Most of the sites I build at 10up are massive undertakings. They are the kinds of projects that involve multiple sets of hands and many months.
For this reason the way we structure our work is vitally important. Our work has to make sense to everyone else on the team, but it also makes sense down the road when someone else picks it up to work on it.
The basic rule here is not to cram everything into one file. This makes your code harder to read and maintain. Also, when working in a team, having concerns separated into different files makes collaboration a more enjoyable process.
While we don’t necessarily strictly follow the single responsibility principle unless we are writing a true OOP class, the aim is to maintain a 'one file equals one concern' principle.
An example functions file might look like this:
<pre>
<?php
/**
* theme functions and definitions *
*
* @package Core
* @since 0.1.0 */
namespace Core;
. / useful global constants define( 'CorE_VErsIon',
define( 'CorE_url', directory_uri() );
define( 'CorE_tEMPlAtE_url', get_template_ directory_uri() );
define( 'CorE_PAth', directory() . '/' ); define( 'CorE_InC', 'includes/' );
define( 'CorE_AssEts', CorE_url . '/assets/' );
get_template_ CorE_PAth .
/ Include files
require_once CorE_InC . 'setup.php';
require_once CorE_InC . 'navigation.php'; require_once CorE_InC . 'settings.php'; require_once CorE_InC . 'query_mods.php'; require_once CorE_InC . 'views.php'; require_once CorE_InC . 'helper.php'; require_once CorE_InC . 'seo.php';
/ load Files
add_action( 'after_setup_theme', 'Core\ navigation\setup' );
add_action( 'after_setup_theme', 'Core\Query_ Mods\setup' );
add_action( 'after_setup_theme', 'Core\Views\
setup' );
add_action( 'after_setup_theme', 'Core\setup\ setup' );
add_action( 'amcn_setup_theme', 'Core\seo\ setup' );
add_action( 'init', 'Core\settings\setup' ); </pre>
03. Don’t litter your templates with logic
The concept here is very similar to the last tip. Unlike other frameworks, WordPress makes it virtually impossible not to mix logic, PHP and markup. But we can be careful to use as little of this logic inside of our templates as possible.
Write functions (that you include from your 'functions.php' file) to build your logic. Include the functions in your template – or even better, include them in your template parts.
WordPress powers approximately 23 per cent of the internet. That means a couple of things.
Firstly, that there are millions of people entering data either on their self-hosted WordPress websites or on sites hosted on wordpress.com. And secondly, that WordPress is often under attack by people trying to harness its reach for malicious purposes.
Sometimes users don't even realise when they are entering potentially harmful data. For those reasons, if
we want to create secure code we should never trust user input. Read more on this in this IBM post: netm.ag/user-267.
I will not delve deeply into the process of validating and cleaning up users' input before it is added to the database (where WordPress stores all the content and
data users enter from the admin area) – that sounds like plugin territory to me.
However, for our themers it is important that we properly ensure the data is secure before we show it to the user on the page (known as 'escaping' the data).
If you are building a theme and are creating metaboxes and systems for
users to input data and content, I suggest you read WordPress' guidelines on data validation (netm.ag/valid-267) and plugin security (netm.ag/plugin-267) and watch Mark Jaquith's 'Theme and plugin security' talk (netm.ag/jaquith-267) to make sure you understand how to properly validate and sanitise user input.
On the WordPress VIP blog there is an excellent article about why we escape data as late as possible (netm.ag/escape-267). WordPress provides us with several helper functions we can use to make sure that the data we get from the database is the kind of data we're expecting and to remove potentially harmful HTML or scripts.
The functions I use most often are esc_html(), esc_attr() and esc_url( (netm.ag/functions-267). Remember, security is your responsibility – it isn't just the job of 'those backend folks'.
Words: Corey Ellis
Corey is a senior frontend engineer at 10up. He's also the organiser of WordCamp Austin 2015 and helps run the WordPress Austin Meetup coreyellis.me. This article was originally published in net magazine issue 267.
Liked this? Read these!
