WordPress Themes are fantastic. They let users take an easy-to-use CMS and make it look beautiful. The barrier to entry on the internet is lower than it has ever been, and WordPress has been a huge part of that. However, this also means that people who run WordPress websites don’t always have optimum knowledge of security and coding best practices. As a theme developer, or someone selling commercial WordPress themes, you have a responsibility to make sure that WordPress users have a website that is safe, speedy, and sustainable.
To ensure that your themes are the best they can be for your users, here are some best practices to implement in your development workflow.
Keep Your Theme Organized
WordPress has a lot of files. There are all of the templates that your theme needs, such as index.php and functions.php, then there is your style.css, and any other template files such as custom page templates you want to include in your theme. It is definitely possible to keep things organised though, especially if you follow some best practices.
Follow the Template File Checklist. It’s got a list of the different template files that you should include in your theme. It’ll also help you out with how to format your head area. If you’re struggling to understand the template hierarchy there’s a useful diagram in the WordPress Codex.
Follow Coding Standards
As well as keeping your files organized, you need to keep your code organized and in adherence to WordPress coding standards. This ensures that your code is standards compliant. Keeping your code standards compliant makes it easier to maintain, easier to read, and produces a faster, leaner, website. WordPress has coding standards for CSS, PHP, and HTML. Until you are familiar with the coding standards, you should refer to these as you are developing.
Test
Before you release your theme into the wild, you should test it. For some help on testing your theme there’s a checklist you can follow in the WordPress Codex. This will help you to ensure that your users aren’t going to encounter anything funky. If you’re not sure how to set up your test environment, the information on joining the WordPress Theme Review Team has a guide to setting up a test environment. The developer plugin has all of the tools that you need to run a proper unit test.
Localize
WordPress is used all over the world, and 40% of all WordPress downloads aren’t in the English language. That’s a huge number of people not using WordPress in English. If you’re serious about running a WordPress business you should be serious about localizing your themes. You don’t necessarily have to translate the themes yourself but providing the capabilities for someone else to do so is essential. The translating WordPress page on the Codex has lots of useful information. The functions you need to check out are __() and _e(). You’ll also need to familiarize yourself with Poedit or another translation tool.
Be Smart With Options
Theme options are a constant debate in the WordPress ecosystem. Done well they can enhance a user’s experience, but done badly they can make your theme confusing and difficult to set up. Most of the major theme shops include some form of theme options that allow users to customize the basics, such as changing fonts, colors, and layouts. There are lots of themes out there with multiple options panels, with options for changing the color of individual lines or element padding. Be smart about including options. Try to figure out what your user actually needs for the best user experience possible. Follow the WordPress philosophy of decisions, not options.
Document
Plenty of developers don’t feel the need to document their code inline. There is sometimes a perception that writing the code is enough – so long as the theme works the documentation doesn’t matter. It’s not true.
Inline docs mean that anyone who takes your theme can quickly understand what you do. If you’re selling a theme then technical users can open up the template files and find out what’s going on without having to struggle to understand why you wrote your PHP in a certain way. They also help future developers who are working on your product to do their job. If the original developer has left the company and isn’t accessible, the inline docs will help new developers to work on the theme.
The WordPress Codex has some useful information on documenting your code. You can also check out BuddyPress developer John James Jacoby’s post on why you should write inline documentation.
Copyright Attribution and License
The WordPress Theme Review guidelines state that all WordPress themes must be compatible with the GPL. For the WordPress repository, the CSS, HTML, PHP, images, fonts, icons, and everything else must be GPL compatible. You can either bundle the license with your theme or explicitly state the license in the header of style.css. You should also state copyright along with the license. If you’re releasing a theme that is derivative of another theme then you need to retain the copyright information of the original work.
Of course, not everyone releases their themes entirely GPL. ThemeForest releases its themes under a split license. The GPL only applies to any part of the theme that makes use of another product that is GPL – i.e. WordPress. While this doesn’t tie with the beliefs of the WordPress Foundation, it’s entirely legal to publish your themes this way. In the case of a split license, the PHP would be released as GPL while the other elements, such as CSS, JavaScript and images, would have a separate license.
Child Theme Preparedness
Child themes are the only way you should recommend that users make edits to a theme. A child theme inherits the styles and functionality of the parent theme. They always require a style.css file which includes the declaration of the parent theme in the header. This tells WordPress that the child should inherit from the parent. A child theme may also include a functions.php file, other template files that have changes made to them, and any other files.
If there is anything that you want your users to be able to overwrite in their Child theme you should use the get_stylesheet_directory() or get_stylesheet_directory_uri() functions. If there are elements that should not be overwritten by the child theme then you should use get_template_directory()/get_template_directory_uri().
Chip Bennett’s talk from WordCamp Toronto 2011 has lots more information on how to prepare your themes for child themes.
Enqueuing Scripts and Stylesheets
Scripts and styles will make your theme even more powerful. You may want to include JavaScript or jQuery, for example. The WordPress codex has information on including scripts and styles. You should always enqueue scripts that are bundled with WordPress. Don’t start enqueuing scripts hosted on Google, or jQuery or anywhere else. Other plugins will expect the core-bundled version to be registered by the theme. If they aren’t registered you’re going to cause compatibility issues.
There is a list of default scripts that are included with WordPress in the WordPress Codex.
Conclusion
WordPress provides an excellent experience for users. The themes you produce should enhance the user’s experience, not detract from it. After all, we don’t want users to start jumping ship to another CMS. Following best practices will ensure that your users get the best experience possible, which makes for a happy customer and a happy theme shop.
The post WordPress Theme Best Practices appeared first on YinPress.