Theme Review Team

Updates from Chip Bennett Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 5:56 pm on April 21, 2016 Permalink |  

    Theme Reviewer Poll: Code Review 

    Reviewers, please take a minute to complete the following poll:

    Please add any comments or questions, after you respond to the poll.

    • Ulrich 6:53 pm on April 21, 2016 Permalink | Log in to Reply

      I normally I review that code and then install the theme to do a visual review. The reason for not running the Theme Check is that it is run when the theme is uploaded. A nice additional would to post the results from the theme check in the ticket so that the reviewer would not need to run the theme check and see the info and warnings straight away.

    • WPDevHQ 8:07 pm on April 21, 2016 Permalink | Log in to Reply

      My review process is to..
      1) Check that the licence details check out – theme and all resources.
      2) Check code thoroughly to make sure there are no dodgy bits and its up to par with requirements
      3) Install and run theme check – just incase I missed something 🙂
      4) Verify presentation does not break design – not a requirement but used to point things that can improve end user experience.

    • ashiquzzaman 6:20 pm on April 22, 2016 Permalink | Log in to Reply

      You’re gonna have “Last. I review the code after I install the Theme/run Theme Check” getting most of the votes that’s what most people ( especially the new reviewers like me would do). Manually checking code at first meaning you’re wasting time finding certain type of errors theme check would find in a second. I do theme check scan and then “Theme Mentor” plugin scan and then start manually checking files.

    • Nilambar Sharma 4:33 am on April 25, 2016 Permalink | Log in to Reply

      I use Theme Check at first. There are several decisions in meeting which takes time to be reflected in TC. In some cases, TC mentions it as INFO/RECOMMENDED but which meeting already decide as REQUIRED. Some examples, `title-tag` support is actually required but TC says it is RECOMMENDED.

  • Chip Bennett 2:30 pm on September 17, 2015 Permalink |
    Tags: workflow   

    Theme Submission, Review, Approval, Update, Report Workflow 

    During this week’s meeting, we discussed modifying our workflows, both to add a “Report Theme” workflow, and to add an auto-approval workflow for updates to approved, live Themes. As adding these elements will essentially require a complete rewrite of the Theme Review process workflows, we decided that now would be a good time to review/discuss both our existing workflow, and the proposed additions. The thinking is that, if we’re going to start from scratch, we might as well make sure that we’re building the best possible workflow, rather than continue to “bolt on” pieces to a system that already resembles something created by Dr. Frankenstein.

    To that end, I have roughed-out a workflow diagram that shows both our current workflows, and the new/proposed additional workflows. To help make the workflow more understandable, the various actions are sub-divided. At the top are user/developer actions that set things in motion. After that are a series of system actions that lead to the tickets. After that are the actions of the Theme Review Team that process the tickets. And finally, there are the system actions that make Themes live in the directory.

    Note that the existing workflow is in black-line, and the new/proposed workflows are in red-line. The “Report Theme” button that we discussed during the meeting would fall under the “Live Theme Reported” box in the upper right corner:

    Current and proposed workflows for Theme submission, review, approval, update, and reporting

    Current and proposed workflows for Theme submission, review, approval, update, and reporting

    So, please review and discuss. Do the proposed workflows make sense? Are there ways that we can improve them? While we welcome feedback on our existing workflows (in particular: does the diagram accurately reflect our current workflows), at this point, we are primarily looking for feedback on the proposed workflows for the new functionality: the Theme reporting functionality, and the auto-approval of updates to live Themes.


    • Konstantin Obenland 2:59 pm on September 17, 2015 Permalink | Log in to Reply

      In case it’s a live theme update, would commenting on the most recent ticket work as well, like we currently do with theme updates that have open tickets? Creating new tickets only to immediately close them again feels odd.

      • Chip Bennett 3:10 pm on September 17, 2015 Permalink | Log in to Reply

        If it’s a live Theme update, there won’t be any open tickets, generally speaking. I’m fine with opening/closing tickets. It creates an audit trail for activity for that Theme. It’s little different from what we do now: ticket is opened, reviewer does a quick diff-review, then closes the ticket as “approved”.

      • Michael Beil 10:36 pm on September 21, 2015 Permalink | Log in to Reply

        That could be a good way to go with theme updates.

    • kevinhaig 3:41 pm on September 17, 2015 Permalink | Log in to Reply

      Great Job Chip! Brings back memories 🙂

      I thought that at some point down the road TRT was planning to allow new theme uploads to go live as well. Perhaps this could be accounted for in the workflow and coding now, with a switch to turn it on in the future?

      • Chip Bennett 5:42 pm on September 17, 2015 Permalink | Log in to Reply

        I like the idea, Kevin. However, for now, we’re merely testing/experimenting with the auto-approval, so I don’t think we want to build it in to the workflow yet for New Themes. Perhaps Otto can chime in here, but I’m guessing that, after he rebuilds the workflow, if we later decide to use auto-approval for New Themes, it should be easy enough to add a flag/switch to allow it at that time.

      • Tammie 7:05 pm on September 17, 2015 Permalink | Log in to Reply

        The new side is something we have talked about, but this is going to be our experiment potentially leading to more. There’s a lot more to think about for new themes, that’s why we’re having to take things bit by bit.

      • kevinhaig 2:39 am on September 18, 2015 Permalink | Log in to Reply

        Yeah I hear you, as long as Otto knows it is a possibility down the road.

    • kevinhaig 5:19 am on September 19, 2015 Permalink | Log in to Reply

      One last thought, will all themes have a report button, or just the ones updated and set live with no review?

      • Chip Bennett 8:49 pm on September 21, 2015 Permalink | Log in to Reply

        That’s a detail for the next step of the definition process; but my understanding is that all Themes in the directory will have a “Report” button.

  • Chip Bennett 12:05 pm on September 10, 2015 Permalink |  

    WordPress, PHP7, and Themes 

    Theme developers: please see this important information from @jorbin on Make/Core regarding upcoming core support for PHP7, and how that does and will impact Themes.

  • Chip Bennett 1:44 pm on June 15, 2015 Permalink |  

    Customizer Code Examples on GitHub 

    As was discussed in previous meetings, we have begun work on the Theme Review Team’s GitHub repository to build a library of code examples. The first area to tackle is example Customizer code, which currently includes examples for adding panels, sections, settings, basic core controls, specialized core text controls (email, URL, etc.), advanced core controls (color control, image control), and an example custom control (radio image).

    We will continue to add to the library, including more examples of custom controls, and more advanced examples, such as postMessage and other JavaScript fun, modifying the style of the Customizer panel, and others as suggested/requested.

    Suggestions, requests, questions, and pull requests welcome!

  • Chip Bennett 12:58 am on June 13, 2015 Permalink |  

    Meeting Minutes 06/11/15 

    Per our meeting yesterday and the comments on the earlier post, the Theme review requirements have been modified. Additions are highlighted in red, and deletions are struck-out:

    A theme must meet all of the following requirements to be included in the WordPress.org theme repository.

    Along with these checks you should also make sure you run the theme through the theme check plugin. It automatically checks for all the required items. You can find a full list of what it checks here.


    • If the theme has the tag ‘accessibility-ready’ then it needs to meet these requirements.


    • No PHP or JS errors.
    • Include at least index.php and style.css.
    • Have a valid DOCTYPE declaration and include language_attributes.
    • Sanitize everything.
    • No removing or modifying non-presentational hooks.
    • No shortcodes are allowed.
    • Support the following WordPress-generated CSS classes:
      • alignleft
      • alignright
      • wp-caption
      • wp-caption-text
      • gallery-caption
      • sticky (can be unstyled)
      • bypostauthor (can be unstyled)
      • screen-reader-text
    • Must meet all uploader/Theme Check required tests
    • Provide a unique prefix for everything the Theme defines in the public namespace, including options, functions, global variables, constants, post meta, etc.

    Core Functionality and Features

    • Use WordPress functionality and features first, if available.
    • Don’t include admin/feature pointers.
    • No custom post types and no custom taxonomies.
    • No pay wall restricting any WordPress feature.
    • No disabling of the admin tool bar.
    • Use get_template_directory() rather than TEMPLATEPATH to return the template path.
    • Use get_stylesheet_directory() rather than STYLESHEETPATH to return the stylesheet path.
    • Avoid hard coding to modify content. Instead, use function parameters, filters and action hooks where appropriate. For example wp_title should be modified using a filter.
    • Able to have child themes made from them. (Child theme ready)
    • Include comments_template().
    • The theme tags and description must match the what the theme actually does in respect to functionality and design.
    • Use template tags and action/filter hooks properly.

    Presentation vs. Functionality

    • Must not not generate user content, or configure non-theme site options or site functionality.


    • Any custom features, options or any limitations (for example menu restrictions), should be explained. Enough documentation should be provided.


    • If implemented, disable favicons by default and have the ability for users to override.


    • All theme text strings are to be translatable.
    • Include a text domain in style.css
    • Use a single unique theme slug – as the theme slug appears in style.css. If it uses a framework then no more than 2 unique slugs.
    • Can use any language for text, but only use the same one for all text.


    • Be 100% GPL and/or 100% GPL-compatible licensed.
    • Declare copyright and license explicitly. Use the license and license uri header slugs to style.css.
    • Declare licenses of any resources included such as fonts or images.
    • All code and design should be your own or legally yours. Cloning of designs is not acceptable.


    • Theme names must not use: WordPress, Theme.
    • Spell “WordPress” correctly in all public facing text: all one word, with both an uppercase W and P.

    Options and Settings

    • Save options in a single array.
    • Use sane defaults and don’t write default setting values to the database.
    • Use edit_theme_options capability for determining user permission to edit options, rather than rely on a role (e.g. “administrator”), or a different capability (e.g. “edit_themes”, “manage_options”).
    • Use the Customizer for implementing theme options.


    • Don’t include any plugins. A theme can recommend plugins but not include those plugins in the theme code.
    • Don’t do things in a theme considered plugin territory.


    • The Screenshot should be of the actual theme as it appears with default options, not a logo or mockup.
    • The screenshot should be no bigger than 1200 x 900px.

    Security and Privacy

    • Don’t phone home without informed user consent. Find out more about security here.
    • Make any collection of user data “opt-in” only and have a theme option that is set to disabled by default. Validate and sanitize untrusted data before entering into the database. All untrusted data should be escaped before output. (See: Data Validation.)
    • No URL shorteners used in the theme.
    • Use esc_attr() for text inputs and esc_textarea() for textareas.

    Selling, credits and links

    • If you are a theme shop you should be selling under GPL to be in the WordPress.org repo.
    • If the theme adds a footer credit link, there should only be one (link to WordPress does not count)

    Stylesheets and Scripts

    • No hard coding of scripts, styles and Favicons unless a browser workaround script. Everything should be enqueued.
    • No analytics or tracking.
    • No minification of scripts or files unless provide original files.
    • Required to use core-bundled scripts rather than including their own version of that script. For example jQuery.
    • Include all scripts and resources it uses rather than hot-linking. The exception to this is Google libraries.
    • If a tag is used in style.css the theme should support that feature or adhere to what that tag stands for. For example custom background or header.


    It’s worth noting we are working to automate a lot of the above requirements.

    Along with the required items, you should also consider the recommended items. The recommended items are there to make sure your theme is the best it can be and good advice to include as best practice.

    If you have any questions regarding what was updated/clarified, please ask in the comments.

    Please note that we will very likely continue to look for ways to clarify and simplify the Requirements, including more extensive usage of code examples, explanations, and clarifications linked from the Requirements elsewhere in the Theme Review Handbook.

    • Hardeep Asrani 1:06 am on June 13, 2015 Permalink | Log in to Reply

      Hi Chip,

      I’ve a couple of questions:

      No custom post types and no custom taxonomies. No shortcodes are allowed.

      So now WordPress.org themes can include CPT and shortcodes, right?

      Must not not generate user content, or configure non-theme site options or site functionality.

      So what does it means for themes like Zerif Lite? They generate user content, and Matt was fine with it, right?

      And also – it would be great if you could explain this point. Thanks for the update. 🙂

      • Venkat Raj 1:25 am on June 13, 2015 Permalink | Log in to Reply

        I second that…
        Isn’t CPT is user content?

      • Justin Tadlock 1:26 am on June 13, 2015 Permalink | Log in to Reply

        CPTs, CTs, and shortcodes are not allowed. Those items now fall under the “Presentation vs. Functionality” section, which was the original section we had until it got removed/modified a few months back. What we’ll be doing is adding specifics to the “Examples and Explanations” page. So, on that page, we’ll list out specifics like CPTs, CTs, and shortcodes.

        Basically, the meeting was for minimizing the guidelines where possible.

        • Hardeep Asrani 1:31 am on June 13, 2015 Permalink | Log in to Reply

          Thanks for the clarification. One more question – how would you describe themes adding widgets to style the front-page? Is it allowed, or will it fall under “user generated content?” Thanks again. 🙂

          • Justin Tadlock 5:58 pm on June 14, 2015 Permalink | Log in to Reply

            The question is too general. If there’s a ticket you can CC me on or specific example you can point me to, I’d be happy to look at it.

    • Dovy Paukstys 5:14 am on June 13, 2015 Permalink | Log in to Reply

      Question, in reference to: https://github.com/Otto42/theme-check/issues/65#issuecomment-111516643

      Long story short, my framework is used by many developers and has the ability to add both add_menu_page and add_theme_page. Now add_menu_page is not approved and flags Theme-Check.

      The issue is, our devs KNOW to not use that particular function at all when submitting.

      Is there any way we can make the Required a warning/notice, and let them know it’s not permitted allowing my framework to pass Theme-Check? Or can we remove that requirement all together and allow devs to do what they would like? 😉

      Honestly, with the customizer it will never be used anyways, but I’d rather not take it out of my code even if it’s not used by WP.org themes.


    • dmccan 10:12 pm on June 13, 2015 Permalink | Log in to Reply

      This is a good improvement.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar