WordPress.org

Theme Review Team

Recent Updates Page 3 Toggle Comment Threads | Keyboard Shortcuts

  • Tammie 6:17 pm on April 7, 2015 Permalink |  

    Theme review team weekly notes

    The logs are here:
    https://wordpress.slack.com/archives/themereview/p1428429623002869

    We had a really short meeting as there was no topic. This is an issue we’ve had previously and was solved by getting topics. Lets do that again. I’m going to leave the comments here for people to add topics and issues they’d like to see brought up in meetings. In the past we’ve had a lot of success with this, but as a community we should all decide the direction so feel free to add your suggestions.

    Here are my suggestions:

    • Sub project status. What is going on with the doing_it_wrong theme? What is going on with the multilingual push?
    • Contribution days. We have the contribution pack up, but what now? How can we get it used beyond those of us in the community here so more days can have theme reviews?
    • Mentoring. We don’t have a solution. What can we do? Lets have actions, we all know it works so lets make strides to get that working.
    • Design emphasis. What was successful from our design challenge weekend (what wasn’t) and what can we do to push on with the focus on design?
    • Accessibility challenge. What is going on about building bridges between the two teams? How can we get more reviewers trained up to do accessibility reviews? Should we have a challenge weekend?
    • Learn-ups. We had some success with them during the design challenge weekend. Could we do more on different topics?
    • On-boarding reviewers easier. What can we do to make the first steps easier? Could we have hangouts? Could we have videos? What materials and things could we produce to make the journey easier?
    • Code examples. This is happening slowly, how can we form a group of people to really hit this and make sure we get a good example base?

    Ideally we’d also be looking for people to spearhead any initiative we mention. This is a chance for you to really take on a project and make an impact for the future of theme reviewing. Several people have done this and I’d love to see more take on projects and call them their own.

     
  • Jose Castaneda 9:26 pm on March 31, 2015 Permalink |  

    Handbook Examples: Stylesheets and Scripts 

    Let us continue with making some examples, shall we?

    This one will focus on scripts and stylesheets.

    No hard coding of scripts, styles and Favicons unless a browser workaround script. Everything should be enqueued.

    This does include the main stylesheet. I’ll start with a few:

    Example:

    All stylesheets must be enqueued.

    add_action( 'wp_enqueue_scripts', 'my_parent_theme_css' );
    function my_parent_theme_css() {
        wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
        wp_enqueue_style( 'child-style', get_stylesheet_uri(), array( 'parent-style' ) );
    }
    

    Example:

    No hard-coding of scripts.

    <script type="text/javascript" src="<?php echo get_template_directory_uri(); ?>/js/theme-slider.js"></script>
    <script>
    jQuery( document ).ready( function( $ ){
        $( '.slider' ).fancySlider({
            'autoplay': <?php echo get_theme_mod( 'slider-autoplay', true ); ?>,
            'navStyle': '<?php echo get_theme_mod( 'nav-style', 'circles' ); ?>',
            });
    });
    </script>
    

    In the functions file:

    add_action( 'wp_enqueue_scripts', 'my_theme_slider_options' );
    function my_theme_slider_options(){
        wp_enqueue_script( 'theme-slider', get_template_directory_uri() . '/js/theme-slider.js', array( 'jquery' ) );
        wp_enqueue_script( 'theme-slider-init', get_template_directory_uri() . '/js/init.js', array( 'jquery', 'theme-slider' ) );
        // get user options
        $options = array();
        $options['autoplay'] = get_theme_mod( 'slider-autoplay', true );
        $options['navigation_style'] = get_theme_mod( 'nav-style', 'circles' );
        
        wp_localize_script( 'theme-slider-init', 'themeSliderOptions', $options );
    }
    

    In the JavaScript file:

    jQuery( document ).ready( function( $ ){
        $( '.slider' ).fancySlider({
            'autoplay': themeSliderOptions.autoplay,
            'navStyle': themeSliderOptions.navigation_style,
            });
    });
    

    So, let’s share more examples and fill that handbook!

     
    • Frumph 10:27 pm on March 31, 2015 Permalink | Log in to Reply

      There’s a reason for hardcoded stylesheet’s to be placed first (ref: get_stylesheet_uri() – because you cannot specify placement in the enqueue’ing of scripts and CSS is a top down execution order interpreter. Without the ability to properly specify what comes first then you will never know if one thing is going to override the other.

      • Ulrich 7:22 pm on April 1, 2015 Permalink | Log in to Reply

        You can define the order of the scripts by defining the priority in which you run the action.

        This will run before most other styles: add_action( 'wp_enqueue_scripts', 'my_theme_slider_options', 9 );
        This will run after most other styles: add_action( 'wp_enqueue_scripts', 'my_theme_slider_options', 10 );

    • ArnaudBan 7:07 am on April 1, 2015 Permalink | Log in to Reply

      The third parameter of wp_enqueue_style() is a dependencies array :
      “Array of handles of any stylesheet that this stylesheet depends on; stylesheets that must be loaded before this stylesheet. false if there are no dependencies.”

    • Justin Tadlock 5:24 pm on April 1, 2015 Permalink | Log in to Reply

      The “no hard-coding of scripts” is partially incorrect. This is the part we don’t allow:

      <script type="text/javascript" src="<?php echo get_template_directory_uri(); ?>/js/theme-slider.js"></script>

      This is perfectly OK:

      <script>
      jQuery( document ).ready( function( $ ){
          $( '.slider' ).fancySlider({
              'autoplay': true,
              'navStyle': 'circles',
              });
      });
      </script>
      • Jose Castaneda 8:41 am on April 4, 2015 Permalink | Log in to Reply

        True, I was using a super simplified example. There are times when it requires more than, say, 30 lines.

        • Justin Tadlock 7:19 pm on April 5, 2015 Permalink | Log in to Reply

          No problem. I just want to make sure we’re not causing any unnecessary confusion.

          • kevinhaig 10:23 pm on April 14, 2015 Permalink | Log in to Reply

            Why is the top one not allowed and the bottom one allowed?

            • kevinhaig 10:26 pm on April 14, 2015 Permalink

              I thought it also applied to in line scripts (if that is the term)

            • Jose Castaneda 10:28 pm on April 14, 2015 Permalink

              Can remove it via hook.

            • kevinhaig 10:33 pm on April 14, 2015 Permalink

              Yep enqueue’ing is definitely the way to go.
              I know your slider example is just an example but it would make sense to me to enqueue that script as well because it would allow it to be removed if the user wanted a different slider(as an example).

            • Jose Castaneda 10:38 pm on April 14, 2015 Permalink

              it would make sense to me to enqueue that script as well

              And I wholeheartedly would agree with that. There are times when it makes more sense to hard code because it may be faster. A simple example is Twenty Fifteen:

              (function(html){html.className = html.className.replace(/\bno-js\b/,'js')})(document.documentElement);
              
            • Justin Tadlock 3:38 pm on April 15, 2015 Permalink

              The top one is not allowed because you must enqueue all script files via wp_enqueue_script(). This is so that they can be properly deregistered/dequeued or re-registered.

              The bottom one is merely some inline code. It should be hooked to wp_head or wp_footer in most cases. My reply above should’ve mentioned that.

              You wouldn’t want to add that small bit of code to an additional external file and enqueue it. That’d actually slow page load time with an extra HTTP request. It’s far better to just add it.

              What’s not OK with either is just dropping them in header.php.

      • Jami Gibbs 4:45 pm on April 15, 2015 Permalink | Log in to Reply

        Re: No hard-coding of scripts. What about IE conditional JS? For example:

        `

        <script src="/js/html5.js”>

        `

        Although maybe this won’t be an issue for long with work being done on JS IE conditional comments:

        https://core.trac.wordpress.org/ticket/16024

    • Mckilem 7:42 pm on April 8, 2015 Permalink | Log in to Reply

      “Don’t include any plugins. A theme can recommend plugins but not include those plugins in the theme code.”

      Does it mean that I can’t do something like:

      And then use something like “TGM Plugin Activation” to recommend PageNavi?

      • Jose Castaneda 7:48 pm on April 8, 2015 Permalink | Log in to Reply

        Keep in mind this doesn’t really pertain to the topic ( scripts and stylesheets ) but there are other ways of recommending plugins. TGM is an exception but the recommended plugins have to enhance the theme. You wouldn’t recommend a moving truck for grocery shopping, right?

        • Mckilem 8:13 pm on April 8, 2015 Permalink | Log in to Reply

          I know it doesn’t, but wasn’t able to find a topic where my reply would be more appropriate. Well, can I conclude by your answer that I can add pagenavi, since that would enhance the theme (better pagination)?

  • Tammie 7:19 pm on March 30, 2015 Permalink |  

    Weekly meeting agenda

    This week we’ve got our usual weekly meeting. I’d like to talk about mentoring in the meeting. Why it’s important and how can we make it so more of you join us mentoring?

     
    • Aaron Jorbin 4:00 pm on March 31, 2015 Permalink | Log in to Reply

      I think the decision to only require .screen-reader-text if a theme has the accessibility-ready tag should be revisited. [31388] makes the default output of comments_popup_link include this class. As this is now a core outputted class, having it be REQUIRED makes sense to me since we already require a number of WordPress-generated CSS classes be styled.

  • Tammie 6:04 pm on March 26, 2015 Permalink |  

    Theme review team weekly notes

    The logs are here:
    https://wordpress.slack.com/archives/themereview/p1427220029004057

    We talked about when a plugin should or shouldn’t use TGM. It should at least relate to the theme. But as usual, when in doubt cc one of the admins or ask someone in #themereview.

    @grapplerulrich is going to get the recommended tags up in the handbook – woohoo!

    WordCamp London happened and was a great success, join me in saying hi to all the new theme reviewers from the weekend. You are all amazing! I’ve tried to find you all, but if I missed anyone out please shout out in the comments. Looking at the assignment button (some others may get picked up) for Friday a big hello to:
    @carol-hayes, @BinaryMoon, @aloisia, @designituk
    A big thanks to all the existing reviewers that turned up and those that helped mentor the 26+ people in the room.
    @wcorner is going to spearhead a new incentive to make the handbooks English language make more sense. This will be covering all aspects of the handbook. I’m really excited as this means we get someone to review it and improve what we already do!

    If you’ve got a contribution day with theme reviews coming up just let me know and we can make sure to give it a shout out.

     
  • Tammie 3:48 pm on March 24, 2015 Permalink |  

    This week’s meeting will be at 18:00 UTC today. Let us know if you’ve got a topic you’d like covered.

     
    • Maria Antonietta Perna 3:56 pm on March 24, 2015 Permalink | Log in to Reply

      One topic I’ve got a couple of questions about is about the 7 days deadline, but perhaps it’s not suitable for a meeting, just a simple reply by the admins: is the deadline automatically enforced or is the reviewer supposed to close the ticket if it’s gone unanswered for too long by an author by closing the ticket? Do tickets left open for more than 7 days have an impact on queues? Thanks!

      • Tammie 3:57 pm on March 24, 2015 Permalink | Log in to Reply

        Reviewers should never close tickets, but you can notify admins.

        • Maria Antonietta Perna 2:53 pm on March 25, 2015 Permalink | Log in to Reply

          Hi Tammie,
          Thanks for your reply. I guess I can notify you. The ticket number is 23160 and it’s gone unanswered for weeks now. The author must know about the 7-day policy because he/she is not new to submitting themes to the WP.org repo. On the other hand, if the author decides to reply during a time when I won’t be able to follow up on my review, there will likely be one more orphaned ticket for the team, which wouldn’t be all that nice.

        • Arya Prakasa 6:19 pm on March 26, 2015 Permalink | Log in to Reply

          Whoops … I did that twice without notify admins :(

  • Tammie 3:56 pm on March 18, 2015 Permalink |  

    Join me in welcoming new key reviewers

    We all appreciate the great work everyone does with reviews. The admin team would like to today call out a few people specifically and say thanks by making them key reviewers.

    The role of key reviewer is given to people who have shown they consistently do amazing reviews. These are people who have proven over time they can be counted on as always delivering and have been consistent with their contributions.

    From the handbook:
    “People who are key reviewers are allowed to make themes live. These are an important piece to the theme review process, they make sure that the queues are kept low. In addition, you can guarantee they are a great source of reviewing knowledge as long standing reviewers.”

    We’d like to invite the following people to become Key Reviewers:

    Please join me in congratulating and welcoming these brilliant people to their new role.

     
  • Jose Castaneda 5:54 am on March 18, 2015 Permalink |  

    Handbook Examples: Language 

    Another round of examples, shall we? This one will focus on language examples.

    I’ll start it off:

    Required: load_theme_textdomain()

    add_action( 'after_setup_theme', 'my_theme_setup' );
    function my_theme_setup(){
        load_theme_textdomain( 'slug-text-domain', get_template_directory() . '/languages' );
    }
    // if child theme
    add_action( 'after_setup_theme', 'my_child_domain', 11 );
    function my_child_domain(){
        load_child_theme_textdomain( 'child-text-domain', get_stylesheet_directory() . '/languages'
    }
    
     
  • Emil Uzelac 3:43 am on March 18, 2015 Permalink |  

    Mobile-Friendly Themes 

    As some of you already know on April 21st, Google will expand use of mobile-friendliness as a ranking signal. This change will affect all mobile searches worldwide.

    Mobile-Friendly can be a Responsive design, but also an App that turns your theme into a “mobile version”.

    Since we don’t accept themes with mobile Apps because that would fall into a plugin-territory, our choice is Responsive and media queries instead of browser sniffing tools.

    Now, for the mobile-friendliness Responsive media queries will be enough and that is the very basic to be qualified as “mobile-friendly”.

    New algorithm will also take mobile usability into consideration when ranking sites.

    Please test your themes and make sure that we meet and exceed their expectations.

     
  • Ulrich 8:52 pm on March 17, 2015 Permalink |  

    Tracking tickets that need to reassigned 

    Recently we have had a number of tickets that have needed to be reassigned due to different reasons. The problem was is that these tickets are not easily identifiable as the ticket modified date changes once a comment is made in the ticket. I have created a new report so that we can publically track these tickets as a temporary solution till we find a better way. This report will help us to be more fair as the oldest ticket will be reassigned first. The tickets will be added/removed manually by an admin.

    Theme Reviewers: These tickets will be manually reassigned by an admin. Please just ask in Slack to be assigned a ticket.

    Theme Authors: If you are not getting a response from a theme author after 7 days please let us know in Slack and an admin will add your ticket to the report.

    The report can be found here: https://themes.trac.wordpress.org/report/30

    Let me know what you think of this solution. Are there any better ideas how we can track these reviews?

     
  • Tammie 3:18 pm on March 16, 2015 Permalink |  

    Agenda for this week’s meeting

    We’ve got a meeting at 18:00 UTC on Tuesday in Slack #themereview.
    Let us know what you’d like to talk about. So far we have:

    • Increasing the maximum size and requirement for screenshots. This is mainly changing documentation to keep up with what we already do.
    • Mentoring. We’ve briefly talked about it a bit last week, lets go into more depth this week.
     
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