DocsWP — WordPress Help

Update on the doingitwrong theme

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:

  • Code
  • Core functionality/features
  • Presentation/Functionality
  • Documentation
  • Language
  • Licensing
  • Naming
  • Options/Settings
  • Plugins
  • Screenshot
  • Security/Privacy
  • Selling/Credits/Links
  • Stylesheets/Scripts
  • Templates

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 __(), _e(), or _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 after_setup_theme.

The following serves as a guide of some common sections that can be missed or over-looked.

Code

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_theme_mod, or get_option depending on how your options are setup.

For example:

.divider {
	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 ?>"/>

Core features/functionality

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.

Scripts/Styles

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' );
function 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' );
}

Documentation

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.

Plugins/Functionality/Presentation

Never require any plugin. A theme needs to work out of the box without having to rely on plugins or external resources. This can mean third-party JavaScript or even fonts. This is often a gray line for many because there are times when settings, options, or even some content needs to remain when a theme is switched. This will always on a case by case basis.

Closing remarks

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.