1. Renardi

    As a WP developer that often build theme from scratch, I’m very surprised at those stats. PHP warning left out? Are they not developing in WP_DEBUG?

    I believe the cause is WP suggesting (in the doc) to use twentysomething as benchmark. They should use things like _underscore where everything is still in WP vanilla.


  2. Nick

    I am usually very harsh on the core developers, the plugin review and theme review teams, even though they are obviously overwhelmed and do the best they can. That said, things should be done correctly or not at all.

    If I understand correctly these stats are form themes that were not approved, thus I want to congratulate and fullheartedly thank the theme review team for a job well done. I just hope no theme or plugin that has security holes do not fall through the cracks. And again, I’m strictly referring to security issues and not things not working, like customizer options.

    Thanks again, please keep up the good work.


  3. Zeokat

    What means the part “missing prefix” ?

    Honestly don’t know what prefix should i check into a theme or where i can find the guidelines that points me to a proper prefix usage.

    Maybe is realted to prefix all the custom code, anyway don’t know where security is affected by this.


    • Ashley

      I think they’re referring to the fact that all functions created by a theme should have a unique prefix.

      Good: mytheme_get_logo()
      Bad: get_logo()


      • fwolf

        Even better:
        if( !function_exists( 'my_theme_prefix_get_something' ) ) :

        Makes it child-theme ready and enhancement not a total PITA. Having more grief with this nowadays than ever before.

        cu, w0lf.


    • Stephen Cronin

      From the Theme Review Requirements:

      Provide a unique prefix for everything the Theme defines in the public namespace, including options, functions, global variables, constants, post meta, etc.

      It’s not about security, it’s about themes clashing with WordPress core or plugins. If they use the same name for one of those things as something else, there will be problems. By adding a prefix, it greatly reduces the chance of a clash.


  4. Emil Uzelac

    One link that covers the most what author needs: https://developer.wordpress.org/themes/theme-security/


  5. Ryan Hellyer

    One of the experiments Mullenweg proposed is to remove the manual review process and rely more on user feedback

    Deep in the WP Tavern archives are conversations where a large number of people suggested this originally. There was quite a deep divide between those of us who felt this was the only way forward due to us feeling it was not viable to manually review every theme without creating bottlenecks, and those who felt that the way forward was to get more people involved with the review process until it was running smoothly.


  6. Joseph Dickson

    I’m appreciative of the theme review team. (Which is why I’ve never submitted one of my half baked themes.)


  7. Georgio

    It’s interesting what Matt is wanting to find out about the theme directory and the reviewing. I can also agree that if the security issues is a problem with submitted themes, this is really the most important element for any theme; having a secure theme is absolute.

    However, what I would like to see happen is the comment Matt has mentioned in the past on a few occasions about the theme rules and guidelines being (I believe he called it) draconian. The review process, rules and guidelines are too restrictive and prevents theme authors from getting too creative.

    ….this is one of the reasons I walked away last year from submitting themes, the other being the queue wait times. Personally, I would rather have long wait periods if the theme guidelines were not so restricting and eased off to just reviewing of security only.


    • Poena

      So many people are saying this but are not able to say exactly which requirement they would like to remove or change… and I’m sorry but that’s not as helpful.


      • Satish Gandham

        First, I would like to thank WPTRT for their reviews of my themes, because of which I’m a better developer today.

        Some rules felt like you were unnecessarily holding back the theme.
        I came to understand the significance and reasons behind some rules later in my career.

        With the new reviewers it felt like they were trying to impress someone by finding faults in the themes with a magnifying glass.

        1. My theme used to have a slider, it had Steve Jobs picture in one of the slide. Some reviewer complained about it.
        Steve Jobs
        2. Some one had to dig through the TOS (which even our paying customers barely check, even after prominently linking to it) listed on our website to find fault with the submission.

        Whether the above two cases were right or wrong is not the point here. The general attitude of the reviewers (the new joines) is not right towards the theme authors and the themes.

        And titles like “WPTRT Cracking down on so and so” doesn’t make things any better.

        Also most of the rules are mostly written in rock. At least that is how they are treated by new reviewers.

        I recently developed a theme using Hybrid framework, and bundled functionality not in hybrid into a second framework.
        This resulted in two name spaces for the frameworks and one for the actual theme code.

        When I if this will be allowed, the answer is no.


      • Georgio

        A few comes to mind, such as not allowed to modify any core WP functions, even when it’s at the theme level for style purposes; Not allowed to remove the archive title label such as Category: Your Category Name; not allowed to modify the pagination with my own; WPTitle restrictions; not allowed inline styles (situations where it’s required); screenshot restrictions; no default logos, required to use core-bundled scripts rather than including their own….In many cases, we’ve experienced requirements in reviews that are listed that are not even in the actual development guidelines…almost like the reviewer added them on their own. I guess I should correct myself to mention that most of the issues are during the review process where you get some cowboy/girl type reviews happening. Like Satish mentioned, it’s often reviewer attitudes and a feeling of I’m the reviewer and what I say goes. And when they start adding in their own rules and requirements, or they misinterpret a real requirement, it’s a bad experience for the theme author.

        Not all reviewers are like this, by all means, I’ve encountered a few really amazing ones, but there are many over the years that come across like they have something to prove or impress someone.

        The whole review process is a cringing experience and often made me think, what’s the point. I know many authors have walked away and scares new ones who were contemplating theme submissions.

        To become a reviewer, I believe it should be like a job application you go through. You need to also be a people person because you are working in an environment that involves many people.


        • Justin Tadlock

          Ping me (@greenshady) on Slack if you have issues in your review.

          Some of those things don’t look like requirements (archive label, pagination, title, and inline styles).

          The other things such as screenshot (must be a real screenshot of your theme at the correct size for our system) and using core scripts (so that you’re not breaking plugins) are pretty important.

          Without context, it’s hard to talk about anything definitively though. Just get in touch so that we can walk through any issues together.


  8. M

    Concerning the prefix, what about setting one in the header section of themes (and plugins) and automatically compare the functions, options and all to that ?


Comments are closed.

%d bloggers like this: