WordPress.org

Ready to get started?Download WordPress

Review WordPress Themes

Updates from Chip Bennett Toggle Comment Threads | Keyboard Shortcuts

  • Chip Bennett 5:14 pm on April 8, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    Selective Ticket Assignment and Ticket Hogging 

    Based on recent comments, I would like to clarify a couple points about ticket assignment.

    Selective Ticket Assignment

    First, when you assign a ticket to yourself, assign the first ticket in the queue. That means assign from tickets in Priority #1 queue, before assigning tickets from Priority queues 2, 3, or 4. Also, and more importantly: assign the first-available ticket in the queue. Do not cherry-pick tickets based on ease of review, reporter (i.e. Developer), etc.

    Selectively assigning tickets is unfair to developers who are required to wait their turn in the review queue, and is a means of gaming the incentive program. Several reviewers have alleged that this practice takes place. We have not monitored it, but we will do so – something that will take even more time, and result in further delays in getting Themes approved and live. Anyone found to be selectively assigning tickets will risk being disqualified for the incentive program.

    Ticket Hogging

    Until now, we have not set limits on the number of open/assigned tickets a reviewer can have at any one time. Several reviewers have complained that often there are no tickets available, while some reviewers have several open/assigned tickets. So, going forward: reviewers may not have more than 5 open/assigned tickets at any one time.

    In order to ensure that reviewers don’t get stuck with developer-abandoned tickets, admins will close tickets older than one week with no activity or developer response. For this reason, it is even more important not to “bump” tickets by posting comments requesting status updates.

    Also, while this will be much more difficult to monitor: reviewers should only assign themselves one ticket at a time. Assign a ticket, conduct a full review, post comments, and only then assign another ticket.

    Also, this clarification isn’t intended to introduce delays in developers getting their Themes reviewed. Any ticket that appears in the Priority #3 queue (tickets older than 2 weeks) are fair game to anyone. (But if the priority queue system is followed properly – see above – there should never be any tickets in the Priority #3 queue.)

    Please discuss in the comments below.

     
    • Rohit Tripathi 5:30 pm on April 8, 2014 Permalink | Log in to Reply

      Although, I don’t disagree with any of the above, there is one thing which I would like to say in regard to Selective Assignment.

      When, I review a ticket from a Developer say XYZ. It took me an hour, to perform a complete review and point out the mistakes. Now, another theme from the same developer is towards the bottom of the queue. I am obviously inclined to pick it up, as I have already reviewed the code. And chances are that 90% of the code is same in 2 different themes from the same developer. This will save my time, and others’ too as they won’t have to put in the same amount of effort which I had to put in on the first theme of XYZ.

      Is this still an unhealthy practice?

      • Chip Bennett 5:34 pm on April 8, 2014 Permalink | Log in to Reply

        Yes, because all those tickets in between represent developers who have also patiently waited their turn to have their Theme reviewed.

        Also, it is healthy for more reviewers to be exposed to more Theme code from more Theme developers, because it helps make us all better at reviewing.

    • tskk 5:41 pm on April 8, 2014 Permalink | Log in to Reply

      If a ticket at top is way over my head, i have to wait till its picked up, tickets below have to wait unnecessarily.

      Tickets are flying off the list, there won’t be much unjust to if we skip the one’s over my head.

      • Chip Bennett 6:12 pm on April 8, 2014 Permalink | Log in to Reply

        If you always skip tickets for more difficult Themes, one, you force other developers to review the Themes that take more effort; and two, you never benefit from learning from those more difficult Themes. If you need help with a ticket, ask. Everyone on the mail-list should be willing to jump in and help another reviewer who needs help with a complex Theme (especially when tickets are getting assigned so quickly that we have none in the queue). We are a team, and the expectation is that we will act like a team, and help one another like a team.

      • Frank Klein 6:17 pm on April 8, 2014 Permalink | Log in to Reply

        I agree with Chip.

        If you go into the queue and look for small updates, you can do a huge number of tickets in a short amount of time. It’s simply not cool for the theme developers and for the other reviewers if you go in and only take the low hanging fruit, and leave the large and difficult to dissect reviews for others.

        At the same time, we should encurage developers to do smaller commits, instead of mashing together different features and bug fixes in one gigantic kitchen sink commit.

    • Emil Uzelac 5:43 pm on April 8, 2014 Permalink | Log in to Reply

      Additionally: (very much related)

      Current program is to help community and in return TRT features your Theme. This is not a race or competition.

      At the same time our program was not designed as a promotional tool from i.e. Theme Name to Theme Name Pro, but it has been used as such and we have no problems there.

    • robin90 5:48 pm on April 8, 2014 Permalink | Log in to Reply

      Thanks Chip for outlining all those. All the points that you have outlined above were already there and has been discussed many times except this one I think 5 open/assigned tickets. But reviewers seemed to neglect that and grab more tickets simultaneously. It’s sad that we have to outline each and every point. If reviewers would have been little more sensible than we wouldn’t have needed all this.

    • ThinkUpThemes 7:29 pm on April 8, 2014 Permalink | Log in to Reply

      Thanks Chip for this! I totally agree that limiting tickets to 5 per reviewer really helps to give everyone a better chance at getting hold of a ticket and getting that valuable learning experience gained from reviewing. Quick question, if a theme is set to “approved”. Does it still count towards the 5 limit until it’s either made live / reopened / etc… by an admin?

    • CyberChimps 8:23 pm on April 8, 2014 Permalink | Log in to Reply

      We are glad we’re addressing this now, but as long as the reopen ticket rule exists, the system can still easily be gamed.

      A blog post on this topic doesn’t negate the fact that this practice lead to several of this months winners winning the contest, when completely legitimate reviews were discredited for erroneous reasons.

      You guys rewarded those who cheated this month and punished legitimate reviews which disqualified two winners.

      A blog post pointing out that people cheated while still honoring those who cheated and punishing legit reviews doesn’t undue the damage caused. This isn’t a fair contest.

      • Chip Bennett 11:06 pm on April 8, 2014 Permalink | Log in to Reply

        We are glad we’re addressing this now, but as long as the reopen ticket rule exists, the system can still easily be gamed.

        How so? Unless you’re suggesting that the Admins are attempting to game the system?

        A blog post on this topic doesn’t negate the fact that this practice lead to several of this months winners winning the contest, when completely legitimate reviews were discredited for erroneous reasons.

        Untrue. And for the third time: if you have issues with tickets that you believe were unopened unfairly, the place to raise that issue is in the specific ticket.

        You guys rewarded those who cheated this month and punished legitimate reviews which disqualified two winners.

        Again untrue. There is no evidence of “cheating”, and no reviews were “punished”.

        A blog post pointing out that people cheated while still honoring those who cheated and punishing legit reviews doesn’t undue the damage caused.

        Still untrue. There is no evidence of “cheating”, and no reviews were “punished”.

        This isn’t a fair contest.

        If you think the contest isn’t fair, you’re welcome not to participate.

        • CyberChimps 12:47 am on April 9, 2014 Permalink | Log in to Reply

          If reviewers are selectively reviewing themes, and more complicated tickets are being left to the remaining reviewers the odds of the tickets being reopen is higher. Therefore the reviewers not selectively reviewing are at a greater risk of taking on tickets that may get reopened negating all of their review work. Which is exactly what just happened, and unfair.

          The tickets we had weren’t reopened unfairly, the rule of disqualifying those reviews is unfair.

          We’ve sent a list of the theme reviewers who were selectively reviewing to you personally to review as we would prefer not to present this data publicly, although it is clear upon reviewing Theme Trac who the offenders are.

          We consider disqualifying legitimate reviews as being punished because it lost us the contest this monthly unfairly, where as reviewers who selectively reviewed were rewarded and won the contest. This what we consider to be unfair.

          CyberChimps has been providing Theme Reviews for 3 years now long before the contest and will continue to contribute no matter how unfair the circumstances. We’ve sponsored many WordCamps, the Community Summit, and continue to do what we can to support the community. Our reputation in this community alone, as well as having the most popular theme on WordPress.org and in the world should be more then enough to back up our credibility on such matters.

          • tskk 6:58 am on April 9, 2014 Permalink | Log in to Reply

            So you are saying people should be punished for not following rules of future while you yourself are breaking the rules of the present? you have 13 open tickets right now and your employee’s are still assigning tickets to them self, while the current limit is 5. You should be disqualified from this month’s competition as you have more tickets than the limit.

            • CyberChimps 1:07 am on April 10, 2014 Permalink

              We took on those tickets before the new rule.

              We’re going to review all of those tickets, we could easily be doing 15-20 reviews a month. We have several new people being trained to do reviews.

              Like CyberChimps, you have been one of the few reviewers not selectively reviewing. Thank you for that.

          • tskk 9:20 am on April 9, 2014 Permalink | Log in to Reply

            I personally don’t think all these rules are unnecessary, program was working for months and certain company will complain no matter what, as long as they don’t get their theme featured.

            Not assigning next ticket without posting the full review is enough.

            All this is too much work for admins and will only result in program getting cancelled.

    • ThinkUpThemes 8:54 am on April 9, 2014 Permalink | Log in to Reply

      Hi All,

      I wanted to share some thought on the cap on open/allocated tickets and hear the thoughts of others. Although the need of a cap, of sorts, is a great idea. I worry that this new cap although will reduce the risk of ticket hogging (which affected reviewers), it will however introduce a new and greater risk of ticket churning (which will affect developers).

      Consider a scenario where a reviewer has 5 allocated tickets, all of which have been reviewed, and on which a developer response is required. Reviewers might:

      1. Rush a review to the approval stage simply to free up a slot to allocate a new review.
      2. Rush to disapprove a theme purely because it may take longer to review or require more support to be provided to the developer.

      In addition, inexperienced developers with a passion to learn may not get the support they need as reviewers simply may not be inclined to keep tickets open.

      Also the risk of selective reviews will increase, however the point at which the risk arises will simply shift to a later stage of the review cycle. Rather than being at the ticket allocation stage (which personally I don’t think happens) the selective review risk will shift to when a ticket is now allocated. Essentially reviewers will ‘cherry pick’ by choosing to decline complicated themes that may take a while to review in the hope that the next theme they choose will be more simple.

      Another worry is that the move of closing tickets after 1 week is a move to keep reviewers happy so that 1 of the valuable 5 allocations isn’t unnecessarily filled by an unresponsive developer. I feel a little uneasy about changes which shift the focus of the review process from benefiting developers to benefiting reviewers. The previous rule of admins following up on a ticket after 1 week, and them closing after 2 (if no response is received) is great for developers as it gives them a chance to take action. Disapproving tickets for lack of response after 1 week, especially if the developer hasn’t been warned, might lead to them bring disheartened with our process and discouraged from resubmitting in future.

      Just an initial thought, could there be a way to impose a cap for example, reviewers cannot allocate more than 5 tickets unless all allocated tickets have been fully reviewed. I know this makes it harder to monitor and more time for admins. So to discourage poor reviewer behaviour, I was thinking that a penalty can be imposed whereby any tickets in addition to this 5 will not count towards the incentive program if an admin feels a “good” attempt has not been made in reviewing their existing tickets. Obviously the definition of “good” here is subjective and would be purely be based on the admins view of what is considered “good”.

      Anyway, thanks so much to anyone who’s taken the time to read this. I’d love to hear your thoughts.

      Afzaal

      • Chip Bennett 1:02 pm on April 9, 2014 Permalink | Log in to Reply

        Note that both of these are counter-productive (and the latter is contrary to our current workflow):

        1. Rush a review to the approval stage simply to free up a slot to allocate a new review.
        2. Rush to disapprove a theme purely because it may take longer to review or require more support to be provided to the developer.

        Neither of these would result in a ticket being made approved and live, and so wouldn’t count toward the incentive. And premature ticket closure is contrary to our workflow.

        Another worry is that the move of closing tickets after 1 week is a move to keep reviewers happy so that 1 of the valuable 5 allocations isn’t unnecessarily filled by an unresponsive developer. I feel a little uneasy about changes which shift the focus of the review process from benefiting developers to benefiting reviewers. The previous rule of admins following up on a ticket after 1 week, and them closing after 2 (if no response is received) is great for developers as it gives them a chance to take action. Disapproving tickets for lack of response after 1 week, especially if the developer hasn’t been warned, might lead to them bring disheartened with our process and discouraged from resubmitting in future.

        This is a valid concern. I would be fine with saying “no more than 5 open/assigned tickets less than a week old“, and then Admin-closing after two weeks of no Developer response. But, I think that a week is more than enough time for a developer to provide some kind of response in-ticket. Let’s see how it goes as-is, and we’ll adjust as necessary.

        Just an initial thought, could there be a way to impose a cap for example, reviewers cannot allocate more than 5 tickets unless all allocated tickets have been fully reviewed. I know this makes it harder to monitor and more time for admins. So to discourage poor reviewer behaviour, I was thinking that a penalty can be imposed whereby any tickets in addition to this 5 will not count towards the incentive program if an admin feels a “good” attempt has not been made in reviewing their existing tickets. Obviously the definition of “good” here is subjective and would be purely be based on the admins view of what is considered “good”.

        My bigger concern – and the concern that could be the downfall of the entire incentive program – is that reviewers are performing every action and basing every decision on how those actions/decisions impact their ability to win the incentive program. If we have reached that point, then the program has, in fact, failed. If reviewers are expending more effort on gaming the incentive program than they are expending effort on contributing to WordPress via Theme reviews, then we’ve failed. If Admins are expending more effort running and managing the review incentive program than we are expending effort on final-approving Themes/pushing Themes live, finding ways to make the review process easier for developers and reviewers, and helping to educate about Theme development best practices, then we’ve failed.

        That we’re getting this much into the weeds with the incentive program is a pretty major indication that it’s becoming more of a detriment than a benefit – which is a shame, because it’s been instrumental in more than doubling the rate of new Themes being made live in the Theme Directory.

    • PageLines 9:40 am on April 10, 2014 Permalink | Log in to Reply

      Hey Chip! Thank you for the comments and additional guidelines, we’ll do our best to stick with them.

      We do have one question, though, related to the cap:

      What if we have 5 reviews, all completed, but waiting for dev answer? This means that we cannot assign any more reviews until those have been finalised, but devs often take a few days to come back and upload the new version.

      We should be able to assign further tickets as long as the review is started and posted immediately after the ticket assignment, and *before* any further tickets are assigned, right?

      Thank you for your time.

      • Chip Bennett 12:14 pm on April 10, 2014 Permalink | Log in to Reply

        What if we have 5 reviews, all completed, but waiting for dev answer? This means that we cannot assign any more reviews until those have been finalised, but devs often take a few days to come back and upload the new version.

        I’ve been informally monitoring the number of assigned tickets per reviewer for a while. It is very rare for more than a handful of reviewers to have more than 5 open/assigned tickets at any one time. It is also very rare for any reviewers to have more than 20 closed/live tickets in any one month. So, any real impact here is going to be on the extreme edges, based on current review activity.

        If the 5-ticket cap starts causing issues with the queue, we’ll revisit it.

        We should be able to assign further tickets as long as the review is started and posted immediately after the ticket assignment, and *before* any further tickets are assigned, right?

        Of course. Just make sure the first review is thorough and complete, leave review comments, and then feel free to move on to the next ticket.

        • tskk 12:25 pm on April 10, 2014 Permalink | Log in to Reply

          “Of course. Just make sure the first review is thorough and complete, leave review comments, and then feel free to move on to the next ticket.”

          He is talking about further tickets beyond the cap of 5.
          Can you consider increasing the limit to 10?

          • Chip Bennett 1:56 pm on April 10, 2014 Permalink | Log in to Reply

            Can you consider increasing the limit to 10?

            Not at this time. We’ll reevaluate as we move forward, but as I said: based on informal monitoring of assigned tickets, it is extremely rare for any one reviewer to have more than 5 tickets open/assigned at any one time.

            Also: the more tickets open/assigned, the more work it is for a given reviewer to perform follow-up actions when developers respond: actions such as responding to questions, providing guidance for resolving required issues, and reviewing submitted updates.

            I’d rather see a reviewer put more time into a single review, and do one review a day, than to race through multiple reviews a day. And the current throughput and reviewer activity level doesn’t really indicate a need for any single reviewer to have more than 5 open/assigned tickets at one time.

    • Catch Themes 10:49 am on April 10, 2014 Permalink | Log in to Reply

      Thanks Chip and the Admin Team for highlighting the points so that we have clear winner :)

    • ThinkUpThemes 1:09 pm on April 11, 2014 Permalink | Log in to Reply

      Hi Chip,

      In relation to the cap I just wanted to seek clarification on one of your points:

      I would be fine with saying “no more than 5 open/assigned tickets less than a week old“

      So am I correct in thinking that if a ticket has been open for more than 5 days then a reviewer can assign a new ticket? So essentially the 5 cap applies only to themes opened less than 7 days ago, thereby eliminating the issue of hogging?

      Thanks as always!

      • Chip Bennett 1:36 pm on April 11, 2014 Permalink | Log in to Reply

        For now, please stick to the 5-ticket cap. Admins will close tickets that have no response for longer than a week.

    • tskk 1:26 pm on April 15, 2014 Permalink | Log in to Reply

      @chipbennett how do we notify selective assignment if spotted?
      Or is that something you will take care of yourself?

    • Ulrich 3:55 pm on April 18, 2014 Permalink | Log in to Reply

      This is my suggestion to the admins.

      Reward the top 10 reviewers by letting them choose a theme that will be featured. This should help reduce the amount of competition. We have ten spaces then why not use them all.

      Every theme should be reviewed by second theme reviewer. We can use the workflow keyword “2nd opinion” to mark the themes are ready to be approved but need to be reviewed by another reviewer.

      The report can be seen here.
      https://themes.trac.wordpress.org/query?keywords=~2nd-opinion&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=time&col=changetime&report=5&order=priority

      This should reduce the work for the admins and cultivate team work. This will reduce the risk of a theme not being reopened due to human error or not knowing something. This should also help standardize the theme reviews.

    • Emil Uzelac 9:53 pm on April 18, 2014 Permalink | Log in to Reply

  • Chip Bennett 8:05 pm on April 7, 2014 Permalink | Log in to leave a Comment
    Tags: , ,   

    How To Ensure Your Ticket Passes Final Approval Audit 

    Over the past couple of months, the number of approved tickets that have been reopened due to issues found during final-approval audit has declined, but many still get reopened. As a team, we want to ensure that tickets get approved (so that new Themes get added to the directory, and into the hands of end users), and we want reviewers to be able to take advantage of the incentive program.

    So I want to step through the things I check when performing a final review audit. We’re looking for some high-level and/or high-impact things that would cause problems for end users:

    Overall File Structure

    • Does the Theme look like it is derived from a common Theme (Underscores, Twenty Ten-Fourteen, etc.)? Are there included functional files that I’ll need to check. Are there asset folders (fonts, scripts, etc.) that I’ll need to check?

    style.css

    • Check ThemeURI and AuthorURI. Are they appropriate?
    • If ThemeURI or AuthorURI reference commercial Themes, are those Themes sold as GPL-compatible?
    • If the Theme appears to be derived, does it include a proper derivative-work copyright/license attribution?

    readme.txt

    • If the Theme has bundled resources/assets, are they listed in the readme with copyright/license attribution, or will I need to check file headers?
    • Is license for all bundled resources GPL or GPL-compatible?

    header.php

    • Are Theme options properly escaped on output?
    • Is favicon, if used, disabled by default?
    • Does the TITLE tag include anything other than the call to wp_title()?
    • Does wp_nav_menu() reference theme_location, and not menu?
    • Are any stylesheet or script links output instead of being properly enqueued

    footer.php

    • Does the Theme only use one credit link? Is that credit link exactly ThemeURI or AuthorURI, with no SEO-seeding of link text, title attribute, etc.?
    • Are any footer scripts output instead of being enqueued properly?

    index.php

    • Does template markup look generally appropriate?

    Front/Home Page Templates

    • Does the Theme have front-page.php? If so, is it used properly? Does it account for both a static page and the blog posts index as site front page?
    • Does the Theme have home.php? If so, is it used properly as the default blog posts index template?
    • Does the Theme have any custom page templates intended to be used as either front-page.php or home.php?

    comments.php

    • Does the Theme properly output wp_list_comments() for the comments list?
    • Does the Theme properly output comment_form() for the comment reply form, rather than hard-coding the form?

    page.php

    • Does the page template properly call comments_template()?

    functions.php

    • Are all functions and other things in the public namespace properly prefixed?
    • Is all functional output properly wrapped in callbacks and hooked into appropriate actions?
    • Is any of the functionality Plugin territory?
    • Does any of the functionality replicate core functionality?
    • Does the Theme use Theme options? Are they handled properly (single DB entry, proper settings page, sanitized on input, etc.)?
    • Do any of the Theme options replicate core options?

    This list comprises 99% of what I look for in an audit, and accounts for the vast majority of issues encountered that require reopening tickets. So, if you verify these things before resolving the ticket as “approved”, the chances that your ticket will get reopened will go down considerably.

    (Note: @emiluzelac may have other things to add to the list, for things he checks during an audit.)

     
    • ruphel 9:16 pm on April 7, 2014 Permalink | Log in to Reply

      Thanks for the checklist Chip

    • Emil Uzelac 11:47 pm on April 7, 2014 Permalink | Log in to Reply

      My process is very similar to @chipbennett and there is nothing more to add.

      I would like to say that rushing through reviews will most definitely resolve getting your ticket reopened. Take your time and you will be golden.

      Your time and efforts are greatly appreciated!

      For some weird reason, my post got published 4 times, sorry about that.

    • ThemeZee 7:28 am on April 8, 2014 Permalink | Log in to Reply

      “Does the Theme have any custom page templates intended to be used as either front-page.php or home.php?”

      Does this mean we are not allowed to use for example template-homepage.php for a custom front page template, but have to use front-page.php instead ?

      • Justin Tadlock 3:10 pm on April 9, 2014 Permalink | Log in to Reply

        home.php and front-page.php have very specific meanings in WP. They should only be used when they’re meant to be used. template-example.php, even if intended to be used on the front page, can also be used if the template can be used with any page.

        Personally, I prefer that devs make a custom page template that’s usable on any page. It offers more flexibility for users.

        • Chip Bennett 3:22 pm on April 9, 2014 Permalink | Log in to Reply

          Intent is important here. If it’s obviously intended as the site front page template, then it should be `front-page.php`. If the developer doesn’t necessarily intend for it to be the site front page, then call it a “featured content” template (or something similar), and name it `template-featured.php` (or whatever).

    • Jose Castaneda 11:25 pm on April 8, 2014 Permalink | Log in to Reply

      One of the things I often look for are hooks and filters. I’ve seen a few themes that register meta boxes and some that add post types. It just depends on how they are being used ( though post types should really be avoided in themes ).

      One thing I’ve learned is using the command line to my advantage and using grep to find all the add_action/add_filter calls a theme uses.

    • PageLines 12:30 pm on April 9, 2014 Permalink | Log in to Reply

      Thanks for the checklist guys!

  • Chip Bennett 2:53 pm on April 3, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Discussion: Theme Activation Standards 

    Currently, we are proposing a change to the Guidelines that would blanket-prohibit Themes from adding admin notices, redirects, or other similar functionality on Theme activation. The intent of the Guideline is to curtail the proliferation of nuisance/obtrusive Theme marketing in the user’s Admin.

    In the vast majority of cases, such activation functionality should not be needed. Themes are required to use add_theme_page() to add a Settings page, which ensures that end users can always find the Theme’s settings page under the Appearance admin menu. The new requirement for sane defaults will ensure that Themes will always work “out of the box”, at least at a baseline (i.e. no-broken-sites) level. The recommendation for Themes to hook settings into the Customizer will help ensure that end users can visually preview Theme settings changes via the core Customizer (Appearance -> Customize). And the Contextual Help API ensures that Theme developers can add as much rich-text setup/configuration detail as necessary.

    That said, there is still room for appropriate, standardized admin interventions on Theme activation. If we can agree on a consensus for standard admin interventions, then the Guidelines could reflect that consensus, and reviewers would have an objective standard to use when reviewing Themes.

    So, let’s discuss. What’s appropriate? What isn’t? How can we define appropriateness objectively?

     
    • Han 3:28 pm on April 3, 2014 Permalink | Log in to Reply

      How about adding admin notice about important changes of the new version? For example when we move the header and footer script, or custom css feature from theme to a plugin.

    • mudthemes 7:04 am on April 4, 2014 Permalink | Log in to Reply

      Even if the theme redirects the user after activation, the redirect must be to a page where only the documentation regarding the theme configuration is written.

      • eminozlem 5:51 pm on April 4, 2014 Permalink | Log in to Reply

        I think the extent may be defined with two rules a.) The redirected page should be theme’s page (most likely options page or documentation help page) b.) The page should be a related page and not advertising purpose page. Just like the same in many rules such as author & theme uri etc.

    • eminozlem 9:16 am on April 4, 2014 Permalink | Log in to Reply

      I don’t understand what’s the big deal with redirection on activation. It’s essential for themes with Option Framework that the options are initially saved for the theme to properly function.
      If you put your mind to it you can use anything out of its intended purposes so I think it’s not fair to punish everyone else because of the aggresive advertisers by prohibiting all kinds of redirecting / notice boxes that could otherwise prove useful.

      Semi OT: You mentioned sth. about the screenshot. I totally agree with that, screenshot guidelines shouldnt be that restrictive. After all, no theme ever really does look like the demo out-of-the-box. Screenshots should be allowed to display what theme might look like with proper modifications and / or content.
      Also I dont see any harm including other material in screenshot (like theme options). I mean some themes provide 4 theme options, others a hundred. It’d be eye-catching and easier for the user to spot the one for them if other aspects are allowed in the screenshot.

      • Chip Bennett 2:23 pm on April 4, 2014 Permalink | Log in to Reply

        Its essential for themes with Option Framework that the options are initially saved for the theme to properly function.

        This statement is untrue. Refer back to the Sane Defaults requirement. Properly implemented Theme options work out of the box, using developer-determined sane defaults, without any user configuration required. Themes that “break” if the user doesn’t configure Theme options have not properly implemented those Theme options.

        If you put your mind to it you can use anything out of its intended purposes so I think its not fair to punish everyone else because of the aggresive advertisers by prohibiting all kinds of redirecting / notice boxes that could otherwise prove useful.

        I do agree, which is why I’ve linked to a separate discussion, so that we can work out some meaningful standards/guidelines.

      • Chip Bennett 3:02 pm on April 4, 2014 Permalink | Log in to Reply

        It’s essential for themes with Option Framework that the options are initially saved for the theme to properly function.

        This statement is untrue. Refer back to the Sane Defaults requirement. Properly implemented Theme options work out of the box, using developer-determined sane defaults, without any user configuration required. Themes that “break” if the user doesn’t configure Theme options have not properly implemented those Theme options.

        If you put your mind to it you can use anything out of its intended purposes so I think it’s not fair to punish everyone else because of the aggresive advertisers by prohibiting all kinds of redirecting / notice boxes that could otherwise prove useful.

        I do agree, which is why I’ve linked to a separate discussion, so that we can work out some meaningful standards/guidelines. Please provide feedback there.

    • tskk 2:35 pm on April 4, 2014 Permalink | Log in to Reply

      I have opposed banning redirection in earlier discussion too, taking the user back to themes page after activation is meaningless, doesn’t serve any purpose, they have to click on theme options link and go select options anyway to get the best out of the theme. Wasting their time and effort is no good.

      Redirecting to theme options should be allowed.

      • Chip Bennett 3:07 pm on April 4, 2014 Permalink | Log in to Reply

        I disagree that user configuration of Theme options should be necessary. That’s partly why we’re adding a requirement for Sane Defaults. Users should know where to find the Theme Settings page should they choose to modify any of the defaults; users should not be forced to deal with settings configuration out-of-the-box.

        Theme-activation redirection UX is something that should be defined and handled by core, IMHO.

      • Frank Klein 3:21 pm on April 4, 2014 Permalink | Log in to Reply

        I disagree with this.

        When a user installs a theme, the experience should be the same, no matter what theme he just installed. Forcing the user to visit another screen without any action from his part makes the experience very confusing, especially if it doesn’t happen that way consistently.

        Imagine that you are a user. You found this great theme, installed it and activated it. The last thing you want to see is an options panel. You want to see how your site looks with this theme applied!

        Is the current theme activation experience as good as it can be? Probably not, but the Core team has been working on this, and they will continue to iterate on it. We should let Core handle this, because it is part of the core experience of WordPress.

        Themes should look good without having to configure options. Nobody likes setting up something, it is boring and often complicated.

        Also if a user can’t figure out quickly how to get a free theme to look like he wants, he’ll either post a support forum message or just download another theme. Either way that is not the outcome you want to achieve.

    • Devin Price 4:02 pm on April 4, 2014 Permalink | Log in to Reply

      I don’t think we should do a blanket-prohibition of admin notices. I am using two in the latest version of Portfolio Press if users are upgrading (so, actually, re-activation). One is a notice about important updates in the version, along with a link to a post about them. A second notifies users that they should update their Reading Settings. I think room should be left in the theme review guidelines for situations like this.

      I agree that upsell and marketing links should not be allowed on activation.

      I agree that notices about an option panel do not need to be displayed on activation. Users are becoming more aware about the “Customize” link. Good theme documentation can also help educate users.

      @eminozlem, Chip is absolutely right about defaults in Options Framework. You should pass a default when you call an option, e.g. of_get_option( ‘my-option’, ‘default’ ), if the theme requires something other than “false” as the reply if the option is not set. Does that make sense? Happy to explain more if needed: http://wptheming.com/contact

      • eminozlem 9:13 pm on April 4, 2014 Permalink | Log in to Reply

        Sure, my theme with OF does work defaults. But there are other specific reasons my implementation of the theme is better with an initial redirect (refresh) on activation.
        I agree with notices.The point is, no matter what the case is, be that notice, redirection, prompt or whatever, I think all should be allowed as long as it’s used in good faith and not in an abusive manner for marketing purposes.

    • @mercime 2:50 am on April 5, 2014 Permalink | Log in to Reply

      +1 blanket-prohibit Themes from adding admin notices, redirects, or other similar functionality on Theme activation.

    • CyberChimps 6:13 am on April 8, 2014 Permalink | Log in to Reply

      We’re strongly opposed to banning all theme activation notices.

      Some kind of default activation notice is required to alert users of a successful activation and what to do next.

      A better solution would be to have a default activation notice similar to what we’ve built into Responsive that directs users to theme options and documentation.

      In a perfect world, we’d all love if a theme just worked out of the box, but the truth is users need a help in knowing what the next step is to configure their website, and some customization will always be required, and the Customizer does not include all use cases yet.

      When .org forced us to removed redirects in our themes we saw significant increases in theme abandonment, and increased support from people who could not locate the theme options. Adding a customize button to the wp-admin bar is an illogical UI progression that most users don’t follow.

      Also, what about notices for companion plugins? Does this proposal intend to ban those as well?

      • Frank Klein 6:55 pm on April 8, 2014 Permalink | Log in to Reply

        TGM Plugin Activation notices or similar are not prohibited by this guideline.

        The Customizer has been introduced a while ago, and users definitely are getting used to it. Having to go to a separate options page to configure the front end of your website is more illogical than a contextually relevant and prominent link to the Customizer.

        I agree that there will always be users that struggle with setting up a theme, and we should help those. But I think that overly complicated themes are more to blame than the banning of admin notices or redirects.

        Instead of every theme shop rolling their own, we should use the feedback and experiences made to develop a Core proposal that will alleviate some of these pain points.

        • CyberChimps 12:21 am on April 17, 2014 Permalink | Log in to Reply

          The Customizer is fine for front end settings, but what about template configurations? Layouts?

          The Customizer is a great tool, but not an end to theme options.

          We would love standardized ways of addressing these pain points, which is why we would prefer if admin notices aren’t banned until a solution is actually in place.

      • Emil Uzelac 4:13 am on April 14, 2014 Permalink | Log in to Reply

        Companion plugins are excluded from the get-go and proposal does not affect them.

        Please note that @chipbennett was asking and not making solo decisions here, otherwise this post would not even exist.

        What is the best way to handle the activation and can we standardize?

        Emil

    • sanerdesign 10:22 am on April 8, 2014 Permalink | Log in to Reply

      I’m all for standardizing the theme activation notices rather than applying a blanket ban. I really feel that the admin notices can benefit the user if we can agree on the information that is displayed.
      This is just a suggestion, from my experience, but I think the following should be allowed in an agreed layout:

      Thank you message
      Link to developers site
      Link to the options if the developer isn’t just using customizer (optional)
      Link to that theme’s support pages

      It’s important to link to the developer in recognition of their hard work.
      A link to the theme options, I feel, is still important whilst they still exist. Theme options allow the developer to not just add options but to add a lot more information than they could on the customizer. Yes I am talking upselling (dirty word I know). Whilst we are probably all against over-the-top upselling and promotion of pro options etc we also have to accept that businesses are making money from this format and it is that money that pays for ongoing development and support of the theme. If we make it too difficult for developers to upsell we could end up with a lot of poorly supported themes that don’t get developed. I do think that this would be bad for the end user.
      The link to support pages is self explanatory but it is really important to let the user know immediately that there is somewhere to get help if they struggle with their chosen theme.

      Whilst I believe that it is the user experience that is always the most important for every action that we take we should consider the developer and their business for it will always be them that keep the WordPress themes fresh, supported and developed.

      Hugo

    • Schwarttzy 4:04 am on April 9, 2014 Permalink | Log in to Reply

      I don’t understand why after a theme gets activated that they get redirected to the page “Appearance.” Are they trying see how many themes they can activate in a minute or what? What’s so wrong with a page explaining the theme? Or possibly things they may want to do now that they activated this theme?

      Why is it so crucial that they get taken back to all the other possible themes they could change too?

      • CyberChimps 1:09 am on April 10, 2014 Permalink | Log in to Reply

        +1.

        Valid points.

        The explanation I was told was because they want to improve the on boarding process for WordPress, and there is some concern that a lack of selection for themes may be a pain point. However, they are simply creating a user experience nightmare with all of these new rules.

    • nikeo 2:13 pm on April 21, 2014 Permalink | Log in to Reply

      Hi,
      This follows a discussion with @chipbennet and @catchtheme during a theme review (https://themes.trac.wordpress.org/ticket/18164).

      We were wondering about the possibility to incorporate links into the top admin bar.
      In my case (Customizr theme), I have added a “Help” button in the admin bar which is visible both on back end and front end for a user connected.
      Users can have an almost direct link to the support forum on WP.org, the FAQ or the theme ‘s documentation if they feel lost. I think this makes the theme more user’s friendly and this is not redundant with the built-in WP links already displayed in this bar like : add a new post,/page…, link to dashboard, search, …

      Many popular plugins are elevating those kind of links in the admin bar and I think that’s often really interesting from a user experience perspective too.

      I would love to have your point of view/feedback about this and hope that we could come up with consistent guidelines for the WP themes.

  • Chip Bennett 2:35 pm on April 3, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.9 Guidelines Revision Proposal: Round 2 

    Based on the previous discussion, the Guidelines proposal has been revised as follows. The proposed guideline change for Credit Links has been removed, and a proposed guideline change for Custom Logos has been added. Other proposals have been clarified based on previous discussion.

    The two most significant clarifications regard arbitrary header/footer scripts, and Theme activation.

    The proposed Recommended guidelines have not changed. While we understand the argument that there may not be consensus around certain implementations of features, we maintain that it is within the overall scope and objective of the Theme Review Team to encourage, facilitate, and drive best-practice consensus, and that it is in the best interest of end users to establish best-practice consensus. Thus, arguing that the Theme Review Team should not be establishing/promoting such best-practice standards in order to encourage consensus is moot – though we absolutely encourage discussion regarding what implementations should be considered/promoted as best-practice standards.

    Other Discussion Topics

    Screenshot

    I would be interested in discussing our screenshot requirements. It seems that “reasonable facsimile”, as a standard, isn’t really sufficiently meeting anyone’s needs. While the intent was to avoid blatant marketing via screenshot, the requirement tends to be taken so literally that developers cannot even display user-configurable features in their screenshot. This is especially limiting for Themes with featured-content front-page templates. As currently interpreted, the “reasonable facsimile” standard prevents the screenshot from displaying the featured-content front-page, because the featured content first has to be configured. So, let’s discuss a more sane/useful guideline for screenshots.

    Translation-Ready

    I would also be interested in discussing the establishment of at least some “best practice” guidelines for translation-readiness – primarily, proper i18n of strings. I think it is all but a given that, eventually, we should be requiring Themes to be translation-ready; but currently we don’t have objective standards to follow. The first step, then, is creating those standards, and then educating developers on them.

    Required

    Sane Defaults: Themes are required to use sane defaults.

    Themes must not save default settings to the database without explicit user action, and Themes must function properly out-of-the-box without user configuration (that is: if the user does not save settings, the Theme will still function properly)

    Bundled Plugins: Themes must not bundle Plugins.

    Themes may incorporate support for Plugins, and may integrate Plugin code directly into the Theme (if that Plugin code meets the presentation-vs-functionality requirement), but Themes must not bundle Plugins as a whole.

    Arbitrary Header/Footer Scripts: Themes must not provide Theme options for arbitrary header/footer scripts.

    Arbitrary scripts are non-Theme-specific scripts added to the document head or footer to provide non-Theme-specific functionality. Such scripts are Plugin territory, and pose a significant security risk if not handled properly.

    Custom CSS is acceptable, if properly sanitized.

    Note: this guideline does not apply to content “scripts” added to the template outside of the document head/footer, such as script widgets (Google Maps, Twitter Feed, etc.). Essentially, if a script can be hooked into the template via wp_head() or wp_footer(), then it falls under this guideline; otherwise, it does not.

    Theme Activation: Themes must not implement activation redirects, admin notices, or similar functionality on activation.

    Note: this guideline does not apply to admin notices such as TGM recommended Plugins (if implemented properly). I will open a separate discussion regarding consensus/standard “unboxing” admin notices. The purpose of this Guideline is to curtail the proliferation of unnecessary/obtrusive marketing in the user admin area, not to prevent legitimate, useful activation information for the end user.

    Theme Documentation: Themes must place any required documentation in a clearly marked readme file.

    Note: this guideline applies only to required documentation. Required documentation includes copyright/license attributions, Theme design constraints/limitations, description of non-standard Theme functionality, etc. Plugin-standard readme.txt is preferred, but not required.

    License: Themes are required to document in the Theme readme or license file the copyright/license attribution for all bundled resources.

    Themes are required to provide this documentation in the Theme readme file, regardless of where or how those bundled resources provide their own attribution. The purpose is to ensure that end users (and also, reviewers) don’t have to search for this important information, and to ensure that the developer has done due diligence to ensure that licenses for all bundled resources are GPL-compatible.

    Note: “blanket” statements for developer-owned resources (images, etc.) bundled with the Theme are perfectly acceptable. It is only third-party bundled resources that need to be listed explicitly.

    Custom Logos: If implemented, custom logos must be user-configurable, and disabled by default.

    This guideline will bring the handling of Theme options for custom logos in-line with the handling of Favicons. Currently, we require that “default” logos be generic/unbranded, but generic/unbranded logos are of no benefit to the end user. Likewise, Theme-branded logos are of no benefit to the end user. The most logical approach, then, is to require that custom logos not be displayed at all, unless the end user has configured one.

    Recommended

    Theme Documentation

    Themes are recommended to include a Plugin-standard readme.txt file.

    Themes are recommended to meet the WP core standard for inline documentation.

    Translation

    Themes are recommended to be translation-ready.

    Social Profile Links

    Themes are recommended to use a custom navigation menu when incorporating social network profile links

    Theme Options

    Themes are recommended to integrate Theme options into the core Theme Customizer

    Discuss

    Please discuss in the comments below.  If you have any additions to propose, please post them in the comments below, as well.

     
    • Rohit Tripathi 2:41 pm on April 3, 2014 Permalink | Log in to Reply

      +1 For Everything. Especially, the guideline change related to Screenshots. I hope it goes through.

      • Edward Caissie 4:19 pm on April 3, 2014 Permalink | Log in to Reply

        Aside from maintaining the premise of not allowing any sort of spammy / marketing type images I would be fine with opening the screenshots to something relatively easy to configure at installation provided how to create the screenshot’s “look” is documented in at least the `readme.txt` file … or similar documentation available to the end-user within the theme’s package.

    • tskk 2:57 pm on April 3, 2014 Permalink | Log in to Reply

      How much time do we have before recommendation of using theme customizer turns into requirement?

      • Chip Bennett 2:59 pm on April 3, 2014 Permalink | Log in to Reply

        Who knows? It’s something that may never happen. Right now, we just want to promote it as a best practice.

        Is there any particular reason not to want to integrate Theme options into the Customizer? I’m genuinely curious what those reasons might be.

        EDITED TO ADD: We made the Settings API *recommended* years ago, and have never made any move toward making it *required*.

        • tskk 3:03 pm on April 3, 2014 Permalink | Log in to Reply

          the left pane is very cramped,
          no framework like OF which has all the controls we need,
          no drag and drop setting/option

          • Chip Bennett 3:06 pm on April 3, 2014 Permalink | Log in to Reply

            True, the left pane can be a bit cramped – but I think they payoff (real-time preview of the setting change) more than compensates. Also, if you segregate your Theme options into logical sections, it makes the UI much more manageable.

            Almost every control imaginable is built-in to the API. Which one(s) are you missing, specifically?

            Can you explain the drag-and-drop? I’m not sure what you mean.

            • tskk 3:21 pm on April 3, 2014 Permalink

              The ability to use images in place of radio buttons like in optionsframework, ability to have a vertical accordion like i have in optionsframework. Is it possible to add stand alone text and maybe apply css to that text?

              If you see one of the cyberchimp themes, they have a drag and drop option where user can drag page elements around like reordering the site elements.

          • Zulfikar Nore 4:03 pm on April 3, 2014 Permalink | Log in to Reply

            I think with a little thought the drag and drop for page builders can also be integrated in the customizer.

            My thoughts here are based on the new incoming Widget control section which has some drag and drop options for the widgets.

        • tskk 2:08 am on April 4, 2014 Permalink | Log in to Reply

          Also customizer doesn’t have a reset button, import/export option.

    • daveshine (David Decker) 3:39 pm on April 3, 2014 Permalink | Log in to Reply

      *Tranlation-ready* should totally be REQUIRED!

      Why?
      Translations are essential, and I never understand why an international used platform like WordPress.org/themes should promote untranslateable themes in the year 2014+ ?!?

      *Translation-ready* also means a theme can be customized with another tone/ type/ of the same language, for example, still in English (but use British English, formal tone for business etc.).

      Also, to have it as a requirement will improve overall theme code and quality – and especially make them more user-friendly! And not to forget, it will all help prepare for upcoming launch of language packs (that are prepared in core, but “not yet launched” here on .org for themes, plugins).

      Standards:
      There are already standards all there, for years already:

      • load_theme_textdomain()
      • load_child_theme_textdomain()
      • all the translation functions for strings like __(), _e() plus all the related stuff there…
      • using sprintf() and printf() to keep as much markup as possible out of translation strings
      • using _x() context translation functions to add context to strings and/ or be better help for translators

      I don’t know any reason why *Translation-ready* should not be required for any theme here (and plugins also!)? So, if someone has such a reason for me, I am eager to know what speaks against all that.

      As a international developer and user I am fighting the good fight for years already, to get more and more themes, child themes and plugins translateable at all, and moreover to have them in the “standards” (see points above). WordPress.org theme repository should be the leading example in this field!

      PLEASE make it a requirement! Thanks so much!

      Dave from Germany :)

      • Chip Bennett 3:55 pm on April 3, 2014 Permalink | Log in to Reply

        I agree that making it *required* is our end goal. But we have to start somewhere. We have to have an established, objective string-translation standard. Then we have to educate developers how to implement it – and we have to educate reviewers how to evaluate Themes against it. We’re simply not ready for that.

        I want to get there. We need to get there. I agree that WPORG-hosted Themes should all be translatable. But we’re simply not at the point that we can make it required, and be able to enforce it fairly and consistently.

      • Ulrich 4:55 pm on April 3, 2014 Permalink | Log in to Reply

        I think it would be great if every theme and plugin were internationalized. From my experience reviewing themes a number of theme developers do not have a deep understanding of PHP so they find it difficult to internationalize the theme. By placing it as a requirement we are increasing the level of entry. Do we really want to do that?

        Somehow I think it is a theme developers decision to choose to support i18n or not. Users can show the demand by asking for i18n support.

        We did once discuss what is needed for a theme to be allowed to use the translation-ready tag. At the time we decided that all strings had to be internationalized and the header should contain the text domain but does not need to include a POT. How far do theme reviewers enforce best practices for creating strings?

      • Justin Tadlock 5:01 pm on April 3, 2014 Permalink | Log in to Reply

        I’m one of the biggest supporters of theme authors internationalizing their themes that you can find. I’ve done this myself for many years. However, I cannot get behind this being a requirement, at least at this point in time. The reason for this is that it is a huge barrier to entry. I probably would’ve never made my first theme if I had to do this.

        We need to start with education. I’d also like to see all articles in the Codex and Handbooks that provide code examples with text strings to actually show those strings with the proper functions.

      • Sami Keijonen 5:30 pm on April 3, 2014 Permalink | Log in to Reply

        I’m with David here. Make it required. This has been in theme/plugin development best practice for so long that it should be required. I don’t mind if it makes a little bit harder to get your theme on WP.org. It should be about quality, not quantity.

        Do you have data how many new themes are not Tranlation-ready?

      • wpweaver 8:02 pm on April 8, 2014 Permalink | Log in to Reply

        I am 100% for making theme translatable on the front side (visitor view).
        But, as usual, my theme (Weaver II) is on the extreme edge of things.

        It has a very complex admin interface, full of long, complex, and technical descriptions. It uses complex HTML and scripts to make the admin user interface work with its hundred of options.

        Making this in a translatable form (it has LOTS of direct HTML output) is next to impossible. And this doesn’t even mention how difficult it would be to get technically correct translations.

        But for the visitor side, my theme has already been translated to something like 25 languages, and that number is growing.

        So – visitor side translation capable – REQUIRE asap.
        admin side translation capable – leave recommended.

    • Frumph 3:45 pm on April 3, 2014 Permalink | Log in to Reply

      … no, no and no.

      If you want to write up guides and point to them to the designers, go for it.

      • daveshine (David Decker) 3:54 pm on April 3, 2014 Permalink | Log in to Reply

        Yes, sometimes to much guides/ guidelines make things more complicated and could take away some passion…!

        However, it’s not only about design here: it’s also about usability, security of code, making stuff translateable, avoiding aggressive marketing in themes etc. Over the years, the experience was some guidelines should be in place.

    • Morgan Feeney 3:47 pm on April 3, 2014 Permalink | Log in to Reply

      Theme options in the customizer! The purpose of which is for live preview of your website, including styles, now widgets too, so why exclude any other content which can be edited on the back end from this?

      It makes total sense to me, I am a designer and front-end guy and I think it would be of benefit.

      if WordPress is to carry on competing on a global scale with new and existing CMS, anything which enables a real-time preview into how the site looks with on-the-fly changes being made only makes it a stronger contender in the long-run.

    • Zulfikar Nore 4:13 pm on April 3, 2014 Permalink | Log in to Reply

      +1 on all proposed changes!

      The Screenshot issue has been too stringent – allowing for configurable options to be included in the screenshot is a sane proposal.

    • Justin Tadlock 5:07 pm on April 3, 2014 Permalink | Log in to Reply

      I still disagree with the requirement for license info to be placed into readme.txt. WordPress itself uses a license.txt file for this. I’d be more supportive of this if we allowed for license info to be placed in either license.txt or readme.txt.

    • Ron 5:23 pm on April 3, 2014 Permalink | Log in to Reply

      Most of the guidelines seems to be in order but I have to disagree with the Custom Logo being disabled by default. Unlike the favicon, a logo affects the overall design of a theme.

      Currently, we require that “default” logos be generic/unbranded, but generic/unbranded logos are of no benefit to the end user. Likewise, Theme-branded logos are of no benefit to the end user.

      True, but what about one that is not visible? There might not be any benefit to the end user whether a custom logo is enabled or disabled by default but then why make it a requirement?

      If the generic logo requirement isn’t good enough then maybe we could even have a standard logo image for every theme with a logo option to use. Maybe a WordPress logo?

      • Chip Bennett 5:55 pm on April 3, 2014 Permalink | Log in to Reply

        You might be misunderstanding what “disabled by default” means. It just means that, if the user configures a logo, then that logo is output; otherwise, if the user does not configure a logo, then no “default” logo is output.

        I’d be curious to see an actual case where a “disabled by default” custom logo would adversely impact a Theme’s design.

        • Ron 6:10 pm on April 3, 2014 Permalink | Log in to Reply

          Yup, that’s exactly how I understood the guideline. It might not be a very big difference but a visible logo helps a user envision the overall look of the theme after he/she either removes or changes it.

          My point is, are there actual benefits at all from a custom logo being either enabled or disabled by default that would command it to be a requirement? If there aren’t any then this would just unnecessarily add to the growing set of guidelines.

          • Chip Bennett 6:20 pm on April 3, 2014 Permalink | Log in to Reply

            Yes, there are actual advantages. A company is very likely to have a pre-defined logo that they would then configure for use with the Theme. But an individual (or even a non-commercial entity or group) likely won’t have a logo. For them, it is detrimental to have an arbitrary image (or worse: an image that says “Logo”) prominently displayed on their site. (Note: it would be equally bad to have an image displaying the Theme name prominently displayed on their site.)

            This is not an onerous guideline. It simply means wrapping the logo output in if ( '' != $themename_options['logo'] ) {}.

            • Ron 6:50 pm on April 3, 2014 Permalink

              A company is very likely to have a pre-defined logo.
              An individual (or even a non-commercial entity or group) likely won’t have a logo.

              Is this really the case? I think a user, whether intending a theme for company or individual use would decide on what theme to use basing on it’s looks (screenshot & preview). The visibility of a logo and seeing its positioning helps make that decision. I think it’s pretty reasonable to expect a user who chooses a theme that has a logo option, to use one. I think the fact that logos are required to be user-configurable is good enough.

              I’m not really that much against it but I just can’t see the guideline as an actual benefit to warrant being a requirement.

            • Chip Bennett 9:26 pm on April 3, 2014 Permalink

              I doubt that users primarily base their decision on whether or not a Theme supports a custom logo, nor should individuals be barred from using a Theme simply because it outputs a logo, and they don’t have or need one.

              The decisions to add this guideline is born out of the numerous instances of logos being problematic during the review/approval process. This guideline actually simplifies things for Theme developers, who no longer have to come up with a “generic/unbranded” logo to output by default (most of the time, Themes have had a Theme-branded default logo, and had to go to the extra effort to create an unbranded logo).

        • Catch Themes 3:26 pm on April 5, 2014 Permalink | Log in to Reply

          I think the only problem with this will be in Theme Preview. If we have option to make that logo available in preview then there will be no effect on design. For example in Catch Kathmandu theme, I added in generic logo just to show in Theme Review at http://wp-themes.com/catch-kathmandu/

    • Emil Uzelac 6:20 pm on April 3, 2014 Permalink | Log in to Reply

      +1 for all @chipbennett!

      • alex27 10:34 am on April 4, 2014 Permalink | Log in to Reply

        I totally agree with Chip on the logo. What good does the fancy custom logo does to the user anyway, when theme authors do not provide source files to customize it (not that I think we should require it).

    • Codice e Bella 2:47 am on April 4, 2014 Permalink | Log in to Reply

      I only developed my first theme for the repository about a month ago. While I created a very basic and simple theme to learn the process so that I could start developing themes that weren’t so “basic”, I didn’t think learning to develop it as translation-ready was that difficult. Someone else said it should be about quality, not quantity. Even as a new developer to the theme repository, I would agree with that, and say making it a required practice shouldn’t stop someone from developing new themes for the repository.

    • mudthemes 6:57 am on April 4, 2014 Permalink | Log in to Reply

      Screenshot Proposal is brilliant.

      To make it more transparent, why not ask theme developers to include the exact method used to achieve the screenshot in readme.txt or link the plugins/widgets used to create it.

    • Frank Klein 11:47 am on April 4, 2014 Permalink | Log in to Reply

      Screenshot

      I think that the screenshot should reflect the intended use case of the theme, so a blogging theme (like TwentyThirteen) should show the blog index. A theme with a front page template (like TwentyTwelve) could show this specific template.

      I’d argue though that themes should always show the front page (whether a blog index or static page). It is okay to have a screenshot that shows user-configurable options already set up. However the screenshot should not contain elements that are dependent on the installation of plugins.

      Translation-Ready

      I would be in favor of making this a requirement. I agree with Justin Tadlock that this represents a further barrier to entry for theme developers. But I would say that we need to think about the users first and only then about the developers.

      With an increasing number of WordPress users that don’t have English as their native language, themes that are not translated are effectively useless. So in this case, we should side with the users and make this a requirement.

      I would also add that Internationalization is no longer a mystery or novelty. With the amounts of tutorials and WordCamp talks on this subject, learning this is not an issue.

      Custom Logos

      I agree fully with this. Custom logos are an option. As such they should optional.

      Licensing information

      Having a file (whatever name it has) that contains all the licensing information for the theme is a big help for reviewers. It also makes the life for users easier that want to use themes for their own projects, as they don’t have to worry about finding out what licenses apply to the different elements of a theme.

    • Devin Price 4:09 pm on April 4, 2014 Permalink | Log in to Reply

      +1 for all these changes.

      I think we should put a note about how to properly enqueue Google fonts as this has come up a lot in my recent reviews. It could also perhaps be somewhat automated: https://github.com/Pross/theme-check/issues/6

      I would also love to get more theme support for translations. Perhaps there is a better way to match theme developers who are knowledgeable in this area with developers who wish to learn it?

    • Catch Themes 3:32 pm on April 5, 2014 Permalink | Log in to Reply

      +1 for the changes. Ready to work on Theme Review. Will need to adjust some on my themes as well. Thanks :)

    • Scott Smith 2:18 am on April 7, 2014 Permalink | Log in to Reply

      How should I be escaping Custom CSS? I crawled the internet for a while and wasn’t able to find a helpful bit of advice on this.

    • Catch Themes 12:49 pm on April 17, 2014 Permalink | Log in to Reply

      Has this guideline been finalize. Can we use this proposed guidelines while review new themes. WordPress 3.9 is out now. But I don’t see final guidelines.

  • Chip Bennett 12:23 pm on April 2, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Theme Review Incentive: March 2014 Winners 

    We are pleased to announce the following winners for March 2014.

    New Themes

    Theme Updates

    Please post a comment below, indicating your Featured Theme selection.

    Monthly Stats

    • New Themes:
      • Approved/Live: 97
      • Reviewers: 15
      • Eligibility: 10
      • Reopened: 19
      • Missed Eligibility due to reopened tickets: 2
    • Theme Updates
      • Approved/Live: 468
      • Reviewers: 19
      • Eligibility: 117

     

    Featured Theme Rotation

    Per the program changes, all Themes but the following will be removed from the list:

    • Twenty Fourteen
    • Twenty Thirteen

    Note: review totals are taken as a snapshot at an arbitrary point in time, based on this Theme-Trac report, and varying the filters as appropriate.  Totals are as accurate as reasonably possible.

     
    • acosmin 12:26 pm on April 2, 2014 Permalink | Log in to Reply

      Congrats to the winners! :)

    • tskk 12:34 pm on April 2, 2014 Permalink | Log in to Reply

      Thanks Chip and congratulations to other winners.
      I will continue with Alexandria.

    • ThinkUpThemes 12:39 pm on April 2, 2014 Permalink | Log in to Reply

      Congratulations guys!

    • alex27 1:09 pm on April 2, 2014 Permalink | Log in to Reply

      I’ll go with Sugar & Spice for this month. Thank you!
      http://wordpress.org/themes/sugar-and-spice

    • Rohit Tripathi 1:31 pm on April 2, 2014 Permalink | Log in to Reply

      Hi Chip, I will go with Fifteen -> http://wordpress.org/themes/fifteen/

      Congratulations to All and Thank you!

    • PageLines 1:45 pm on April 2, 2014 Permalink | Log in to Reply

      Congrats to everyone! We’ll go with DMS -> http://wordpress.org/themes/dms/

    • Themonic 1:54 pm on April 2, 2014 Permalink | Log in to Reply

      Congrats guys!

      @Chip So even the reopened tickets like these won’t count?
      https://themes.trac.wordpress.org/ticket/17544
      https://themes.trac.wordpress.org/ticket/17281

      • Chip Bennett 4:30 pm on April 2, 2014 Permalink | Log in to Reply

        Correct. If Emil or I have to reopen the ticket due to required issues that are missed prior to approval, then the ticket won’t count toward the incentive.

        • Themonic 10:29 am on April 8, 2014 Permalink | Log in to Reply

          The thing I wanted to show you was, that those were super minor issues and could have easily approved while asking the theme author to submit a new version asap. Even after 12 reviews this month, I didn’t make it to the list :( . I am relatively a new reviewer ~100 reviews, I am kinda feeling like if you have to then you can re-open any ticket this way and then just due to couple of tickets whole contribution effort seems to be wasted. If I am feeling this than what about the would be reviewers, wanting to get into theme reviews? I hope you get my point.

          May I also propose a small change :

          Approved/Live: 97
          Reviewers: 15
          Eligibility: 10
          Reopened: 19
          Missed Eligibility due to reopened tickets: 2

          Eligibility now 97/10 = 9.7

          Eligibility should be 97 – 19 = 78

          New Eligibility = 78/10 = 7.8

          This is more fair right?

          The current program is kind of perfect. Kindly look into it based on the above, it would be great if something can be done for reopened tickets with minor issues.

          • Chip Bennett 12:00 pm on April 8, 2014 Permalink | Log in to Reply

            97-19 is not correct. The 97 is the number of Themes approved and made live. Of the 97, 19 had to be reopened but were subsequently re-approved, and then made live.

            I am kinda feeling like if you have to then you can re-open any ticket this way…

            We’re not trying to reopen tickets for minor issues. We have no desire to “punish” reviewers for minor mistakes, nor do we have any desire to create more work for everyone involved. That’s why I published this list: so you know exactly the things I’m looking for.

            …and then just due to couple of tickets whole contribution effort seems to be wasted. If I am feeling this than what about the would be reviewers, wanting to get into theme reviews?

            Honestly, if the only reason that people are reviewing Themes is to win the incentive, then the entire system is failing, and w’ll have to reconsider it. The Theme Review Team is a community contributor group, which exists in order for WordPress community members to have an opportunity to contribute back to the WordPress project. Anyone involved merely for the incentive is involved for the wrong reasons.

    • Catch Themes 2:47 pm on April 2, 2014 Permalink | Log in to Reply

      Thanks Chip and Congratulations to all the winners.
      I will go with Catch Kathmandu http://wordpress.org/themes/catch-kathmandu/

    • Zulfikar Nore 7:55 pm on April 2, 2014 Permalink | Log in to Reply

      Congratulations to all winners – especially Catch Themes, good to see you in the mix :)

      I’ll go with Itek for this month: http://wordpress.org/themes/itek – thank you

    • robin90 7:10 am on April 3, 2014 Permalink | Log in to Reply

      Thanks Chip and Emil for their support and Congratulations to all the winners. I will go with Spacious http://wordpress.org/themes/spacious

    • talentedaamer 3:01 pm on April 3, 2014 Permalink | Log in to Reply

      congratulations to all winners, specially new for this month (pagelines, catchthemes) keep it up.

    • CyberChimps 10:30 pm on April 7, 2014 Permalink | Log in to Reply

      I would like an explanation as for why we didn’t win when we had more reviews then some of the winners.

      My staff has informed me that two of our reviews were discredited?

      I seems odd that an entire review should be discredited if a ticket only has to be re-opened once. Even if a review has to be reopened before final approval, the reviewer still did the majority of the review did they not?

      • Emil Uzelac 11:54 pm on April 7, 2014 Permalink | Log in to Reply

        As previously noted: if the ticket gets reopened that will resolve getting your ticket discredited.

      • Chip Bennett 12:25 am on April 8, 2014 Permalink | Log in to Reply

        The rules are stated, quite clearly:

        So, starting this month, any ticket that has to be reopened after being closed as “approved” will not count toward the incentive program.

        So yes: if a ticket gets reopened, even once, after approval, it doesn’t count toward the incentive. The reasoning is explained in the linked post. We’re not looking for nit-picky things when we do a final approval audit (see my checklist above). We’re not looking for excuses to reopen tickets, to create more work for everyone involved. If you disagree with the assessment to reopen any particular tickets that your staff have completed, you’re welcome to comment, in-ticket, to discuss it.

        • CyberChimps 3:23 am on April 8, 2014 Permalink | Log in to Reply

          We were under the impression that this contest was designed so that the admins of WordPress.org weren’t the ones deciding which themes get featured?

          Yet now you’re telling us a new rule has been put in place that just so happen to discredited two of our reviews pushing us out of contention to win the contest? Hmm.

          A rule that basically allows any admin the ability to discredit any reviews they want by simply re-opening a ticket essentially granting the admins the power to determine who wins the contest. I thought this was the very thing we were trying to get away from?

          I can easily understand why such a rule might be necessary for tickets that require being open more then once, but a ticket that has only been reopened once should not be disqualified.

          We are volunteering to contribute reviews, and now you’re telling us we’re not even allowed a single mistake?

          Theoretically you can find a reason to reopen any ticket at any time.

          This rule is completely unfair.

    • CyberChimps 5:04 am on April 8, 2014 Permalink | Log in to Reply

      CyberChimps did 10 reviews, and legitimately won this months review contest for the following reasons:

      1) Selective reviewing.

      We keep getting stuck with the themes that the other theme reviewers know have a chance of being re-opened. Everyone has figured out that if they target themes from reputable theme shops including Automatic the odds of the ticket being re-opened are lower, and they have to do less work per review.

      Go take a look at your winners this month and decide for yourself.

      It is an unfair practice that you guys are rewarding.

      2) The reopen ticket rule is not fair.

      I understand why this rule was put in place, but almost any ticket could be reopened at any point for any reason. It isn’t a fair metric to judge disqualifying a review on. We’re putting in hard work that isn’t being credited because we’re getting stuck with the themes other reviewers don’t want to review, and then we’re being disqualified for reviewing them. How does that make sense?

      Authors should have at least 1 reopen per review, we are volunteering, an occasional mistake shouldn’t be punished, especially on difficult tickets that require more oversight.

      3) Not enough tickets. It’s nearly impossible to get more then 10-15 themes to review per month because everyone is still trying to assign themselves tickets and still selectively picking tickets. We easily could have done another 10-15 reviews this month but couldn’t even if we wanted to.

    • tskk 5:45 am on April 8, 2014 Permalink | Log in to Reply

      1) Selective reviewing, not everyone has the same technical know how, they pick tickets they can review.
      2) If the ticket is difficult, Chip has mentioned to ask him for help before approving the theme, he said he will be happy to help as much as required before approving the theme.

      • CyberChimps 6:27 am on April 8, 2014 Permalink | Log in to Reply

        1) We agree, which is why it is not fair to discredit reviews that require being re-open a single time. If a theme requires that much additional oversight there is typically a reason. Or at least a determination should be made, not just an automatic disqualification. If the reviewer put in considerable time to review a theme and then gets it disqualified that isn’t right.

        Either way, there is still a reviewers cherry picking tickets who are being rewarded for their practices, and those who take on the less desirable tickets are being punished.

        2) We received no help for the tickets that disqualified us out of the contest. The tickets were reopen and we lost. That’s what happened, and will continue to happen to legitimate reviews as long as this rule stands.

    • Vivacity InfoTech Pvt. Ltd. 7:39 am on April 8, 2014 Permalink | Log in to Reply

      Congratulations to all winners!

  • Chip Bennett 8:30 pm on March 3, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Theme Review Incentive: February 2014 Winners 

    As you may recall, last month we announced changes to the Theme review incentive program, both opening up the incentive to more winners, and adding in a measure of accountability.  Per those changes, we are pleased to announce the following winners for February 2014.

    New Themes

    Theme Updates

    Please post a comment below, indicating your Featured Theme selection.

    For the month, there were a total of 88 new Themes added to the directory by 21 reviewers, and 369 Theme updates added by 16 reviewers. The eligibility requirements for this month were 8 New Themes approved, and 92 Theme updates approved.

     

    Featured Theme Rotation

    Per the program changes, all Themes but the following will be removed from the list:

    • Twenty Fourteen
    • Twenty Thirteen

    Note: review totals are taken as a snapshot at an arbitrary point in time, based on this Theme-Trac report, and varying the filters as appropriate.  Totals are as accurate as reasonably possible.

     
  • Chip Bennett 2:28 pm on February 7, 2014 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.9 Guidelines Revisions Proposal 

    It’s just about that time again, with the WordPress 3.9 release just around the corner. We’ve taken a few release cycles off from making any major changes to the Guidelines, so now is a good time to take a look at what we can improve. To kick off the discussion, the admins propose the following revisions to the Guidelines:

    Required

    Sane Defaults: Themes are required to use sane defaults.

    Themes must not save default settings to the database without explicit user action, and Themes must function properly out-of-the-box without user configuration (that is: if the user does not save settings, the Theme will still function properly)

    Bundled Plugins: Themes must not bundle Plugins.

    Themes may incorporate support for Plugins, and may integrate Plugin code directly into the Theme (if that Plugin code meets the presentation-vs-functionality requirement), but Themes must not bundle Plugins as a whole.

    Arbitrary Header/Footer Scripts: Themes must not provide Theme options for arbitrary header/footer scripts.

    Arbitrary scripts are non-Theme-specific scripts added to the document head or footer to provide non-Theme-specific functionality. Suchscripts are Plugin territory, and pose a significant security risk if not handled properly. Custom CSS is acceptable, if properly sanitized.

    Theme Activation: Themes must not implement activation redirects, admin notices, or similar functionality.

    Theme Documentation: Themes must place any required documentation in a clearly marked readme file.

    Required documentation includes copyright/license attributions, Theme design constraints/limitations, description of non-standard Theme functionality, etc. Plugin-standard readme.txt is preferred, but not required.

    License: Themes are required to document in the Theme readme file the copyright/license attribution for all bundled resources.

    Themes are required to provide this documentation in the Theme readme file, regardless of where or how those bundled resources provide their own attribution. The purpose is to ensure that end users (and also, reviewers) don’t have to search for this important information, and to ensure that the developer has done due diligence to ensure that licenses for all bundled resources are GPL-compatible.

    Theme Credit Links: ThemeURI and AuthorURI, if both are used, must be from distinctly separate sites.

    Using both ThemeURI and AuthorURI is not required, and if only one is appropriate, then only one should be used. ThemeURI is a resource specific to the Theme. AuthorURI is a resource specific to the developer. For example, a Theme shop really only needs to use examplethemeshop.com OR examplethemeshop.com/themes/theme-slug. There’s really no need for both. Likewise, a non-commercial individual really only needs to use exampleperson.com OR exampleperson.com/blog/post-about-theme-slug. There’s really no reason to use both. But, if an individual has a ThemeURI of github.com/authorname/theme-name, and an AuthorURI of exampleperson.com, that’s totally appropriate.

    The intent here is to try to drive the focus of ThemeURI and AuthorURI back to being *end user* resources, first and foremost: information about the Theme, or a way to contact the developer. This clarification will hopefully eliminate some of the issues regarding appropriateness of ThemeURI/AuthorURI.

    Recommended

    Theme Documentation

    Themes are recommended to include a Plugin-standard readme.txt file.

    Themes are recommended to meet the WP core standard for inline documentation.

    Translation

    Themes are recommended to be translation-ready.

    Social Profile Links

    Themes are recommended to use a custom navigation menu when incorporating social network profile links

    Theme Options

    Themes are recommended to integrate Theme options into the core Theme Customizer

    Discuss

    Please discuss in the comments below.  If you have any additions to propose, please post them in the comments below, as well.

     
    • tskk 2:34 pm on February 7, 2014 Permalink | Log in to Reply

      I have seen reviewers asking authors to declare license for images which are part of the theme, do we authors need to? if so how? do we have to list all images used in the theme and declare their license?

      Also will the recommendations be migrated to required any time soon?

      • Chip Bennett 3:02 pm on February 7, 2014 Permalink | Log in to Reply

        Yes, bundled images must have licenses declared. If the developer created the images, then it is fine to state that they are copyright the developer, and released under the Theme’s license.

        • tskk 3:42 pm on February 7, 2014 Permalink | Log in to Reply

          but do we have to list them like :
          Filename.png – License ?

          If a theme has multiple skins, the list will be huge.

          • Rohit Tripathi 3:55 pm on February 7, 2014 Permalink | Log in to Reply

            We can do it folderwise. All images inside a particular folder fall under one license. And the ones in a different folder have a different license.

      • Chip Bennett 3:05 pm on February 7, 2014 Permalink | Log in to Reply

        Some things added as *recommended* are there as a phased approach toward *required*; others are not; they are simply there as a best-practice recommendation.

        • tskk 3:28 pm on February 7, 2014 Permalink | Log in to Reply

          Is theme customizer going to be required? if so how much time do we have? its going to be major overhaul for many themes.

          • Chip Bennett 3:32 pm on February 7, 2014 Permalink | Log in to Reply

            If there’s ever a timeline, we’ll communicate it. For now, this is the “get it on people’s radar” phase. :)

            And, it really isn’t a huge overhaul at all, if the Settings API is implemented properly. It takes minimal code to extend the Customizer via the Customize API.

      • fernandot 9:04 am on February 16, 2014 Permalink | Log in to Reply

        What about the changelog?

        It’s strange that there are complete guidelines for plugin submission that require a special readme.text file with a section for change log and there aren’t the same guideline for themes en the official repository.

        It’s frightening to update any theme with no information about the changes that you’re going to approve, while with plugins you are plenty informed about what is gonna happen.

        I’m truly concerned about this absence of mandatory for themes since they are the face of our sites. And yes, of course, I can make a child theme for my customizations but the problem remains the same: I don’t know what it is gonna happen when I update a theme from the repository.

        Why?

        Cannot this be changed?

        • Chip Bennett 11:17 pm on February 16, 2014 Permalink | Log in to Reply

          I agree with you in part, but the reality is, with the current infrastructure, even if we required Themes to include a Change Log, there would be no way to expose that Change Log to end users, either via the WP-Admin back-end, or via the Theme’s directory listing page. End users would have to pull up the Theme’s directory listing, then dig through the SVN files to find the readme or change log file.

          Also: requiring a change log would not ensure that all Theme developers add consistently useful and detailed information for each update.

          So, requiring a change log would not guarantee any real benefit to end users. Ensuring that end-user benefit is a long-term objective that will have to include changes both in what is required of Theme developers and also in the Theme directory infrastructure.

          • fernandot 5:29 pm on February 17, 2014 Permalink | Log in to Reply

            I agree with you, also in part :)

            I understand your complaints but I really believe that it could be a great benefit for users. You only visit the updates page in your dashboard and, if there is any update for plugins and themes the difference is huge and, in case of themes, a question of faith.

            As for plugins there could be mandatory to submit a change log, if plugin developers can do it (most of them no profit) more easy for theme developers to require because they are the main interested in promote their themes in repository, as a lot of them sell themes (profit).

            It’s my opinion as heavy user and WP consultor for some companies that demand it to me.

            • Chip Bennett 1:39 pm on February 18, 2014 Permalink

              The point is: we could require a Plugin-standard readme.txt for Themes, including Change Log and Update Notices, but it wouldn’t change anything. As far as I know, WordPress doesn’t parse Theme readme.txt files in order to display Update Notice on the Upgrades page. The infrastructure isn’t in place, the way it is for Plugins.

    • Inekris 2:52 pm on February 7, 2014 Permalink | Log in to Reply

      Just some clarification for non-English readers might come in handy.

      • By ‘must not’, the actual meaning is ‘are not allowed to’, ,ie, it is a binding restriction
      • By ‘end-user’, the person(s) actually administering, or have acces to the back-end of the site, not the readers.

      I know these questions might seem silly, but assumptions are the root of all screw-ups, so better safe than sorry.

    • Sami Keijonen 2:53 pm on February 7, 2014 Permalink | Log in to Reply

      I would definitely require translation-ready.

      It doesn’t encourage to use Plugin-standard readme.txt file, when it’s not used anywhere in .org site.

      Other than that guidelines seems good to me.

      • Chip Bennett 3:03 pm on February 7, 2014 Permalink | Log in to Reply

        I would, too; but we’re simply not ready. Consider making translation-ready formally *recommended* as the first step toward eventually making it *required*.

        • daveshine (David Decker) 9:09 pm on February 14, 2014 Permalink | Log in to Reply

          Can explain further what “we’re simply not ready” means? Is that regarding “Language Packs” or such?

          It should be required that all themes are translation-ready — that has nothing to do with language packs directly, though it would need no extra work if language packs happen for themes then… :)

          When I give support for my plugins, one of the biggest issues are bad internationalized themes or those that are not translation-ready at all.

          Any GOOD WordPress theme should be translation ready, if it is not, than it is no good theme IMHO, no matter how it looks…! :)

          • Chip Bennett 11:12 pm on February 16, 2014 Permalink | Log in to Reply

            “We’re simply not ready” means that Translation itself isn’t mature enough as a properly implemented feature to be *required* at this point. It’s a matter of education, not one of infrastructure. I agree that the ultimate goal is to require translation for directory-hosted Themes; but we need to ensure that implementing that requirement doesn’t raise the bar unreasonably high. Right now, it would. 90% – perhaps even 95% – implementation is fairly simple. But it is that 5-10% of string translation that prevents us from making it a requirement at this time.

            Full disclosure: I personally lobbied to propose that we make “translation-ready” a requirement in this go-round. But I agreed with the rest of the admins (and others queried) who argued that, as a whole, we’re just not ready to make it a strict requirement. So the approach we would like to take is to emphasize translation now, by making it *recommended*, and then setting some future end date, probably tied to a future WordPress release, at which time we will increase the criticality to *required*. And in the time in-between, we will put effort into educating developers regarding proper/best-practice implementation of translation.

      • Chip Bennett 3:06 pm on February 7, 2014 Permalink | Log in to Reply

        Note: there are (long-term) plans for readme parsing. Those plans will first include the Plugin-standard readme file, and will hopefully be extended to include others (readme.md, for example). So, making it *recommended* at this time is a first step in that direction.

    • Ulrich 3:02 pm on February 7, 2014 Permalink | Log in to Reply

      Just to clarify the readme file can also be a readme.md?

      I would like to see a Child Theme and Tags section.

      • Chip Bennett 3:07 pm on February 7, 2014 Permalink | Log in to Reply

        Yes, at this time, the readme file can be any clearly identified format (readme.txt, readme.md, README, etc.)

        I’m not sure what you mean by Child Theme and Tags section?

        • Ulrich 4:03 pm on February 7, 2014 Permalink | Log in to Reply

          What I meant have a guidelines for child themes. Something along the lines of “Child themes need to be functionality wise or design wise different to the parent theme.”

          There is no clear guideline what the theme needs to achieve to be allowed to use a certain Tag. accessibility-ready being the exception here.

    • Rohit Tripathi 3:22 pm on February 7, 2014 Permalink | Log in to Reply

      I don’t think Custom Navigation Menu for Social Profile Links is a Good Idea.

      +1 for everything else.

      • Chip Bennett 3:25 pm on February 7, 2014 Permalink | Log in to Reply

        Why don’t you think it’s a good idea? What are the disadvantages?

        EDIT: I have ulterior motives for this question. I’m presenting on the concept at WordCamp Dayton in a month, and would love to know any issues/problems/disadvantages with the concept, so that I can try to address them.

        • Rohit Tripathi 3:41 pm on February 7, 2014 Permalink | Log in to Reply

          Truly speaking. I can not think of a way in which it could be implemented. If you could provide a link to a theme, which implements social icons using custom menus, then I could provide better feedback on this.

        • kevinhaig 3:44 pm on February 7, 2014 Permalink | Log in to Reply

          The two themes I have use a widget for social links. It seems odd to add social links to a menu that is usually crowded to begin with.

          • Chip Bennett 4:09 pm on February 7, 2014 Permalink | Log in to Reply

            But a menu is just a “list of links”. A bunch of social profile links are a form of a “list of links”. Where it gets placed and how it gets styled is completely up to the developer.

            • kevinhaig 4:18 pm on February 7, 2014 Permalink

              I agree, however so is a social widget. So why is it recommended over a widget or other methods?

            • Zulfikar Nore 4:20 pm on February 7, 2014 Permalink

              Another problem that might arise here is the different icon fonts that are available. Are we going to say that all developers use one specific icon font set i.e. genericons?

            • Chip Bennett 4:21 pm on February 7, 2014 Permalink

              A social Widget is fine as well, but may not be as tightly integrated into the Theme. The recommendation is that the custom nav menu implementation is recommended over Theme Options or other Theme-specific implementations.

            • Chip Bennett 4:21 pm on February 7, 2014 Permalink

              Why would the icon font matter, if the Theme defines the CSS? :)

            • Zulfikar Nore 4:24 pm on February 7, 2014 Permalink

              So if theme A defines the CSS for Genericons and theme B defines its social menus as Font Awesome how would that carry over to the new theme?

              The user will still have to redo the menu won’t they?

            • Chip Bennett 4:37 pm on February 7, 2014 Permalink

              Why would the user have to redo the menu? A menu is just a group of “menu-item” post-types that get output as HTML list items. The separate Themes define the separate CSS to style the separate implementations of the social custom nav menu.

        • Ulrich 4:14 pm on February 7, 2014 Permalink | Log in to Reply

          This will be difficult for theme with another solution to switch.

          Is there a solution to do it with images and not icon fonts?

          • katmoody 4:28 pm on February 8, 2014 Permalink | Log in to Reply

            I’m newer here but wanted to jump in … hope that’s okay?

            This is my default way of handling menus for clients and I have done them with images, sprites and Font Awesome … maybe having a default would be a good idea. Justin Tadlock has a post that uses the same idea of a social menu but utilizes CSS selectors for the different social networks – which would make it possible to have lots of different social networks included without having to have them in the same order within the menu OR having to add class names. I can’t remember if he used Font Awesome with that example or a different one, but it works well and could be a great default.

            Theme authors could utilize hooks to change it around, use images, use an image sprite, or even just use text links …

            As for themes that already have a solution in place – that’s pretty easy – you just don’t display the menu (deregister it?)

            As for Justin’s work … both his Social nav posts are worth reading to understand how this could be done:

            http://justintadlock.com/archives/2013/08/07/social-media-nav-menus

            http://justintadlock.com/archives/2013/08/14/social-nav-menus-part-2

      • bassjobsen 3:39 pm on February 7, 2014 Permalink | Log in to Reply

        Can you give an example of a custom navigation menu for social profile links? I don’t understand what this mean at all.

        • Jose 7:23 pm on February 7, 2014 Permalink | Log in to Reply

          I know Stargazer, ( already mentioned ), I think Konstantin K’s Expound ( might ?) I know sorbet has it and uses really well. It’s just a simple way of creating a social links area without having to store/lose that information within themes. since menus are saved and theme options vary from theme to theme.

      • Ulrich 4:16 pm on February 7, 2014 Permalink | Log in to Reply

        @jeffr0 How did you find using it on wptavern?

        • Jeff Chandler 4:25 pm on February 7, 2014 Permalink | Log in to Reply

          I love the way Stargazer utilizes an icon font for social icons. It does limit the ability to use different icon images to represent social services but the icon fonts have the look and colors of the services and it’s portable so I’m willing to take the good over the bad.

          The only other potential downfall is if you want to make the icons larger, you must increase the icon font size. If you are using one icon font declaration in the CSS for use of icons across the entire site, adjusting the size will adjust all of them. Doesn’t work out so well if you only want the icons within the social menu larger instead of the entire site.

          • Chip Bennett 4:29 pm on February 7, 2014 Permalink | Log in to Reply

            The icon colors are actually defined via CSS – at least for Genericons. Also, because you can use specific CSS IDs and class names for custom nav menus, you can target your social menu specifically for adjusting the font size.

            • Jeff Chandler 4:31 pm on February 7, 2014 Permalink

              Yeah, I realize it’s just CSS and with the right CSS, I could increase the social icons by themselves without messing with the rest of the site. So not really a good or bad thing, just a means of how they are setup.

      • Konstantin Obenland 4:36 pm on February 7, 2014 Permalink | Log in to Reply

        Having a hard time to find a place for this comment. :)

        Even as (only) a recommendation, I think we are steering in very muddy territory here. While using the menu functionality to provide social links may be a good way to provide a somewhat portable social links experience, in reality it is not. There are no standards surrounding an implementation, so even if two themes use menus for it, it may very well be that they are still not compatible with each other.

        There are plenty of other, valid ways out there to provide social links. IMO it is not the place of the Theme Review Guidelines to recommend one approach over the other, especially without any kind of core provided support for a truly portable solution.

        We don’t recommend a specific way or script to implements sliders, we don’t tell theme authors how Featured Content should be done, we don’t recommend using `li`s over `div`s in comment list markup. Why would we recommend how to implement Social Links?

        • Chip Bennett 4:40 pm on February 7, 2014 Permalink | Log in to Reply

          The biggest advantage of the custom nav menu implementation is that the user retains user-created content (a group of links to social network profiles) when switching Themes. It is terrible user experience for a user to have to enter 6-10 social network profile URLs as Theme options every time the user switches Themes.

          And the implementation has no adverse impact. If a Theme doesn’t use it, the user still has to input the Theme options, and simply doesn’t apply the social menu to any of the Theme’s defined Theme Locations. It’s as if that menu doesn’t even exist.

          • Konstantin Obenland 4:43 pm on February 7, 2014 Permalink | Log in to Reply

            I’m not disputing that it is one of the better ways to provide that functionality.

            I’m saying that the Theme Review Guidelines have no place in even recommending it, without explicit core support.

            • Chip Bennett 4:46 pm on February 7, 2014 Permalink

              My comment above addresses this, but I see no problem at all with the Theme Review Guidelines adopting as “recommended” things that are best-practice implementations. That’s partly why some things are “recommended” rather than “required”.

              And core *does* have support for the implementation: the custom nav menu feature.

        • Konstantin Kovshenin 4:43 pm on February 7, 2014 Permalink | Log in to Reply

          Compatibility really just means the way the navigation menu location is called. In Stargazer and Expound it’s social, if all themes used the same theme location, it will all just work out of the box. If they use a different slug, well, the user will have to just assign their existing menu to the new location. If they don’t use wp_nav_menu(), the user can just assign their existing menu to a sidebar widget.

          In any case, the user will not have to re-enter their links to their social profiles every single time they switch a theme.

          • kevinhaig 4:54 pm on February 7, 2014 Permalink | Log in to Reply

            Usually if a user switches a theme, it’s for a longer period, and minor adjustments are not a big deal, in my opinion.

            However don’t you feel these kind of recommendations ultimately dampen the creativity of a theme development?

          • Chip Bennett 5:35 pm on February 7, 2014 Permalink | Log in to Reply

            While we want to defer to the developer’s prerogative regarding design intent and aesthetics whenever possible, I fail to see a “creativity of Theme development” argument in this case. We’re talking about a list of links.

          • Chip Bennett 6:08 pm on February 7, 2014 Permalink | Log in to Reply

            Since the Theme can define the menu CSS ID and class names, it’s really unnecessary to rely on a given custom menu name at all. The user merely needs to assign the correct menu to the correct Theme Location. Same with a Plugin that makes use of a menu Widget.

        • Chip Bennett 4:45 pm on February 7, 2014 Permalink | Log in to Reply

          I should also add: sometimes, the best way to *create* a standard is to pick an implementation, and then encourage its adoption. That’s been true for the Theme Hooks Alliance (outside of the Theme Review Team), Post Formats implementation, and many other features.

          To my knowledge, there is no better, more-portable way to implement social network profile links integrated into a Theme, than to use the custom nav menu method. So, unless and until a better method comes along, it is a net benefit to end users to encourage the best-known method as an adopted best-practice.

          • Konstantin Obenland 5:25 pm on February 7, 2014 Permalink | Log in to Reply

            sometimes, the best way to *create* a standard is to pick an implementation, and then encourage its adoption.

            Is it the WPTRT’s job to create a best practice?

            To my knowledge, there is no better, more-portable way […]

            That is a bad reason to create a recommendation. If anything, developers should be encouraged to come up with new, unique, and better ways. And of course there are already other ways of doing it out there!

            • Ian Stewart 10:03 pm on February 7, 2014 Permalink

              Another +1 to Konstantin’s points here.

            • Chip Bennett 10:14 pm on February 7, 2014 Permalink

              So, Konstantin and Ian: you both think it is a bad idea, and detrimental, for the Theme Review Team to promote and facilitate consensus around best practices? Really?

              I must strongly disagree with that position. Who better to educate and promote regarding best practices, and to help build consensus around those best practices? It is in the best interest of the WPTRT – and more importantly, it is in the best interest of end users – for WPTRT to engage in consensus-building around best practices.

              And promoting one implementation as recommended because it is the *current* best practice does not preclude the later development of *better* practices.

            • Emil Uzelac 10:40 pm on February 7, 2014 Permalink

              I will have to agree with Chip here, promoting best practices is not bad idea at all. Also why shouldn’t we educate?

      • Konstantin Kovshenin 4:36 pm on February 7, 2014 Permalink | Log in to Reply

        Just to clarify, using wp_nav_menu() to display links to social profiles doesn’t mean you have to use Genericons, or any icon font at all. You can still use sprites or images, that’s up to your theme.

        • Chip Bennett 4:37 pm on February 7, 2014 Permalink | Log in to Reply

          THIS. That’s the beauty of the implementation.

        • Zulfikar Nore 4:40 pm on February 7, 2014 Permalink | Log in to Reply

          That still does not make it portable from theme to theme as Konstantin Obenland points out above.

          • Chip Bennett 4:42 pm on February 7, 2014 Permalink | Log in to Reply

            How so? It’s always there. And someone could write a Plugin to define the CSS, and allow the social profile menu to be used, for example, in a sidebar Widget, regardless of the Theme.

            100% portability, with or without explicit Theme support.

            • Zulfikar Nore 4:43 pm on February 7, 2014 Permalink

              Then lets make it a “Plugin territory” in that case – always portable in terms of user defined links as well as the icons :)

            • Chip Bennett 6:05 pm on February 7, 2014 Permalink

              Why swing the pendulum that far that direction – too far in that direction, IMHO?

              If a Theme is designed such that social profile links are displayed in the site header (or footer), for example, you could do that with a dynamic sidebar. But that’s a lot of unnecessary hoops for both the developer and the end user, when the developer could simply output wp_nav_menu() in the desired location, and be done.

      • Justin Tadlock 5:36 pm on February 7, 2014 Permalink | Log in to Reply

        I want to provide a little feedback and answer a few questions on the whole social nav menu idea since I originally proposed it. This isn’t a direct response to Rohit only, but to all who have asked.

        The original article is here: http://justintadlock.com/archives/2013/08/07/social-media-nav-menus This shows how to create the menus with and image sprite.

        The updated tutorial is here with Genericons: http://justintadlock.com/archives/2013/08/14/social-nav-menus-part-2

        Those two posts go into quite a bit of detail and answer some of the questions some of you might have.

        I originally came up with this concept for a theme called Socially Awkward. After testing its success with users, I later added it to a theme called Stargazer. Both themes are on WordPress.org. Since then, it has picked up a little steam with other theme authors implementing it.

        The main reason for this concept was to handle data portability. The idea is that a user can create a nav menu with their social links. These can be used with nearly any theme either via a theme’s nav menu locations or widgets. They’re simply menu items.

        The cool part is that theme authors, if they choose, can define styles like what I’ve done with Genericons to make these menu items look cool without the user having to do anything other than select the nav menu location for a particular theme. It doesn’t require them to re-enter information or know the names of CSS classes to have their social menus look cool.

        This is but one approach to social profile links. I think it’s pretty cool. However, I don’t think it should be listed under “recommended”. What I’d really like to see is a separate section on the Make Themes site for “cool things you should try”. To me, this is nothing more than a resource that we should promote, which should be separate from the guidelines.

        • kevinhaig 5:07 am on February 8, 2014 Permalink | Log in to Reply

          +1 Justin

          I think your idea of social links is a very cool one, and I will look into it more.

          I also love the idea of a section on things to try.

          I just don’t like the idea of it being recommended, as developers will tend to gravitate to this solution as it is classified as a best practice. I’m not against best practices by the way, just not in this case. As theme developers move to this proposed best practice, it will in my opinion limit other creative ways of presenting social links.

          • Chip Bennett 1:01 pm on February 8, 2014 Permalink | Log in to Reply

            The idea is for developers to gravitate toward a consensus best-practice, because that gravitation leads to consistency for end users. It’s always important to be open to new and creative ways to do things, and that certainly applies here. And of course, a specific core-implemented solution would trump all.

            • kevinhaig 2:44 pm on February 8, 2014 Permalink

              I agree that consistency for end users is a good thing, but I think it’s important to balance that with creativity. Creative design also has a huge impact on the user experience.

              Incorporating social links into a menu is a great idea and an option that will fit many themes. But in some themes it may make better sense to go a different route.

              I think in this case it’s very a minor impact on the user experience, and as such I don’t feel it warrants being considered a best practice.

              Enough said….I do appreciate these kinds of discussions Chip! It’s one of the things that makes WordPress so great :)

            • Chip Bennett 3:07 pm on February 8, 2014 Permalink

              I agree that creativity is important, and I believe in deferring to the developer’s design and aesthetic prerogative. But, I just don’t see how this recommendation in any way hinders or infringes developer design. Bear in mind that we’re simply talking about HTML markup here – HTML markup for a “list of links”. Semantically, that’s a UL with a bunch of LIs. I don’t recall any Themes that are doing anything meaningfully different with the markup for their social profile links. Likewise on the back-end: the “list of links” is generated by a set of Theme options. There’s no “creativity” there. The Theme options are entirely utilitarian.

              The real creativity here is in the design/style of that markup – and that creativity is in no way hindered by using a custom nav menu to output the list items, or by having the user input their “list of links” via the custom nav menu UI rather than via the Theme settings UI. In fact, it’s the real beauty of this implementation. Want to use an icon font? You can. Want to use a different icon font? You can do that too. Want to use images or an image sprite? You can do that, too. It’s all defined in the CSS, by targeting link attributes.

    • bassjobsen 3:41 pm on February 7, 2014 Permalink | Log in to Reply

      I should make the standard readme.txt required

    • kevinhaig 3:53 pm on February 7, 2014 Permalink | Log in to Reply

      I’m not sure I fully understand the Arbitrary Header/Footer Scripts requirement.
      In themes I have developed I allow the user to set up a copyright strip at the bottom of the page, by entering an html line in a custom option panel. This allows them to set up links (for example designer links, or sitemap links). Is this what you are talking about?

    • Frank Klein 3:57 pm on February 7, 2014 Permalink | Log in to Reply

      Concerning the theme activation, the proposed guideline is “Themes must not implement activation redirects, admin notices, or similar functionality.”

      Does this exclude admin notices generated by something like the TGM Plugin Activation class?

    • Mel Choyce 4:18 pm on February 7, 2014 Permalink | Log in to Reply

      Any chance for allowing multiple theme authors any time soon?

    • Chip Bennett 4:24 pm on February 7, 2014 Permalink | Log in to Reply

      Unfortunately, that one’s outside of our control/scope. That’s an issue with the WordPress.org Theme Directory itself. If the infrastructure supported multiple authors, the Theme Review Team certainly would as well.

    • Konstantin Obenland 4:26 pm on February 7, 2014 Permalink | Log in to Reply

      Theme Activation: Themes must not implement activation redirects, admin notices, or similar functionality.

      “Similar functionality” is extremely soft. The Theme Foundry recently started to integrate “unboxing” messages right after activating themes. That has received nothing but exceptional feedback on WordPress.com, but would probably fall under this guideline. It is also not clear that while admin notices are forbidden in general, it is fine to display them in the context of plugin recommendation. I understand how redirects can be confusing, I don’t like the direction of the other two.

      Theme Credit Links: […] a Theme shop really only needs to use examplethemeshop.com OR examplethemeshop.com/themes/theme-slug. There’s really no need for both.

      I understand the requirements around each URL, I do not understand how having one makes the other obsolete. I think it is reasonable for a theme author to specify both URLs, respecting the current guidelines in place. The links are currently only visible to users in the Appearance menu, and have no effect on the front-end. If anything they provide users with more context, and avenues to get support. This would be one of the rules that seem arbitrary and overreaching.

      • Zulfikar Nore 4:28 pm on February 7, 2014 Permalink | Log in to Reply

        +1

      • Jeff Chandler 4:29 pm on February 7, 2014 Permalink | Log in to Reply

        Just a question but is this guideline also in reference to Helpers that can be used to provide a tour of the theme when it’s activated. Would those violate this guideline

        • Chip Bennett 4:35 pm on February 7, 2014 Permalink | Log in to Reply

          They already do. Core defines those as a core-only functionality. Unless/until core considers them to be open to use by Themes/Plugins, they’ll be disallowed. (That’s been true since their inception.)

          • Jeff Chandler 4:43 pm on February 7, 2014 Permalink | Log in to Reply

            Wow, and here I am constantly telling developers they should add helpers to their plugins or themes after activation so I know where to go to configure them. Now I feel bummed out for giving bad advice,

      • Chip Bennett 4:34 pm on February 7, 2014 Permalink | Log in to Reply

        I’d love to see some UX feedback on types of activation messaging/help/etc. The intent is to prevent misuse/abuse, not to prevent legitimate user assistance.

        As for the credit links: again (and unfortunately), the problem is the misuse/abuse of them. If they’re useful and appropriate, they’re generally going to pass.

        And as with most Guidelines, exceptions can be granted with sound justification. These Guidelines that get into subjective areas are very difficult to write objectively. It will always be a work-in-progress to improve and clarify them.

        • Konstantin Obenland 4:39 pm on February 7, 2014 Permalink | Log in to Reply

          These Guidelines that get into subjective areas are very difficult to write objectively.

          Ha, I remember it being the biggest challenge for me, when I started reviewing themes! :)

          But I really don’t see how only allowing one link rather than two improves that. It doesn’t change the nature of the linked content. It does not help in solving the challenge of subjectivity.

          • Chip Bennett 4:41 pm on February 7, 2014 Permalink | Log in to Reply

            It’s not that only one link instead of two is being allowed; rather, it is that the two links provide meaningfully different information.

            • Zulfikar Nore 4:56 pm on February 7, 2014 Permalink

              somethemeshop.com as author url provides meaningful info about the author and somethemeshop.com/blog/theme-slug has meaningful info on the theme.

              If that is the desired end result then why are we saying that is no longer acceptable? Or even considering it?

              The abuse/misuse is when neither of the links are relevant and meaningful in context right?

            • Chip Bennett 5:36 pm on February 7, 2014 Permalink

              If you’re landed on somethemeshop.com/blog/theme-slug, what are the chances that you can’t or wouldn’t find your way tosomethemeshop.com?

            • Zulfikar Nore 5:57 pm on February 7, 2014 Permalink

              The chances are pretty good but I still think we should not penalize authors for using their themeshop/dev site as author url under the guise of misuse/abuse.

              As long as the two are relevant to the theme then I say its perfectly fine to have them included.

            • Chip Bennett 6:01 pm on February 7, 2014 Permalink

              I don’t think it’s a matter of “penalizing”. The Theme URI and Author URI really aren’t publicly exposed (except for the one used as footer credit link). They’re entirely for conveying information to the end user.

              The ultimate point we’re trying to convey is that the links should be useful for conveying relevant information to the end user.

        • Zulfikar Nore 6:23 pm on February 7, 2014 Permalink | Log in to Reply

          I think the requirement should then be “If both theme url and author url are used” they “must be” relevant as in conveying….

          (a) Information about the author and
          (b) information about the theme.

          If the two conditions are not met then the url is not allowe be it the author or theme url.

          To outright say that author url is not allowed is a bit too restrictive IMHO!

          • Chip Bennett 6:30 pm on February 7, 2014 Permalink | Log in to Reply

            And to outright say that Author URL is not allowed is not the intent. :)

            In my mind, this mainly impacts:

            1) Theme shops. A Theme shop isn’t an “author”; an author is a person. So, a Theme Shop landing page is, from the end user perspective, redundant with the Theme’s page on the Theme shop’s site.

            2) Individual Theme developers who have a valid Author URI, but then use what amounts to a “hey, I released this Theme” blog post as Theme URI. Generally, such a blog post provides no additional, meaningful information for the end user from what is already provided by the Author URI.

            (Now, Otto’s example, where the developer provides a static page with Theme documentation, information, maybe support links, etc.? Entirely appropriate as Theme URI.

            I’m just struggling with the right words to articulate the difference.

      • Ulrich 4:59 pm on February 7, 2014 Permalink | Log in to Reply

        @obenland Do you think you could share a screenshot of what The Theme Foundry has done?

      • Ian Stewart 10:02 pm on February 7, 2014 Permalink | Log in to Reply

        +1 to both these points.

      • Emil Uzelac 10:48 pm on February 7, 2014 Permalink | Log in to Reply

        I would definitely love to see an example and users feedback as well.

    • Justin Tadlock 5:18 pm on February 7, 2014 Permalink | Log in to Reply

      I wanted to bring up some of these points in the admin exchange on this a couple of days ago, but I’ve been a bit busy this week. Now that I’ve had some time to sit down, here’s my response to the required points.

      Sane Defaults: This is something we’ve been pushing for some time. It’s definitely needed.

      Bundled Plugins: I agree on this as well, but I want to reiterate what I’ve previously said in this discussion to make sure we’re not taking this too far. Here’s the link: http://lists.wordpress.org/pipermail/theme-reviewers/2014-January/017291.html

      Arbitrary Header/Footer Scripts: +1

      Theme Activation: Agreed for the most part. However, I wouldn’t be entirely against all things like this. I’d like to see a particular implementation first before making an overarching decision on all features.

      Theme Documentation and License: Disagree in parts, particularly with copyright/license attributions. A license.txt file works just fine for this purpose. As long as the theme makes copyright and license clear, that’s all I care about.

      On the subject of readme.txt, I don’t believe we should be dictating much of anything that goes into that file. It should be treated **exactly** like that of the plugin directory.

      I also see this as largely another stumbling block for theme authors. I’d rather them focus on making great themes than having to figure out the complexity of doing a readme file the correct way. By and large, it has nothing to do with theme development and everything to do with what a few of us would like to see.

      Theme Credit Links: Strongly, strongly disagree. I simply can’t get on board with this at all. If I wanted to give justintadlock.com as my author URI and justintadlock.com/themes/example as my theme URI (what I used to do before having a separate theme site), I can’t think of a valid reason not to allow that. One of the earliest reasons for the theme review team was to prevent spam and people trying to game the system in some way. That’s the reason we check the author and theme URIs.

    • Samuel Wood (Otto) 5:32 pm on February 7, 2014 Permalink | Log in to Reply

      I disagree with the credit links. If I made a theme, I most certainly would use an Author URI of http://ottopress.com and a Theme URI of http://ottopress.com/themename or similar to that, and yes, that would be perfectly valid.

      To disallow this is not an acceptable “requirement”.

      • Chip Bennett 6:02 pm on February 7, 2014 Permalink | Log in to Reply

        Clearly, as-written, it’s not articulating what we’re trying to get after. That’s why we’re having the discussion: to generate the feedback necessary to articulate what we’re trying to accomplish.

    • Zulfikar Nore 6:35 pm on February 7, 2014 Permalink | Log in to Reply

      I totally agree with point #2

      But for #1….For most theme shops – the shop is the developer (a team effort) and therefore they are essentially the author.

    • Zulfikar Nore 6:38 pm on February 7, 2014 Permalink | Log in to Reply

      OK, I don’t know why this landed down here but it was in response to: http://make.wordpress.org/themes/2014/02/07/wordpress-3-9-guidelines-revisions-proposal/#comment-33797

    • Chip Bennett 6:44 pm on February 7, 2014 Permalink | Log in to Reply

      “Essentially the author” – but that’s not the intent of Author URI.

    • Jose 7:49 pm on February 7, 2014 Permalink | Log in to Reply

      I am for most of the things. I, too, will have to agree with Otto and Justin with credit links. We just have to use our best judgement when it comes to that. :)

      As for the readme I think it should be recommended not required.

      • Chip Bennett 8:01 pm on February 7, 2014 Permalink | Log in to Reply

        Yep – the intent of the credit links was to get wording out, and to get feedback. Expect changes there. :)

        And regarding the reaadme: the only thing that’s changing is that we’re specifying the location for any *required* documentation. Previously, we stated that certain things were required to be documented, but didn’t say where. So, we’re clarifying that the location for required documentation is in the readme file.

        The *format* of the readme is being recommended as the Plugin-standard readme.txt, but we’re not proposing that it should be *required* to be in that format.

    • Chip Bennett 8:06 pm on February 7, 2014 Permalink | Log in to Reply

      Regarding admin notices: would it be helpful to clarify that any admin notices must be related specifically to Theme setup, and not advertising in nature?

      • Ulrich 9:37 pm on February 7, 2014 Permalink | Log in to Reply

        Yes, I am working on an extension of the current activation notice. This is what I have created.
        http://grappler.tk/screenshots/Screenshot-20140205001.jpg

        It is only displayed once when the user activates the theme the first time. There is no advertising.

        • Chip Bennett 10:10 pm on February 7, 2014 Permalink | Log in to Reply

          That is certainly unobtrusive, but is it *necessary*? It merely provides a link to the Theme Options page – a page that is in a standard location that is the same for all Themes. I see this more as a user education issue than a real need.

    • CyberChimps 10:14 pm on February 7, 2014 Permalink | Log in to Reply

      “Theme Activation: Themes must not implement activation redirects, admin notices, or similar functionality.”

      This a bad move that will hurt users experience, and continue to cause user confusion.

      What we need is a core solution to the problem such as what I mocked up here: https://twitter.com/trentlapinski/status/428995176426532865/photo/1

      The reason we got rid of redirects was so people can switch between themes quickly without being redirected, a reasonable move. What this also did unfortunately was confuse first time users, increased theme abandonment rates, as well increases in support from people asking where the theme options went.

      First time users need hand holding to let them know where to go to setup their theme, find documentation, and support. We absolutely need some kind of method to on-board users to setup their themes for the first time. The current theme activation notice is useless, and doesn’t tell anyone anything.

      This is why my team and I are developing the concept above, and are hoping to get it in core and would love the Theme Review Admins to encourage we add a standard way of on-boarding users for all themes.

      On Social Profile Links: Poor solution, can we please figure out a better one? I think we need a core solution to this as well.

      On Theme Options in favor of the Customizer: Again not a good solution. The Theme Customizer is half baked, and the version of the Customizer is embarrassing compared to WordPress.com. It was implemented into Core way too soon, and needs to be refined and polished before it can ever be considered as a longterm solution to theme options.

      On that note, Theme Options are not going away even if we perfect the Theme Customizer. For example, how can we ever add drag and drop functionality to the blog or define settings for archives and templates from the theme customizer? You can’t, Theme Options aren’t going anywhere. Again would love a core solution or some kind of options framework for everyone to use, which would make a lot more sense, but forcing people to use the Customizer to do things it was never intended to do isn’t the solution either.

      • Chip Bennett 10:21 pm on February 7, 2014 Permalink | Log in to Reply

        “What this also did unfortunately was confuse first time users, increased theme abandonment rates, as well increases in support from people asking where the theme options went.”

        Has this been supported anything other than anecdotally? I’d love to see user testing on this point, and would certainly support solutions that resolve demonstrated UX issues.

        “On Social Profile Links: Poor solution”

        Why is it a “poor solution”? Please elaborate.

        “On that note, Theme Options are not going away even if we perfect the Theme Customizer.”

        You are correct. The Theme Customizer doesn’t replace Theme Options. At best, it could (potentially) replace Theme *Settings Pages*. Themes would still have to use either the Settings API or the Theme Mods API to define, save, and use Theme options. The recommendation is added only because it is beneficial to end users, and actually helps resolve the issue you mention above – because if Theme Settings are incorporated into the Theme Customizer, then end users can configure Theme Options and activate their Theme in one, single action.

        “…but forcing people to use the Customizer…”

        Recommended != Required. No one is being “forced” to do anything.

        • CyberChimps 10:56 pm on February 7, 2014 Permalink | Log in to Reply

          Seeing as we can’t track users we don’t have the kind of hard data wish we had to definitively prove this.

          All we know is we’ve seen an increase in first time users in our support forums who can no longer find our theme options since 3.8 was released and we had to remove our redirects. We’ve also seen an increase in theme abandonment since 3.8 which we are assuming is due to people who do not know what to do once the theme is activated and can’t find the theme options or our support forums. All we can do is track what happens in our support forums and listen to what users tell us, and ever since 3.8 was released we’ve seen increased confusion as to what to do after a theme is activated.

          We could even simplify it to something like this: http://i.imgur.com/mgtRBVV.jpg Or anything really that gives the user some kind of direction to go in after a theme is activated. Again the purpose of this is to give a first time user a guide on what to do next. The new activation notice does not accomplish this.

          As for the Social Profile links, again this is something that I think needs to be either addressed in Core or in a plugin. Almost all themes I’ve seen use stylized social icons, using the menu system for assigning links to icons is confusing. While a clever work around, I don’t even want to think about the support nightmare this is going to cause.

          As for the Customizer, again at most this can only be recommended for now. I was speaking about in the future of possibly requiring the Customizer.

          • tskk 11:03 pm on February 7, 2014 Permalink | Log in to Reply

            I too would like to redirect users to theme options page after activation, Redirecting theme there is helping them use the theme better.

          • Emil Uzelac 12:19 am on February 8, 2014 Permalink | Log in to Reply

            I will still stand against the redirects.

            The image you presented us with seems harmful and if really is beneficial and if it doesn’t cause any issues, maybe we can work something out. Nothing is written in stone, right?

            • Zulfikar Nore 7:53 am on February 8, 2014 Permalink

              +1.

              I’ll also stand against redirection.

              How about hooking in to the “Theme Actions” section on the active screenshot? A theme options button next to the Customize button sort of thing.

              You could also be innovative and add a secondary button below the current “Theme Details” on hover and maybe that too could open in a modal window with help details? Or better still, hook in to the current modal and details there?

              Just throwing some ideas around :)

            • Chip Bennett 1:04 pm on February 8, 2014 Permalink

              Here’s my suggestion for an improved workflow:
              https://core.trac.wordpress.org/ticket/26899

            • tskk 1:27 pm on February 8, 2014 Permalink

              That would need all themes to use customizer ditching the theme frameworks we use.

            • Chip Bennett 1:40 pm on February 8, 2014 Permalink

              No, it wouldn’t. Why do think that it would?

              Whatever options framework you use itself uses either the Settings API or the Theme Mods API. The Customizer doesn’t replace either of those APIs, and in fact, *requires* and relies on the use of one of the two APIs. The Customizer is merely a different *front end* for settings. Hooking into the Customize API doesn’t change anything at all with any of your current Settings. It can (but doesn’t have to) replace the Theme Settings page. But your options framework? It doesn’t replace that; in fact, it *can’t* replace that – and without your options framework, the Customizer wouldn’t work at all with your Theme’s settings.

        • nikeo 1:12 pm on February 8, 2014 Permalink | Log in to Reply

          +1 for this https://core.trac.wordpress.org/ticket/26899
          => Lot more advantages than drawbacks to me from a user experience perspective

        • Zulfikar Nore 2:04 pm on February 8, 2014 Permalink | Log in to Reply

          The proposed customizer redirect although has some advantages it will only benefit themes that have adopted the Customizer as the means for theme Settings.

          IMO it is defeatist on two counts …

          (1) It will go against the grain of “No Redirection” stance.
          (2) Bad user experience to land on an empty Customizer (except for the defaults) if the developer uses a custom options framework.

          We all seem to assume that all first time users are “dumb” so lets spoon feed them when the emphasis should be on educating them and then let them find their way to those places where they can better understand the facilities and use them effectively.

          • Chip Bennett 2:23 pm on February 8, 2014 Permalink | Log in to Reply

            You’re missing the point. The Customizer isn’t a “means for theme Settings”. It’s merely a front end that *exposes* existing Theme settings. It doesn’t change the way that Themes handle settings, at all. Not one bit. It’s just an alternate front-end – and a darn useful one, I might add, because of the real-time preview of changes.

            1) The Themes UI already includes a “customize and activate” link for Themes. It’s not a redirection; it’s merely part of the Theme-selection workflow. In fact, the Customizer is invoked before the new Theme is ever even active, allowing for user configuration and preview of settings before that configuration ever appears on the site front end. This is freaking awesome UX, not “defeatist”.

            2) I don’t think you’re understanding what the Customize API is or how it works. Unfortunately, that seems to be a somewhat widespread problem. We’re attempting to help alleviate that misunderstanding/problem by encouraging Theme developers to hook their existing options into the Customizer – emphasis on *existing*. Nothing changes, except that the Theme settings auto-magically get exposed in the Customizer. The Theme’s handling of those Settings doesn’t change. Not at all. Not even a little bit. Your Settings Page still exists (though if you wanted to, you could get rid of it). Your Settings framework still exists. Your Theme Settings are still added via register_setting(), still get passed through your defined sanitization callback when saved, and are still called via get_option(). None of that changes.

            Nothing “defeatist” there. Just awesome UX made available to the end user.

            “We all seem to assume that all first time users are “dumb” so lets spoon feed them…”

            That’s actually pretty ironic, given that the reason that I argue against Theme activation admin notices is because we should be educating users about where the standard location for a Theme Settings page is. Users aren’t dumb, and we don’t need to treat them as such. We’re merely *recommending* that Themes hook into an awesome API that provides a sweet end user benefit (real-time preview of settings configuration). It has nothing to do with users being dumb (not true) or with a systemic lack of educating users about basic WordPress UI (true, and a failure on the part of developers, not users).

    • PeterRKnight 4:04 pm on February 8, 2014 Permalink | Log in to Reply

      Just to be extra clear does a bundled plugin mean actually packaging the files with the theme?
      Or does it also apply when using an activation class that downloads & activates a plugin separately during the activation process?

      • Chip Bennett 4:06 pm on February 8, 2014 Permalink | Log in to Reply

        Activation scripts are fine. In that case, the Plugin files are not actually bundled with the Theme; the user downloads and installs the Plugin from the WPORG Plugin Directory.

        Bundled Plugins refer to Plugins for which the Plugin files are physically bundled with the Theme.

    • alex27 6:14 pm on February 10, 2014 Permalink | Log in to Reply

      Regarding Arbitrary Header/Footer Scripts – it’s still allowed to add a field for Custom CSS to be outputted in header, right?

    • wpweaver 7:43 pm on February 17, 2014 Permalink | Log in to Reply

      RE: Header/Footer scripts

      This is a good idea in theory, but….

      It seems to me the requirement overlooks a serious problem. The thought is that is plugin territory, but it isn’t in this case because there is no way to have a plugin get into header.php or footer.php. No actions, no usable filters.

      So say I want to add a video script right below or above my header image. The header image typically gets inserted in header.php by each theme, right? If not a video, then there are other examples of external sites providing a plugin script one might want in the header/footer – I know of some musician sites that provide very nice links to players and the like via scripts. But you can’t get modify that code from a plugin. I’ve tried to write that plugin, and I don’t know how to do it. There is no support from the core to do that. As far as can tell, doing so will require a new standard hook or something that all themes need to call from header.php and footer.php. To me, this is a huge gap in the API.

      So it is not a reasonable requirement. Unless that is not what you mean – stuff coming from header.php and footer.php. Or unless I missed something fundamental about how header.php and footer.php work.

      • wpweaver 7:56 pm on February 17, 2014 Permalink | Log in to Reply

        A good compromise requirement would be to only allow scripts in the header/footer from users with an appropriate user role.

        • Konstantin Kovshenin 7:59 pm on February 17, 2014 Permalink | Log in to Reply

          That would actually be a bad compromise because it’s insecure. You can’t assume that everybody is using the same set of capabilities for specific roles. For example, on many networks the unfiltered_html capability is turned off for everyone, even for the super administrator role.

          • wpweaver 8:00 pm on February 17, 2014 Permalink | Log in to Reply

            Role/capability – whatever.

          • wpweaver 8:04 pm on February 17, 2014 Permalink | Log in to Reply

            I’m after a bigger point – I think non-programmer but competent site admins should be able to insert a script to a musician’s player – or whatever – right below the header image (or above it, or after the title – don’t want to nitpick), or into the footer. These kind of needs exist. Banning scripts from header.php/footer.php would totally preclude this option from anyone other than someone with the ability to go in and modify PHP code. That is not a good option for “mere” mortal users.

            • Chip Bennett 1:44 pm on February 18, 2014 Permalink

              The Theme can provide template hooks (such as THA), or competent site admins can use a Child Theme to add the desired scripts.

              Again, an actual use case would be helpful here.

      • Konstantin Kovshenin 8:01 pm on February 17, 2014 Permalink | Log in to Reply

        You should check out the wp_head and wp_footer actions.

        • wpweaver 8:06 pm on February 17, 2014 Permalink | Log in to Reply

          Yeah – I have. Tell me how to do what I just said with those action? Let’s see – wrap header.php with output buffering, capture that, parse it, find the right place to insert the code. Yeah, right.

          • Konstantin Kovshenin 8:13 pm on February 17, 2014 Permalink | Log in to Reply

            Output buffering? We’re talking scripts here, ones that go in the head section of the site, or before the closing body tag in the footer, that’s pretty standard. Unless you’re referring to mid-page inline js-code, which users can already insert using the editor (if they have the necessary capabilities).

            • wpweaver 8:25 pm on February 17, 2014 Permalink

              And that is my point. A”mortal” user doesn’t have the “necessary capabilities. But they could fill in a box that says “Insert before site header image” or “Insert above menu” or “Insert after site title” – places the theme author can add the the code in “header.php”. This is a reasonable thing for people to want to do – so some with unfiltered_html should be allowed to do that without having to have a programming degree – or the level of comfort of editing PHP file.

              (Which of course is a terrible idea any way. Don’t know why that editor is still there! Change theme functionality via child themes only!!! Just HATE people even hinting of editing theme files! Nothing but trouble.)

              May we could put a little box up “I want to put this script in my header area. I promise to be a good person, and that I have the right to do this, and that the script does only nice things. I am aware of security issues.”.

              But header.php must output everything from …

              typically

              . So what I’m talking about is the stuff in the site content header – title, image header, menus. That’s where an average user wants to easily add extra HTML and nice scripts, and where there is no way for a pluging to get access to the code that generates that content. A theme option is the only feasible way to do that.

            • Konstantin Kovshenin 8:31 pm on February 17, 2014 Permalink

              So what you are referring to is various places in the theme where users should be able to “inject” their inline javascript code. Can you provide more use cases to what a user would insert “after site title” and “above menu” and “before header image”?

              Also, have you considered adding custom actions to the various places you would like users to inject code, and then using a plugin to inject the js during those actions? Finally, if you’re looking at standardizing such actions across many themes, you should take a look at the “Theme Hook Alliance” initiative.

          • wpweaver 9:07 pm on February 17, 2014 Permalink | Log in to Reply

            OK – a use case. I can’t find the music player script I’ve used in the past, but…

            Let’s say there is a site – say Google Maps – that provides nice little scripts to anyone that supports its latest and greatest features. Features that one one has yet provided a plugin to do. So maybe not google, but say great-maps-startup.com. To use this new feature, you have add the script source somewhere – by lets say in the HEAD block. So my theme has an option “Add to HEAD Section”. The user copy/pastes the block right in there. (or the footer if it should be at the end.) A plugin could enqueue the script, but plugins don’t keep up with all the sites that do offer such scripts.

            And if you are fussy, and want to do exactly what you want to do, sites like Google Maps will generate exactly the script you need to show whatever map you want. Things a plugin might not do. Things someone who can read the instructions at the site can follow, and copy and paste.

            The whole point of allowing this option is to let the site owner make the decision, and have the tools needed to add scripts where they need to be added. We can’t predict every use case – just the fact is is that scripts exist on many small and varied sites that average, non-techie site owners want to copy and paste and use without modifying php code.

            And, of course, one could add actions or filters to the theme to appropriate places in header.php to avoid the explicit proposed requirement, and offer a recommended companion plugin to do that (which is of course what I will do if this requirement is added), but the ability to add JavaScript music players or maps at specific places on a site (presentation of that content in appropriate spots) does seem like something a theme should be able to offer.

            I think having to “sneak” around the content/presentation issue, in this case presentation of content in site locations unavailable via plugins – e.g. header.php, is something that by reality is only available to the theme. No one else can affect just what comes out in the HEAD section, or the header/menu section typically found at the top of themes.

            And such specialized plugins can be confusing to the user – it has to be very theme specific. Moving stuff that can only be handled by the theme (header.php) into a fake-out companion plugin seems a little intellectually dishonest – no matter what the intent.

            And of course, I believe we owe it to the average WordPress user to offer options that are accessible to anyone – not just techies who know how to write code, or modify theme php files. The platform has moved beyond the days that only the informed elite can create custom sites.

            • Konstantin Kovshenin 9:17 pm on February 17, 2014 Permalink

              To use this new feature, you have add the script source somewhere – by lets say in the HEAD block. So my theme has an option “Add to HEAD Section”. The user copy/pastes the block right in there. (or the footer if it should be at the end.)

              Sorry but I just don’t get it :) That’s exactly what the wp_head action does. It’s meant to output stuff in the head section of your theme. Or any other theme for that matter.

              A plugin could enqueue the script, but plugins don’t keep up with all the sites that do offer such scripts.

              A plugin can also create an “Add to HEAD section” which would function exactly the same as your theme – it would output custom javascript in the HEAD section of the site.

              Maybe this is just a bad use case…

            • Chip Bennett 1:53 pm on February 18, 2014 Permalink

              First, that script doesn’t belong in the *Theme*. It is by-definition Plugin territory. The user would presumably want to retain that great-maps-startup.com functionality/integration regardless of active Theme.

              Second: two simple solutions already exist to incorporate such a script properly by the end user – Child Themes and Site Functionality Plugins.

              Third: the appropriate way for Themes to support arbitrary injection of user code at defined template locations is via defined custom template hooks (such as the Theme Hooks Alliance is trying to standardize). Offering a companion Plugin is a perfect solution, and not some sort of “loophole” or “workaround”. Heck, I do this: I define action/filter hooks in Oenology, and have an Oenology Hooks Plugin to facilitate users hooking into the template.

              Fourth: you’re simply wrong about document head output. We require the wp_head() call to come immediately before the closing HTML HEAD tag for this very reason: to ensure that Plugins and the end user can have precise control over the order that scripts and stylesheets output in the document head. Nothing can bypass the wp_head priorities by injecting something after the wp_head() call in the document head.

              Finally: I believe in focusing efforts on teaching end users the proper and safe way to administer their sites, rather than providing inherently unsafe hand-holding features. Teach users how to use a Child Theme. Teach users how to write a simple site-functionality Plugin. Don’t facilitate unsafe practices.

      • Ulrich 7:00 am on February 18, 2014 Permalink | Log in to Reply

        You could add support for the Theme Hook Alliance
        https://github.com/zamoose/themehookalliance

        You could then create a plugin that allows people to insert HTML in those separate locations. That plugin would then be compatible with any theme that uses the Theme Hook Alliance.

        I think you need to make the difference between HTML and JS scripts.

      • Chip Bennett 1:43 pm on February 18, 2014 Permalink | Log in to Reply

        Use case, please? I simply don’t understand the issue you’re trying to describe. “Arbitrary” scripts are scripts added by *users*, over which the Theme has no control. (That’s why they’re *arbitrary*.)

        If a Theme uses a script, it can simply bundle it, and enqueue it via appropriate hook (wp_enqueue_scripts, wp_head, wp_footer, etc.). This guideline has zero impact on a Theme’s ability to incorporate and to use a bundled script.

        • wpweaver 6:21 pm on February 18, 2014 Permalink | Log in to Reply

          Chip said: “Teach users how to write a simple site-functionality Plugin. Don’t facilitate unsafe practices.”

          This is an elitist and egotistical comment, and demonstrates what I think is a “we know better than you” attitude common among many WP developers. Who are the users? Not the WP core development team. Not plugin writers, not theme writers. The users are the thousands of individuals who plug along the best they can with their own sites, slowly becoming more competent every day. They are the thousands of independent SITE developers who eek out a living building WP based web sites for many others.

          These people can’t “write a simple site-functionality” plugin. A child theme – seriously? But they do have an artistic eye, and with the right tools, can build pretty amazingly functional sites. Saying they aren’t good enough to do that because they don’t have the skills to write a plugin is just a bit too much for my ethics.

          And these people are artistic perfectionists. They know how to go to Google and use the webmaster tools there to generate a perfect Google map JS snippet they would like to insert in the site content header – things that no plugin can do. The want to EASILY, without writing their own plugin (because the can’t) insert a little script to tweak some styling. They want to use some custom JavaScript available for some obscure site to add something to the header or footer. Want to see some real life use cases: Look at this discussion: http://forum.weavertheme.com/discussion/8149/poll-do-you-add-javascript-to-your-site-using-head-section-or-other-html-insertion-options

          All your use case confusion seem to miss the fact that there are tons of little content JavaScripts that add content, and that aren’t/can’t be supported by a plugin.

          Using wp_head allows the right before the closing HEAD tag, but virtually every header.php file then goes on to define the header content (like the header iamge) as well – ain’t no filter gonna fix that. Let’s see – Twenty-XXX, Oenology, … – I couldn’t find a theme that doesn’t do that, actually.

          And, as one last bit of evidence of the folly of banning script insertion from header.php and footer.php, currently anyone one with unfiltered_html capability can insert whatever they want into a plain old Text Widget. What is the difference?

          MAYBE, if there is some day a great theme hook for inserting content in then banning script insertion from header.php and footer.php might make sense, but asking the average designer to write code? Elitist in the extreme. Right now there are plenty of great reasons that a web designer with limited programming skills will want to insert a script in the code generated by header.php and footer.php, but there are no API tools to support that unless a theme does it directly.

          But I guess all these people aren’t good enough because they aren’t real programmers?

          • Chip Bennett 8:31 pm on February 18, 2014 Permalink | Log in to Reply

            Guidelines don’t impact users; they impact Theme developers. Users can inject whatever code they want, anywhere they want, in whatever template files they want. Nothing here would prevent them from doing that.

            I fail to see how a statement that espouses a belief that end users are fully capable of understanding how to use a Child Theme or a site functionality Plugin is somehow egotistical or elitist. I think it is far more elitist to assert that end users are *not* capable of understanding or learning how to use Child Themes or site functionality Plugins, for example:

            These people can’t “write a simple site-functionality” plugin. A child theme – seriously?

            Personally, I’ll keep on believing that users are fully capable of using a Child Theme, or learning how to write a site functionality Plugin. Maybe we just need to be better teachers? Maybe we need to take the time to teach the *right* way to do things, instead of encouraging lazy and unsafe, blind copy-and-paste code usage?

            Users who need to inject such arbitrary scripts at precise locations in the Theme template can and should use a Child Theme to do so. It’s not even feasible for a Theme to account for every possible template location at which a user might need/want to add some code or script. The closest we get to that is a standardized set of template action hooks, such as Theme Hooks Alliance – and even then, the correct implementation is a hook callback via Child Theme or site functionality Plugin. Exposing Theme options to that effect represents a significant security vulnerability. Doing so also represents Theme lock-in, by placing user-generated content in a Theme option; if the Theme goes, so too goes the user-generated content.

            Using wp_head allows the right before the closing HEAD tag, but virtually every header.php file then goes on to define the header content (like the header iamge) as well – ain’t no filter gonna fix that. Let’s see – Twenty-XXX, Oenology, … – I couldn’t find a theme that doesn’t do that, actually.

            Actually, Oenology makes extensive use of custom filter and action hooks, including the ability to override the site header (image/text) completely. Several other Themes do likewise, including every Theme that implements the THA standard.

            All your use case confusion seem to miss the fact that there are tons of little content JavaScripts that add content, and that aren’t/can’t be supported by a plugin.

            There are Plugins that allow insertion of arbitrary scripts in post-content, via shortcode, which is the correct implementation. Themes don’t need to be involved in post-content javascript.

            And, as one last bit of evidence of the folly of banning script insertion from header.php and footer.php…

            Part of the issue here is that you’re conflating two entirely separate issues: insertion of scripts via wp_head and wp_footer, and insertion of content in arbitrary template locations.

            The vast majority of impact of this Guideline will be on scripts hooked into wp_head and wp_footer. There’s absolutely nothing “Theme-specific” about those hooks; they are standard, universal template hooks found in every WordPress Theme worth using. A Site Functionality Plugin (or Child Theme functions.php callback) is the correct way for the user to hook arbitrary scripts into wp_head and wp_footer. Not Theme Options. Looking at your poll/forum post: if you’re encouraging your users to add Google Analytics, Facebook Like scripts, etc. via your Theme options, then you’re doing your users a disservice.

            • wpweaver 11:12 pm on February 18, 2014 Permalink

              I give up. You obviously don’t see your own elitism.

              “Guidelines don’t impact users; they impact Theme developers. Users can inject whatever code they want, anywhere they want, in whatever template files they want. Nothing here would prevent them from doing that. ”

              User’s CAN NOT inject code wherever they want. In spite of how “easy” you might think PHP programming is, IT IS NOT. There are thousands and thousands of WP site designers who can figure out how to copy/paste a little JS snippet, but who just aren’t as smart as you are, and don’t find it easy to write a little plugin, or write a little child theme. So the need to be able to do that without programming is really there. Honest. There is no need to turn a site designer into a programmer. They aren’t even interested in learning to program, and why should they?

              (And on the other side, I don’t quite understand why there are so many WP folks who think that only programmers should design themes. There are some nice themes for sure, but I’ve not met that many programmers who are really good design artists. That’s why I deeply believe there should be themes with plenty of ways for non-programmers who really are design artists to build beautiful web sites without the need to learn to program.)

              I’m not encouraging or discouraging people for adding JS snippets. These people are control freaks, and can’t find a plugin that will do every single thing a particular JS API to some well-known or obscure site has to offer, but they can get the exact JS snippet to do what they want. They want to add the exact Google tracking code they want and not rely on an invisible plugin to do it – but they don’t want to write a child theme to do that. And why should they?

              So no matter if the theme has to use a back-door plugin, or THA_ or whatever, there is still content lock in to a theme. Until there is a more widely used (what was it – 6 themes listed using THA_? It is good to see Oenology is one) standard, it just seems to me it is sensible to make such insertion areas part of theme options.

              And really – this is a sincere question – what is the difference between inserting scripts in the content header, a text widget, a footer content area, or even a post? Does it really matter where the script is injected, from a security standpoint? I really don’t know how that can be true. If done via a theme injection option, or via a text widget – the site developer can actually see the scripts are there, so I can see that “hiding” it in the header is a valid reason.

              So is the real issue theme lock-in? Then let’s say that, and not hide behind security as the reason.

              I guess it is designer vs. techie, and obviously the techies are the gate keepers.

            • Chip Bennett 1:47 am on February 19, 2014 Permalink

              Sorry, still not accepting that this position is elitist. It is simply not elitist to espouse the belief that the typical end user is perfectly capable of understanding Child Themes and Site Functionality Plugins; in fact, such a belief is the polar *opposite* of elitism.

              But let me address the point of user programming skill that you keep bringing up: owning and administering a web site is not a matter of design; further, owning and administering a web site comes inherent with the responsibility to know what you’re doing. That means some basic understanding of things like web hosting, FTP, server security, and, yes: PHP (if using a PHP-based application such as WordPress). WordPress isn’t the Ron Popeil of web applications that magically turns self-hosting a website into a set-it-and-forget-it Showtime Rotisserie.

              It is bad and irresponsible of us as developers to encourage and facilitate bad practices such as “just copy and paste this code snippet”. It is good and responsible of us as developers to help educate users about the correct, safe, and future- (and theme-)proof methods of extending WordPress functionality.

              What’s so hard about teaching someone how to write a Site Functionality Plugin? Here, I’ll demonstrate:

              examplecom-site-functionality.php

              <?php
              /**
               * Plugin Name: example.com site functionality
               */
              

              All done!

              Now, how hard is it to teach someone how to add their Google Analytics script to the file?

              <?php
              /**
               * Plugin Name: example.com site functionality
               */
              
              function examplecom_google_analytics() {
                  // Code goes here
              }
              add_action( 'wp_head', 'examplecom_google_analytics' );
              

              That’s not hard – to teach, or to understand. Users can get it; we just have to put in a modicum of effort to explain why this is a better method.

              Now, let’s back this up a bit.

              First: scripts injected by the user at wp_head and wp_footer are *by definition* Plugin territory, because they are (by definition) not part of or dependent upon the Theme, and the user would want and expect those scripts to be retained when switching Themes.

              There’s really no getting around that. Google Analytics scripts and similar need to be maintained by the user, apart from the current Theme.

              Can we agree on that point, at least? That arbitrary, user-defined scripts intended to be hooked into wp_head and wp_footer don’t belong in Theme options?

    • Narga 2:29 am on February 19, 2014 Permalink | Log in to Reply

      Themes must not implement activation redirects, admin notices, or similar functionality.
      But I refer it redirecto Theme Option Customizer after actived because user can get Theme Preview and can change Theme Options

    • Frumph 4:57 pm on March 6, 2014 Permalink | Log in to Reply

      Yeah, no. -1 to the requirement of no theme redirect, as per cyberchimp and everyone else who also disagree’s. -1 to stating licenses of my own images. -1 “Themes must not save default settings to the database without explicit user action”

      These are all recommendations; should not be requirements; everything listed about in the requirements section.

      • Chip Bennett 2:51 pm on March 7, 2014 Permalink | Log in to Reply

        Can you articulate *why* you disagree with the things you list?

        Regarding redirects: there needs to be a core-defined workflow. In the meantime: Theme settings will *always* be in the same place (Dashboard -> Appearance -> Theme options (or whatever the Theme names the page) ), and we would far better serve end users by educating them about this standard location, than by allowing all manner of arbitrary workflows that will only serve to confuse users.

        Regarding licensing of your own images: that’s always been required. We’re merely specifying a standard location to provide that explicit copyright/license information. For developer-owned resources, a blanket statement is fine. You don’t have to list each image individually, or anything onerous. You simply need to state that, unless otherwise indicated, all images are copyright you, and licensed under [theme license].

        Regarding not saving default settings to the database: why do you oppose the requirement? Does it force developers to implement sane defaults so that the Theme works “out of the box” without user intervention? Yes. That’s the point. But it’s not a difficult change, at all.

        • tskk 3:00 pm on March 7, 2014 Permalink | Log in to Reply

          I have seen many reviews where reviewer doesn’t agree with statement like “unless otherwise indicated, all images are copyright you, and licensed under [theme license].”

          So if you can specify that its acceptable in the rules, it would be helpful in avoiding arguments.

          • Chip Bennett 8:49 pm on March 7, 2014 Permalink | Log in to Reply

            Why would such a statement be unacceptable, and why wasn’t it resolved in-ticket (or an admin brought into the ticket)? Of course such a statement is acceptable. The onus is on the Theme developer to ensure that it’s *true*; but assuming that it is, it is perfectly fine to make such a blanket statement.

  • Chip Bennett 1:25 am on February 5, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Theme Review Incentive: January 2014 Winners (and Program Updates) 

    Congratulations to @rohitink, @ZGani, and @alex27; you three have completed the most new Theme approvals for January! (This marks the third time in a row that these three have won the incentive.)

    Please post your Featured Theme selections in the comments, with a link to the Theme’s WPORG Theme Directory listing. The Themes that will be cycled out are: RidizainSugar and Spice, and Sixteen.

    A total of 78 new Themes were  approved by 17 reviewers during the review period.

    While we have not had a formal incentive program for Theme Updates (Priority #1 Themes), we have decided once again to recognize @tskk, who completed 143 Theme update approvals during the review period. (This marks the third time in a row that he has also won the incentive.) @tskk, please also post a Featured Theme selection in the comments, with a link to the Theme’s WPORG Theme Directory listing. The Theme that will be cycled out is: Alexandria.

    Program Changes

    As mentioned previously, we’re going to be making some changes to the Review Incentive program – changes that are designed both to increase the number of monthly winners, and also to increase the accountability of reviews. We want to be able to reward more reviewers, which a “top three” program limits. And unfortunately, whether due to the increased number of new reviewers, or less-than-thorough reviews resulting in approval, the Admins have had to spend more time than we should on auditing and reopening tickets that need further review. (Part of that, of course, is reviewer training/education. We’re committed to improving that as well – but right now, all my time is spent on approved-Theme audits, leaving no time to work on improving training/education.)

    So, the program changes will hopefully address both needs.

    More Winners

    The first change we’re announcing is that we’re no longer using a “top three”method of choosing winners. Instead, each month, any reviewer who meets the minimum number of new-Theme approvals will get to choose a Featured Theme. That minimum number will vary from month to month, and will be the greater of a fixed minimum (5 Theme approvals) and a maximum of 1/10 of the total number of new Themes approved for the month. (That means that each month can have up to 10 winners.)

    So for instance, this month, 78 new Themes were approved and made Live. So, the minimum would be 1/10 of that number, or 8 (7.8). So, any reviewer who had at least 8 new Theme approvals would be eligible to select a Featured Theme for the month. (An additional 2 reviewers would have been eligible.)

    We are also formalizing the Theme Update reviews accordingly. For Theme Updates, the minimum number will be 1/4 of all Theme Updates approved and made live. So for instance, this month 306 Theme Updates were approved. So, any reviewer who had at least 76 Theme Updates approved would be eligible to select a Featured Theme for the month.

    We have a total of 10 Featured Theme slots to reward, and each reviewer may choose only one Featured Theme (even if eligible via both New Themes and Theme Updates). So in the off chance that we have the maximum number of winners – 14 – with no duplication, the Admins will determine which 10 will win. (I don’t anticipate this ever happening.)

    More Accountability

    But along with drastically increasing the number of monthly winners, we are making changes to the Theme approval process.

    The approved-Theme audits that Admins perform have too often become secondary reviews – to the point that we simply can’t get through the queue fast enough. Generally, I have been reopening 8 or 9 out of every 10 tickets closed as “approved” – and many times, for significant and/or fairly obvious issues. Please: ask questions in-ticket (cc: an admin if you need to) or on the mail-list during your review. Ask for help if you need it (e.g. for overly complex Theme options libraries). We are a team, and are here to help one another. But once it’s closed as “approved”, that means that the reviewer believes the Theme meets all Theme Review Guidelines.

    So, starting this month, any ticket that has to be reopened after being closed as “approved” will not count toward the incentive program.

    Hopefully, this change will free up some of the Admins’ time, and will enable us to focus more time on training, education, and finding ways to continue to make Theme review easier, especially for new reviewers.

    Caveats

    Just as a reminder: the Review Incentive program has always been intended to be a fun way to encourage reviews and to reward reviewers. If it becomes burdensome, causes too much team strife, results in too many people attempting to game the system, causes people to be unwilling to work together as a team, or otherwise distracts from the purpose of the Theme Review Team, it will have to be discontinued. Please keep the incentive in its proper perspective. I believe it has been wildly successful up to this point. (Themes are being approved and made live at a rate at least three or four times greater than before the program was instituted.) Let’s all have fun with it, and remember that it is intended to help us fulfill our purpose as a team: to get as many great Themes as possible into the hands of end users.

    As always: thank you, all, for your contributions, and for volunteering your time and effort. If there is anything that the Admins can do to improve the review process, please let us know.

    Update

    Based on feedback in the comments, we have decided that the two reviewers who would be eligible this month under the new incentive rules should also get to select a Featured Theme. So, congratulations, @pagelines and @cyberchimpscode! Please post your Featured Theme selections in the comments, with a link to the Theme’s directory listing.

     
    • tskk 1:32 am on February 5, 2014 Permalink | Log in to Reply

      Wonderful changes :)
      But there may be more opposition to program.

    • tskk 1:43 am on February 5, 2014 Permalink | Log in to Reply

      I am thinking 4 rewards for #1 queue will put new theme reviews on back burner, so may be 2 themes for top 2 reviewers in #1 queue and 1/10 for new themes will be good, just a thought.

      • Chip Bennett 1:44 am on February 5, 2014 Permalink | Log in to Reply

        Remember: there can only be *up to* four, and only then, if exactly 4 people review exactly the same number of tickets. If we find that it’s unbalanced, though, we’ll adjust the minimum up to 1/3 if we need to.

        • tskk 1:48 am on February 5, 2014 Permalink | Log in to Reply

          No, I mean reviewers will compete only in #1 queue and ignore new themes. 1 or 2 at most should be enough instead of 4

          • Chip Bennett 1:56 am on February 5, 2014 Permalink | Log in to Reply

            Well, if someone keeps getting 1/2 of the Priority 1 tickets, as has happened the past 3 months, that won’t even be a possibility. ;)

            Also: a marginal increase in Priority 1 activity will be self-limiting, because there won’t be enough tickets to go around. Also, the New Themes category will be far easier to meet eligibility: this month would have been 8 New Themes approved, vs. 76 Theme Updates approved, for eligibility.

            • tskk 2:05 am on February 5, 2014 Permalink

              True indeed, as usual all eventualities accounted for :)

            • tskk 2:09 am on February 5, 2014 Permalink

              Can a theme shop have 2 employees competing ( one in #1 and another in #3/#4) and get 2 themes as reward?

            • Chip Bennett 2:10 am on February 5, 2014 Permalink

              One selection per username.

          • tskk 2:18 am on February 5, 2014 Permalink | Log in to Reply

            So, 2 employee’s can review themes under their own username, win incentive and nominate their employer’s themes? (2 featured themes from same theme shop)

            Sorry for going into fine print, Its bound to happen and don’t want to see strife, better to know whats allowed and whats not :)

            • Chip Bennett 2:40 am on February 5, 2014 Permalink

              I’m going to trust that the commercial Theme shops who participate in Theme Review will continue to demonstrate integrity, as they have done so far. If we get to the point that we’re writing specific rules for every possible circumstance, then the program will have failed, and we’ll have to find some other alternative.

    • Rohit Tripathi 1:44 am on February 5, 2014 Permalink | Log in to Reply

      First of All, Excellent Changes. I really Appreciate that re-opened tickets won’t be counted anymore. That will seriously reduce the amount of low quality reviews which do not involve even looking at the code, and just reviewing on the basis of design.

      Just 2 Queries.

      How would one be able to track the themes that were set to live without being re-opened? Will there be any separate list on the following page -> https://themes.trac.wordpress.org/report ?

      Does anyone else also think that, the Incentive for theme update could be potentially misused?

      • Chip Bennett 1:48 am on February 5, 2014 Permalink | Log in to Reply

        I’m still working on a long-term solution to tracking. Otto and I have some ideas, and in the meantime I may just use a keyword as a stop-gap.

        Yes, there is potential for the system to be gamed. That’s why I added the reminder caveat. If we suspect anyone is gaming the system, they’ll be disqualified and have their reviewer privileges revoked. If system-gaming becomes too intrusive, we’ll be forced to end the program.

        We really should all be able to work on the honor system.

        • Rohit Tripathi 1:53 am on February 5, 2014 Permalink | Log in to Reply

          Well, I hope everyone would honor and respect this program. And with a possibility of 10 reviewers being awarded I think, people will respect the system and there won’t be any manipulation of the system.

          Best of Luck, and I would like to Continue with “Sixteen” as my pick for featured theme, this month as well.

    • tskk 2:48 am on February 5, 2014 Permalink | Log in to Reply

      I will opt for Alexandria http://wordpress.org/themes/alexandria this month.

    • Jose 3:24 am on February 5, 2014 Permalink | Log in to Reply

      Awesome job folks!

      Those are some interesting changes to the incentive. I love it. I think this should be a great way to see some others share in that limelight.

    • alex27 9:42 am on February 5, 2014 Permalink | Log in to Reply

      I like the way this program is going. This should make many people happy :)
      For me I’d like to select Sugar and Spice (http://wordpress.org/themes/sugar-and-spice), though when I look at Themes page, there’s still Corpo and Hueman featured there, which were supposed to be cycled out 2 weeks ago.

    • Chip Bennett 1:49 pm on February 5, 2014 Permalink | Log in to Reply

      Question for the community: given the changes in the program announced above, should we let the two who would be eligible under the new rules choose a Featured Theme for this month?

    • Sandy 4:13 pm on February 5, 2014 Permalink | Log in to Reply

      Yes actually that’s great i review theme very slowly and don’t want that my reviewed theme re-opened any time always want there should be good work.
      Recently i hear there is program like this may be it benefits or not but people from around the World using my design it gives me happiness WPORG performed big role in this.

      Thanks

    • Chip Bennett 1:27 am on February 6, 2014 Permalink | Log in to Reply

      Post updated based on community feedback. Congratulations, @pagelines and @cyberchimpscode!

    • Emil Uzelac 2:18 am on February 6, 2014 Permalink | Log in to Reply

      @pagelines you want DMS to be featured or?

    • pagelines 1:56 pm on February 6, 2014 Permalink | Log in to Reply

      Yes, DMS it will be: http://wordpress.org/themes/dms/

      Thanks a lot guys! :)

    • Zulfikar Nore 10:51 pm on February 6, 2014 Permalink | Log in to Reply

      Now that’s the spirit of the game :) – in total agreement and congrats to both @cyberchimpscode and @pagelines.

  • Chip Bennett 3:39 pm on January 30, 2014 Permalink | Log in to leave a Comment  

    Using the Theme Customizer with the Theme Mods API 

    Several developers are hooking into the awesome Theme Customizer API, and in many places even replacing traditional Theme Settings pages with the Theme Customizer. This is a great development, but there’s one caveat when using the Theme Mods API (as opposed to the Settings API): you have to be sure to sanitize on input.

    With the Settings API, the Theme registers its setting via register_setting(), which accepts a sanitization callback as one of its parameters. When you hook into the Theme Customizer with Settings API-defined options, the user-input option data are automatically passed through the defined sanitization callback. But the Theme Mods API is designed to be much simpler (and generally more user-friendly), and has no analogous method to define a sanitization callback. That means that user-input option data must be explicitly sanitized on input.

    Fortunately, the Theme Customizer API provides a way to sanitize Theme Mods option data: the ‘sanitize_callback’ parameter of the add_setting() argument array. Didn’t know about that parameter? Don’t worry; neither did I until recently. It’s so super-secret that it’s not even listed in the add_setting() method Codex entry. Fortunately, Konstantin Obenland discusses it here.

    Here’s an example. Let’s say the setting is for a slider speed option. The user is expected to enter an integer (in seconds). Here are typical add_setting() and add_control() method calls:

    $wp_customize->add_setting( 'prefix_slider_speed', array( 
    	'default' => '5'
    ) );
    		
    $wp_customize->add_control( 'prefix_slider_speed', array(
    	'label'    => __( 'Animation Speed in Seconds', 'textdomain' ),
    	'section'  => 'prefix_slider_section',
    	'settings' => 'prefix_slider_speed',
    	'type'     => 'text'
    ) );
    

    See the problem? The user can enter anything into that text field, and WordPress will dutifully add the user-input data into the database, and output it upon request, via get_theme_mod().  What happens if the user inputs the following?

    1000" onclick="javascript:alert(1)" data-foo="
    

    (Note: don’t try this at home, kids)

    Enter ‘sanitize_callback’:

    $wp_customize->add_setting( 'prefix_slider_speed', array( 
    	'default' => '5',
    	'sanitize_callback' => 'prefix_sanitize_integer'
    ) );
    

    Once the callback is referenced, you just need to declare it (if it’s a custom function; in many cases, including this one, you could simply pass a core-defined sanitization function here and be done):

    function prefix_sanitize_integer( $input ) {
    	return absint( $input );
    }
    

    Now, the saved input is sanitized as an actual integer.

    There are several valid sanitization methods; the key here is to ensure that you’re aware of the need to perform sanitization.

    P.S. Anyone want to show the Customizer API Codex entries some love? The sanitize_callback parameter isn’t mentioned, and none of the method entries have source references.

     
    • Samuel Wood (Otto) 3:54 pm on January 30, 2014 Permalink | Log in to Reply

      I updated the codex. Added info on the sanitize_js_callback too.

      Minor point: You don’t have to use custom functions for every little thing. This would work just fine:

      ‘sanitize_callback’ => ‘absint’

      One way to think of these sorts of things is with the idea of a “filter function”. In WordPress, a “filter” takes some input, modifies it, and expects to have that input returned afterwards. This pattern is commonplace in PHP itself, with all sorts of things. Any of those PHP built-in functions can be used as filter functions without a problem.

      For absint, which is a WP function, it’s basically the combination of the PHP functions abs() and intval(). If negative numbers were acceptable, then just using ‘intval’ would work too.

      • Chip Bennett 4:41 pm on January 30, 2014 Permalink | Log in to Reply

        Yep; mentioned that: …if it’s a custom function; in many cases, including this one, you could simply pass a core-defined sanitization function here and be done ;)

    • Samuel Wood (Otto) 4:06 pm on January 30, 2014 Permalink | Log in to Reply

      Oh, and since HTML colors are commonplace, there’s a few functions for this so you don’t have to reinvent the wheel.

      The sanitize_hex_color() function will act as the sanitize callback for anything requiring a hashed color, like #123456.

      The sanitize_hex_color_no_hash() function will act as the sanitize callback for anything requiring a non-hashed color, like 123456.

      The maybe_hash_hex_color() function will act as the sanitize_js_callback for anything requiring a hashed color. If the value is unhashed, it will hash it for you. This is generally only needed if you’re using sanitize_hex_color_no_hash() to start with, and you want the hashed value in the customizer and the unhashed value in the database.

      • Chip Bennett 4:43 pm on January 30, 2014 Permalink | Log in to Reply

        Ideally, core would define sanitization functions for all common data types, and then sanitize appropriately based on a ‘data_type’ parameter (for either the Theme Mods API or the Settings API).

        As a good middle-ground, the Data Validation Codex entry could use some freshening up, to list all the core-defined sanitization functions, with code examples. (For example: I never knew about the hex color sanitization functions, until just now.)

        • tskk 4:48 pm on January 30, 2014 Permalink | Log in to Reply

          I was about to ask if there is a list of core defined sanitization functions :)

        • Samuel Wood (Otto) 5:40 pm on January 31, 2014 Permalink | Log in to Reply

          While there are many functions that can be used, and knowing about them is half the battle (GIJoe!), I’d be careful in any such list of functions to note that in most real-world cases, none of them would be appropriate. Sanitization is about safety, certainly, but it’s also about making sure that the input makes sense.

          For example, let’s quickly enumerate the various data types commonly used:

          • Numbers. These can be integers, floats, negatives, and limited to ranges. Any sanitization function should certainly ensure that the data is a number. You could use intval() or floatval() for that, and if negatives were not allowed, you could use abs() for that. Limiting to a valid range (1-100, say) would require a custom function.
          • Strings. Strings can obviously take any form, and one should do things like strip_tags on them if HTML is not allowed, or use kses if a limited set of HTML is allowed. But one might want to check for length as well, and things of that nature.
          • Sets. Checkboxes or radio controls or dropdowns will only have some limited number of choices, and a sanitization function for these should make sure that the input is one of those choices. No built-in function can satisfy that demand.
          • Specific formats. Like HTML colors. There can be pre-defined functions for some of these, but there cannot be for all of them. Consider a date input, one might want to run the input through strtotime() to make sure that the result is a meaningful date and possibly within a reasonable range.

          For most cases, a custom function will be desirable. For safety cases, you can sometimes get away from using a built-in function, but if you want to bulletproof inputs, then you will need custom functions to check not just the safety aspects, but the sanity ones as well, and to have it return default values when the input falls outside of the expected values.

    • Rizqy Hidayat 1:25 pm on March 27, 2014 Permalink | Log in to Reply

      Cool, this was what I’m looking for. But for functions like sanitize_hex_color(), sanitize_hex_color_no_hash(), are the any documentation for these? Cause I found nothing when searching in the Codex.

    • mcunha98 5:36 pm on April 23, 2014 Permalink | Log in to Reply

      Chip

      This is an obligation ?

      I had my theme reffused because I don’t use it in “ALL” settings, but for example in colors or in dropdownlists this is totally unnecessary.

      I understand that you need to use an sanitize only you need to check the data (an integer, a date, etc…) for free text and previous defined options not, right ?

      • Chip Bennett 2:08 pm on April 24, 2014 Permalink | Log in to Reply

        As a general rule (from the Guidelines), all untrusted data (i.e. all user input – Theme settings, Widget settings, custom post meta data, etc.) must be sanitized on input and escaped on output. The Theme Customizer is merely an alternate admin UI for either the Settings API or Theme Mods API, and still requires all input to be sanitized.

        If you have questions about sanitization of specific options passed through the Customizer, please ask in the ticket associated with the specific Theme. Either you or the reviewer is welcome to CC an admin to help if needed.

  • Chip Bennett 1:47 pm on January 28, 2014 Permalink | Log in to leave a Comment
    Tags:   

    Time for a New Team Rep 

    The time has come again for WordPress community contributor groups to select new Team Reps. The Theme Review Team is looking for someone not a member of the admin group to take on this role.

    What is a Team Rep? What would you be getting yourself into? Essentially, the Team Rep is a PR/communication role. The primary duties of the Team Rep are to post regular team updates on the Make/Updates site (the Theme Review Team posts updates each Monday, and we auto-generate the stats we report), and to act as a liaison between the Theme Review Team and the other community contributor groups. There are infrequent meetings (IRC or Google Hangouts), since sometimes communication is easier outside of the written-only medium of a P2 blog.

    Here’s how Jen describes the role:

    • The job description is to post updates and to be a liaison between your team and the rest of the contributor groups via this site. There are a lot of weekly updates, but not so much liaising. When I’ve posted things for comment, it has appeared that people are responding based on their own opinion rather than getting their team’s group opinion and relating it back.

    So that’s really it: the Team Rep facilitates communication with other community contributor groups. It really is a great way to contribute without taking on the added stress, responsibility, and commitment of a team leadership role.

    Ideally, we would have two: a primary and an alternate; but since @emiluzelac and I have covered both roles since the inception of the Team Reps idea, I’m sure we could continue to cover the alternate rep role should we not find two people interested in stepping up.

    Interested? Post comments or  questions below, and discuss!

    Edit: if you’re thinking about volunteering, please include your Trac Username in your comment. I know most of the reviewers primarily by Trac Username, which isn’t always the same as your display name here. :)

     

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel