The doing it wrong theme serves as a tool for theme reviewers as well as theme authors to better understand the requirements needed to be met before a theme can be made live. Currently there are fourteen required sections that are looked over when conducting a theme review. They are as follows:
- Core functionality/features
Many of the requirements will overlap with other sections. An example of this is the language requirements. All themes need to be translation ready. What this means is the theme must use the WordPress translation functions such as
_x() and they must follow core implementation. This means explicitly declaring a text domain, and loading the text domain. This can be done using
load_theme_textdomain() inside of a callback function hooked to
The following serves as a guide of some common sections that can be missed or over-looked.
It is a given that a theme hosted in the repository should be error free. PHP and JS errors are not welcome here, right? They do happen. Some of the common ones are undefined variables and the rare occasion of when a theme’s option is not set. One example of this can be custom colors being used and not setting a default for
get_option depending on how your options are setup.
background: url( <?php echo get_theme_mod( 'trt-bg-divider' ); ?> );
Another example would be element attributes. They do happen and they can be missed. In the following example, an alternate text field is not escaped properly and can lead to potentially breaking the theme’s design.
<?php $alt = get_theme_mod( 'alt-for-img-1' ); ?>
<img src="path/to/img.gif" alt="<?php echo $alt ?>"/>
This can be something so simple as creating a custom background setting, custom header setting or even displaying a category list. What this entails is rather than using core functionality a theme author will create their own version of a core function. An example of this is dates. In the following example you can see the theme is hard-coding the date format making it hard for a user to change that by either creating a child theme or changing the corresponding code:
<p>ublished: <?php the_time('F j, Y'); ?></p>
Instead themes can use:
<p>Published: <?php the_time( get_option( 'date_format' ) ); ?></p>
// or perhaps
<p>Published: <?php the_time( get_option( 'time_format' ) ); ?></p>
In simple terms, it has to be user-configurable just like the display of posts on the front page.
Yes, it does sound a little odd as this is often times one of the first things you see but it can be a common one. In the
<head> of the document, there may be one or more files that are included using the
get_template_directory_uri() there are times when they will try and load from a third-party. An example of this can be Google fonts or even jQuery. All stylesheets and scripts have to be enqueued and hooked to the proper hook.
Example of proper usage:
add_action( 'wp_enqueue_scripts', 'trt_styles_scripts' );
wp_enqueue_style( 'trt-parent', get_stylesheet_uri() );
wp_enqueue_script( 'trt-js-file', get_template_directory_uri() . '/js/trt-js-functions.js', array( 'jquery', 'backbone', 'underscore' ) );
wp_enqueue_style( 'trt-monst-font', '//fonts.googleapis.com/css?family=Montserrat' );
While themes are not required to document every aspect of the theme it does need to have at the very least licensing and copyright information, and any design limitations. For example, if a menu location only displays two levels it should be noted in the readme file of the theme. Please note that all resources included in the theme have to be GPL compatible. This applies to images as well as the code in the theme.
As you can see some of the documentation is making progress but we still need more examples. As we are getting closer and closer to the release of 4.4 and the introduction of the REST API we will need to gather a few more examples. Our theme does reside in the Theme Review repo: https://github.com/WPTRT/doingitwrong
If you would like to add more, remember pull requests are more than happily accepted.