WordPress.org

Ready to get started?Download WordPress

Theme Review Team

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Konstantin Obenland 11:43 pm on February 5, 2015 Permalink |
    Tags: Theme Directory   

    Test the new Theme Directory 

    The new Theme Directory is in its Beta phase and I want to open it up to bug reports form the community. It would be great if you head over to the following URL and give it a spin:

    https://wordpress.org/themesnew/

    If you find anything wonky or out of the ordinary, please feel free to file a ticket over at meta.trac, and assign it to the Theme Directory component.

    Thanks so much for your help!

     
    • Emil Uzelac 11:59 pm on February 5, 2015 Permalink | Log in to Reply

      Awesome job, thanks!

    • Shaped Pixels 12:12 am on February 6, 2015 Permalink | Log in to Reply

      Definitely an improvement from what it is (was). Will there be a “Support” button added when this goes live?

    • jancbeck 12:15 am on February 6, 2015 Permalink | Log in to Reply

      Love it!

    • usability.idealist 12:29 am on February 6, 2015 Permalink | Log in to Reply

      *cough* like the horrible loading time for PNG files, that are each up to 600 kb per file?
      you do known that pngquant and imagemagick ARE real life solutions for that kind of issue, dont ya?

      cu, w0lf.

      • Emil Uzelac 12:35 am on February 6, 2015 Permalink | Log in to Reply

        Loads instantly for me :)

        • usability.idealist 12:56 am on February 6, 2015 Permalink | Log in to Reply

          So, you got a 16+k connection? I don’t. Neither has everybody in the rest of the world (not to forget about mobile connections, too).

          Long loading times for a page ARE BAD. Were bad 10 years ago and are STILL BAD in 2015.

          cu, w0lf.

          • Ipstenu (Mika Epstein) 1:47 am on February 6, 2015 Permalink | Log in to Reply

            Based on speedcheck, I’m on a 100k connection (hey, finally that worked!) so yeah, lots of people on high speed for this will cause problems.

            That said, I think the screenshots being a PNG are at the decision of the theme dev. They are for plugins. You can use either PNG, JPG, or GIFs as you see fit. Not sure if that’s a thing that can be fixed … @obenland ?

          • Emil Uzelac 8:57 pm on February 9, 2015 Permalink | Log in to Reply

            I got super fast connection, that’s probably it ;)

      • Dion Hulse 3:46 am on February 6, 2015 Permalink | Log in to Reply

        Yes, currently we’re loading the same theme thumbnails as we do for the existing directory, the CDN setup we’re using for these screenshots doesn’t currently allow for much configuration. If theme authors were to compress their thumbnails more, it’d certainly help with Theme ZIP total size and the weight of these pages…

        This does mean that the page load is rather heavy for slower connections, but is no worse than the pageload within WordPress itself, and only worse than the old directory in that this loads more than 10 items by default and allows a river, which can quickly increase the MB size of loaded images.

    • Emil Uzelac 12:34 am on February 6, 2015 Permalink | Log in to Reply

      Not out of the ordinary, but something to think about: How about instead of “Downloads Per Day” to say “Daily Downloads” instead.

    • Piet Bos 12:59 am on February 6, 2015 Permalink | Log in to Reply

      Looks like a huge improvement :)

      I filed a little bug that I experienced when attempting to go back after a preview. https://meta.trac.wordpress.org/ticket/843#ticket

    • Ipstenu (Mika Epstein) 1:57 am on February 6, 2015 Permalink | Log in to Reply

      Screen focus ‘jumps’ if your browser is smaller than the screenshot + download button

      https://meta.trac.wordpress.org/ticket/847

    • Jose Castaneda 3:59 am on February 6, 2015 Permalink | Log in to Reply

      Looks good! Great job so far!

    • Aaron Jorbin 4:38 am on February 6, 2015 Permalink | Log in to Reply

      Nice work. I think the fact that this aligning with the theme browser inside core will improve the experience for users.

      One thing that I noticed quickly was that when tab navigating, inside the model none of the links in the right side of the screen are focusable.

      Also, since infinite scroll doesn’t kick in when tab navigating, perhaps at the bottom of the list there should be a link to “load more”?

    • Chandra M 5:55 am on February 6, 2015 Permalink | Log in to Reply

      Great fresh look and much more aligned with .com! Awesome work!

    • Frumph 7:28 am on February 6, 2015 Permalink | Log in to Reply

      This looks really well thought out and pleasing to the eye. Very nice.

    • Thomas from ThemeZee 7:42 am on February 6, 2015 Permalink | Log in to Reply

      The new design is really great and a huge improvement for browsing themes.

      Are there any plans to allow theme developers to add Screenshots, FAQ and Changelog tabs similiar to the plugin directory?

      In my opinion it is great that the theme pages of the new design only display reduced information (description, reviews, stats) about the theme on a single page, that helps to get a first impression about it real quickly.

      However, it would be nice if there were some links to more detailed information. Screenshots to see how the theme handles theme options and a changelog to see what has changed in the recent update for example. As far as I can see the new design is used in addition and includes already hyperlinks back to the old design for Reviews and Support.

      • Konstantin Obenland 6:10 pm on February 6, 2015 Permalink | Log in to Reply

        Are there any plans to allow theme developers to add Screenshots, FAQ and Changelog tabs similiar to the plugin directory?

        There are long-term plans for those features, yes. :)

        it would be nice if there were some links to more detailed information.

        I agree. In the meantime I’d encourage theme authors to use the Theme URI for that.

    • Gary Jones 10:54 am on February 6, 2015 Permalink | Log in to Reply

      Are the filters working (when there are multiple features required)? See https://www.dropbox.com/s/3kc2d0kw34qbhlk/Screenshot%202015-02-06%2010.51.26.png?dl=0 – that’s got three feature filters enabled, which on the current directory gives a total of 20, and not 1686!

    • Gary Jones 11:00 am on February 6, 2015 Permalink | Log in to Reply

      It’s good that opening the modal focuses on the Download button, but when tabbing twice to get to the navigation arrows (top left of the modal), and hitting enter, the focus again jumps back to the Download button, meaning navigating twice involves hitting tab several times again. I suggest not automatically focusing the Download button when the modal was already open.

    • Gary Jones 11:10 am on February 6, 2015 Permalink | Log in to Reply

      Does there need to be better support for when JavaScript is disabled? The /themesnews/commercial page looks and loads fine without JS, but the /themesnew page just has a non-working bar at the top, and then an empty page. I would expect at least the first page of thumbnails (linked to single theme details page) with standard pagination, and *then* if JS is enabled, it can hijack the links with modals, infinite scrolling etc.

      • Konstantin Obenland 6:15 pm on February 6, 2015 Permalink | Log in to Reply

        Does there need to be better support for when JavaScript is disabled

        Yes, and there will be. This is a matter of having themes available that WP_Query can find, currently they’re still not synced over.

        If you inspect the source, there is an API output from the server that we use to test, and it’s hidden by an inline style for now.

    • Sakin Shrestha 3:24 pm on February 6, 2015 Permalink | Log in to Reply

      Looks really nice. Cheers :)

    • Simon Prosser 5:31 pm on February 6, 2015 Permalink | Log in to Reply

      Looks great. Shame to see the bundled themes are still in the most popular list, its like MS bragging that notepad is the most installed text editor, yes it is because you have no choice ;)

    • LittleBigThings 8:45 pm on February 6, 2015 Permalink | Log in to Reply

      Nice, cool WordPress experience… Cheers & thanks! :-)

    • Christine Rondeau 9:29 pm on February 6, 2015 Permalink | Log in to Reply

      Love it. Looks really good.

    • BriniA 10:04 pm on February 6, 2015 Permalink | Log in to Reply

      I like the clean and fresh style. I think the Download button should be always shown not only when the user hovers over a theme. While you scroll to very bottom and it’s loading, it would be great to show a loading animation and maybe a Load more button.

    • S M Hasibul Islam 5:01 am on February 7, 2015 Permalink | Log in to Reply

      Looks really good.

  • Jose Castaneda 7:04 pm on February 3, 2015 Permalink |  

    Theme Review Chat Notes 

    Topic: Custom CSS

    • Discourage usage in favor of plugin
    • If used, must take security, permissions, escaping into account ( ping somebody capable of doing such review )
    • Security is biggest concern
    • Need good examples of _doing_it_right_

    Sub-topic: requirement examples

    • Add items to https://make.wordpress.org/themes/handbook/review/required/explanations-and-examples
    • Encourage commenting but will have a weekly after meeting for examples

    Next Week’s topic: Review Quality

    • Security
    • no-comment-approvals

    Link to meeting in Slack: https://wordpress.slack.com/archives/themereview/p1422986425001223

     
    • Jose Castaneda 7:54 pm on February 3, 2015 Permalink | Log in to Reply

      Addendum to next week’s topic(s):
      Child themes: https://wordpress.slack.com/archives/themereview/p1422990661001394 brought up by @cais

    • Tammie 1:41 am on February 4, 2015 Permalink | Log in to Reply

      Thanks for the update and leading the meeting.

    • Ulrich 7:22 pm on February 4, 2015 Permalink | Log in to Reply

      I am looking into the “Custom CSS” at the moment. Proper sanitization would require the use of CSSTiday? Do we require something for escaping the CSS before output? Ping @greenshady

      Can this be added to the requirements/documentation please?

      • Justin Tadlock 8:17 pm on February 4, 2015 Permalink | Log in to Reply

        I’d really like to see if we can get @nacin and/or @otto42 to weigh in on what’s proper. Or, maybe someone from the Jetpack team who’s worked on this feature. I’m not really in favor of themes doing this, but if we’re allowing it, I’d like to bring in someone I trust to tell us the best method.

        To sanitize, CSSTidy is probably the best place to start. I’d really look into what Jetpack is doing and study their code. If someone could break that down, it’d be nice.

        The correct capability would probably be edit_themes. That seems to make the most sense to me since anyone with that cap can directly edit theme files.

        • George Stephanis 8:50 pm on February 4, 2015 Permalink | Log in to Reply

          Yeah, it’s super tricky to do right and will necessitate a large sanitization library. The Custom CSS code in Jetpack itself is about 600k+ — but that’s including the Sass and Less preprocessors that we bundle. CSSTidy by itself looks to be about 160k.

          Honestly, my recommendation would be to tell themers to suggest an external plugin. Norcross has one as well — https://wordpress.org/plugins/reaktiv-css-builder/ — and there’s a version of the Jetpack one that’s been spun off into its own plugin (yay GPL!) here: https://wordpress.org/plugins/jp-custom-css/ if they don’t want to recommend Jetpack itself.

      • Andrew Nacin 5:22 am on February 5, 2015 Permalink | Log in to Reply

        Despite CSS not being JavaScript, it is just as dangerous. There is no good way to escape arbitrary CSS. There is no good way to sanitize arbitrary CSS. There is no way to do this correctly. A theme should not do this, because libraries can barely do this correctly. They’re patching the CSS sanitization libraries running on WordPress.com all the time.

        This is plugin material, even before weighing all of the additional security concerns.

    • Dovy Paukstys 8:54 pm on February 5, 2015 Permalink | Log in to Reply

      Given the response here, and the query of Justin Tadlock, Redux Framework has integrated the CSS sterilization found in JetPack.

      I’ve also isolated the required code that you could pass to any developers to ensure they comply with these requirements: https://github.com/ReduxFramework/wp-custom-css-validation

      • Dovy Paukstys 9:06 pm on February 5, 2015 Permalink | Log in to Reply

        On a side note, I don’t know why this isn’t just added to WordPress core. It’s only 195kb in all and would be a very useful function. I’ll gladly contribute it if you think it would be accepted. ;)

      • Justin Tadlock 9:11 pm on February 5, 2015 Permalink | Log in to Reply

        @dovyp Thanks for taking the time to flesh out the code in your framework for those theme authors who are using it. That’s definitely a step forward.

    • Kadence Themes 3:18 am on February 6, 2015 Permalink | Log in to Reply

      Hey, I’ll add in, I am for security but strongly disagree that because it’s not easy to do it should be put on plugin developers. I really don’t understand how css needing to be properly sanitized turns into this should only be in plugins? What are the hundreds of themes that have css boxes supposed to do? remove and have all there users lose there css? Come on, we should be promoting safe ways to do this not pushing it off the review team.

      If we are for making sites more secure then themes should be able to lead the way. I took a look around what plugins are available for custom css and it’s not like they are all doing it so well that theme developer should just hand in the towel.

      I could argue all day that I think themes should have the option to add this. But I think that has to be a different point. The point is all css boxes need security and there should be an accepted way to do that. If jetpack has the answer then why can’t we promote the use of jetpack as a plugin or it’s code as a solution?

      • Justin Tadlock 5:44 am on February 6, 2015 Permalink | Log in to Reply

        I am for security but strongly disagree that because it’s not easy to do it should be put on plugin developers. I really don’t understand how css needing to be properly sanitized turns into this should only be in plugins?

        I just want to point out that no one is arguing this at all. The security and plugin territory issues are two separate and unrelated issues.

  • Jose Castaneda 1:47 am on February 3, 2015 Permalink |  

    Tuesday’s weekly chat will focus on Custom CSS at our usual time 1800UTC in #themereview Slack chanel. Justin brought up the subject and a secondary topic will be examples of requirements. Hope to see you there!

     
  • Tammie 9:08 pm on January 27, 2015 Permalink |  

    This week in theme reviews:

    We had a meeting again this week. Here is the archive:
    https://wordpress.slack.com/archives/themereview/p1422381721000231

    Housekeeping:

    Whilst it’s awesome to do reviews. I’m seeing a habit in a few reviewers of just doing the Updates queue. I know people like to do this one as shorter, but we’re not and shouldn’t be chasing numbers. Nothing happens if you clock any number of reviews. There is one queue that is really important and that is the new one. We have over 150 themes waiting to be reviewed that are just (if not more) important than doing 40 updates a week. I appreciate the work anyone is doing, but please spread around what you review and lets crack that new queue here:

    https://themes.trac.wordpress.org/query?priority=new+theme&status=new&priority=previously+reviewed&keywords=!~buddypress&col=id&col=summary&col=status&col=time&col=changetime&col=reporter&report=2&order=time

    Not only are you helping, you will become a better reviewer faster by doing the new themes not just updates. You won’t learn so much focusing only on updates and not be helping as much.

    Main topic:

    Screen Reader text: https://github.com/Otto42/theme-check/pull/42 and https://make.wordpress.org/themes/2015/01/26/supporting-screen-reader-text/

    This really needs more conversation but if you check out the archives you can see some good conversation.

    Next week we’ll talk about Custom CSS and @jcastenada will lead the meeting.

    You can prep here for that talk with some thoughts here:
    https://make.wordpress.org/themes/2015/01/20/theme-review-team-weekly-notes-the-logs-are-7/#comment-40850

     
  • Jose Castaneda 8:28 pm on January 26, 2015 Permalink |  

    If you haven’t already seen it the community hub poll is up; help them out and fill in the poll before it closes on January 29:
    http://wordpressdotorg.polldaddy.com/s/community-hub-voting/

     
  • Tammie 7:21 pm on January 26, 2015 Permalink |  

    Weekly chat agenda

    We’ve got two things to chat about this week at 18:00 UTC tomorrow:

    https://github.com/Otto42/theme-check/pull/42 and https://make.wordpress.org/themes/2015/01/26/supporting-screen-reader-text/

    • @greenshady brought up to : Custom CSS theme options.

    https://make.wordpress.org/themes/2015/01/20/theme-review-team-weekly-notes-the-logs-are-7/#comment-40850

    After that we’ll have an open floor.

     
  • Konstantin Obenland 5:48 am on January 26, 2015 Permalink |
    Tags:   

    Supporting Screen Reader Text 

    Six years ago, r11312-core introduced .screen-reader-text as a canonical class name for text targeted to screen readers for all of core. Not only for wp-admin, but also for the front-end through get_search_form(). Up until now, it was not part of the list of core classes that every theme is required to support, but that will change soon.

    Not only does core already use it to identify content on the front-end to be visually hidden, but the Accessibility team also needs to be able to rely on the existence of this class to improve the screen reader experience outside of wp-admin.

    The change should not be too drastic, given that the class has been around for years, a lot of the new HTML5 features also use it, and many modern themes support it already. Twenty Eleven and Twenty Twelve, the only default themes without complete support, were recently retrofitted with class and style definitions as well.

    If you’re a theme author, this would be a great time to review your themes and update them with styles for .screen-reader-text, to ensure forward compatibility! As a reference, the Codex was updated with example styles that will make your theme fit for a more accessible future.

     
    • Jose Castaneda 6:37 am on January 26, 2015 Permalink | Log in to Reply

      That’s awesome news! Thank @obenland for posting this. :)

    • Volker E. 7:07 am on January 26, 2015 Permalink | Log in to Reply

      Great to see a push towards a11y in custom themes! Keep up the good work.

    • Gary Jones 1:50 pm on January 26, 2015 Permalink | Log in to Reply

      For reference: https://core.trac.wordpress.org/ticket/29699

      Moving forwards, this is great, but it leaves a big backwards-incompatibility hole that hasn’t been addressed:

      > the Accessibility team also needs to be able to rely on the existence of this class to improve the screen reader experience outside of wp-admin

      That’s the hole.

      That single use of the class in the front-end is in a function that can be, and has been, legitimately filtered by themes outside of core (i.e. they aren’t using it) and is therefore missing in the style sheets of potentially millions of sites created in the last six years. Twenty Twelve is a little over two years old, and yet that didn’t have complete support for it, even “given that the class has been around for years”. Twenty Eleven is three and a half years old, and that didn’t have any support for that class name.

      It’s now being used in the new pagination functions in 4.1, and that’s awesome, but using it to retrofit accessibility into existing front-end outputs will cause sites to visually change, just from having a WP core update.

      The referenced ticket suggests a way that site owners can use to opt-in to these visual changes on their site. It’s a single line of code that any theme tweaker can copy and paste in. As well as core, it would also let plugin authors confidently add accessibility enhancements without breaking sites, however small the difference. Not supporting that is a missed opportunity for improving accessibility across the community.

    • Joe Dolson 5:12 pm on January 26, 2015 Permalink | Log in to Reply

      Thanks Konstantin! That’s great.

    • Rian Rietveld 6:59 pm on January 26, 2015 Permalink | Log in to Reply

      I think it’s a good idea, forcing/education theme developers to add the screen-reader-text to their theme, since the option of an add_support was rejected. Otherwise it will never happen.

    • Joe Dolson 8:11 pm on January 26, 2015 Permalink | Log in to Reply

      I have no issue with potentially breaking existing web sites. The changes will be quite minor – but this opens the door for us to make critical future changes. We need to be able to have that flexibility.

      Technically, the accessibility team doesn’t need the class to exist in order to improve accessibility. It needs to exist so that the accessibility improvements we implement have minimal impact on the front-end of sites – what we change will improve accessibility whether the end user or developer implements the class or not.

      A couple of comments to note – first, it appears that the ‘clip’ property has been deprecated. The replacement for it (clip-path) doesn’t have enough browser support to be usable yet, but we should probably have a note of some kind to indicate that.

      Second, I don’t think that the codex example should include :hover and :active styling – :hover in specific can result in some pretty weird behavior, so I think it would be best to focus only on the :focus styles.

    • Aaron Jorbin 8:18 pm on February 9, 2015 Permalink | Log in to Reply

      As of [31388] core now uses .screen-reader-text in text that is output in themes using the default strings in comments_popup_link . The accessibility team has put together a post on hiding text for screen readers that includes sample code to use in your themes.

  • Tammie 11:43 am on January 21, 2015 Permalink |  

    Explaining and giving examples to requirements

    We’ve got a new handbook page now to start collection some examples and further explanations for required items. It’s been brought up a lot that some could do with having extra information. So, now we have a page right here: https://make.wordpress.org/themes/handbook/review/required/explanations-and-examples/.

    This may be a temporary page as we can look to bring in things to the main required page. If we keep this, we do need to link between the two documents. A decision on having these two or merging hasn’t been made yet, this is just about starting to expand and be clearer.

    Next week’s meeting will focus on adding to this section. Please bring ideas and content for things that can be brought into this section and really help make our requirements clear.

    A little note, we don’t want to call people out in our examples. We all have to learn. If you are going to use a code example use one that doesn’t tie to a theme on the repo. Examples from the theme developer handbook or https://developer.wordpress.org/ are ok to use and link back to.

     
  • Tammie 6:52 pm on January 20, 2015 Permalink |  

    Theme review team weekly notes

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

    We are not going to be putting the handbook on Github. We are going to use the workflows already in place and used by other teams. However, so we can keep the handbook fresh and check in with it, we are going to cover a new section each week for a few months. This will also enable in the weekly meeting people to get more familiar and discuss it.

    We will also have a page up for suggestions. People can then add their thoughts to that for changes and updates. This should help us collate ideas.
    https://make.wordpress.org/themes/handbook-suggestions/

    From now on, at the end of each weekly meeting we will also give time every week for change requests and updates. This gives us all a chance to highlight issues, areas of weakness and areas that can be improved. Bring your best ideas and suggestions.

     
    • Emil Uzelac 2:20 am on January 21, 2015 Permalink | Log in to Reply

      Thanks Tammie :)

      I am glad that we are not going with the GitHub for the handbook.

      Great meeting, short and to the point!

    • Ulrich 12:32 am on January 25, 2015 Permalink | Log in to Reply

      We should talk about this in the next meeting https://github.com/Otto42/theme-check/pull/42

    • Justin Tadlock 6:15 pm on January 25, 2015 Permalink | Log in to Reply

      Next meeting item of discussion: Custom CSS theme options.

      This has come up in a few recent tickets. Themes are allowing end users to enter arbitrary custom CSS via a textarea in their theme options. It might be time to consider putting this under the “plugin territory” category. There are 3 major issues I see:

      • Handling permissions (using the correct capability).
      • Sanitizing before saving to database.
      • Handling the output.

      There may be cases where this makes sense in a theme, but for general purposes, I’d say we need to leave this to plugin authors with the skillset to make this safe and work correctly. It should be up for discussion anyway.

      Some relevant links:

      • usability.idealist 8:41 pm on January 26, 2015 Permalink | Log in to Reply

        A note on this: These are regular issues with ANY kind of option, most of which are already dealt with (using the Settings API).

        So the actual ONLY issue is a missing CSS sanitizer (the only existing one is used for INLINE css, which might be found inside tags of regular posts, but certainly not stand-alone fields).

        I’ve been dealing with this the last few days. One option is using the current version of CSSTidy, which might be a bit of overkill, but then, it’s only being used inside the admin section of your theme, so it shouldn’t too much harm.

        Example approach: http://wordpress.stackexchange.com/questions/53970/sanitize-user-entered-css/165496#165496
        Current (!) version of CSSTidy: https://github.com/Cerdic/CSSTidy

        The second one is my current approach: Stripping out anything that is NOT CSS. So, nasty stuff like dropping JS code into it, etc. is already being avoided.

        Third option would be writing your very own, which I tried, but abadoned pretty soon.

        cu, w0lf.

        • Justin Tadlock 10:11 pm on January 26, 2015 Permalink | Log in to Reply

          Permissions, sanitizing, and escaping are definitely issues with any kind of option. However, CSS blocks present their own issues, as I’m sure you’re aware. Using CSSTidy or a custom script might be a good solution, but this is code that one of the reviewers on the review team will have to review for any theme using it. Not many have the necessary skills to review such code.

          There’s also the issue of whether such a setting belongs in a theme at all. I’m sure we’ll cover these points tomorrow in the meeting.

    • smartcat 4:28 pm on January 27, 2015 Permalink | Log in to Reply

      Is there a process outlined in theme review regarding how long a reviewer has to review a theme ? reason I ask is because I have a theme that was assigned to a reviewer who has been idle for a month and I fear that it will just sit there permanently https://themes.trac.wordpress.org/ticket/21699

    • Tammie 4:29 pm on January 27, 2015 Permalink | Log in to Reply

      @smartcat, they should respond within 7 days. We triage all tickets each week as best we can by hand. You can always bring up a ticket in Slack at #themereview. That’s a better place than on our update lists if you want to get eyeballs on it.

  • Tammie 8:51 pm on January 19, 2015 Permalink |  

    This week we’ve got a chat again at 18:00 UTC on Tuesday in #themereview. There is no set topic, so add a comment or bring your topics to the chat.

     
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