WordPress.org

Ready to get started?Download WordPress

Theme Review Team

Updates from Lance Willett Toggle Comment Threads | Keyboard Shortcuts

  • Lance Willett 4:37 pm on November 10, 2013 Permalink
    Tags: , , reviews   

    Guidelines Shouldn’t Fail a Theme 

    Chip’s great post on Points of Emphasis and a recent discussion about a specific Theme Unit Test guideline (failing themes with long titles that overflow) point to a need to change our attitudes to the theme review guidelines.

    If you step away from that specific Trac ticket and look at the bigger picture you’ll see a change is needed to make all WP theme reviews less dogmatic and more pragmatic; not only WP.org directory but also for WP.com, ThemeForest, MOJO, any other marketplace that accepts some submissions and rejects others.

    The items in the Theme Unit Test are guidelines not hard and fast rules. Highly recommended and encouraged and we should feature and love and promote the themes that nail them all. Shout from the mountaintops if a themer manages to achieve the full list! Themes that don’t nail them all can sink to the bottom of the list organically because people might end up not liking them as much.

    Guidelines shouldn’t cause a theme to fail or be prevented from being in the directory. That should be limited to blockers like licensing, security, and spam/malware. What Chip said.

    By letting theme designers choose to implement guidelines in full—or not—you give the power to end users to vote for the best ones by activating them. Instead of keeping out hundreds or thousands of potentially amazing themes that fail the too-strict rules we have now. The themes—and the people behind them—that we lose out on might never come back; and there’s evidence this has happened many times already.

    Changing a strict philosophy of enforcing guidelines as rules to encouraging more experimentation and variety will go a long way to remove negative friction from reviews and make the themes in the collection better in the long run.

    In summary: let’s enforce the “Points of Emphasis” (security, license, no spam) and leave the rest as recommended guidelines. We absolutely love if you follow them all, but none are blockers to your theme being included in the directory.

     
    • PankajAgarwal 4:44 pm on November 10, 2013 Permalink

      You have taken a very right decision, I am completely agree with all your point..

    • Samuel Wood (Otto) 4:46 pm on November 10, 2013 Permalink

      I’m going to have to disagree with you here, Lance. The purpose of the review process is to improve the quality of the themes in the directory in general. As Matt once said, the themes directory should contain the best themes, it doesn’t need to contain all themes.

      Most of the guidelines listed are indeed blockers, because they specifically are there to address perceived breakages. When a theme wants to make a design decision to have certain colors or layouts or what have you, that’s obviously not something to be questioned. But when it doesn’t want to include next post links or widget support, then that’s where the interface of WordPress itself gets broken by something the theme is doing.

      The specific issue in question for Twenty Fourteen is the title overflow problem. And while I agree with your response in that ticket that it is an issue with the unit test, I disagree that it is not a problem in the theme itself as well. While the question of how to handle overflow properly is indeed up for debate, what I don’t see as up for debate is the fact that not handling it at all is a poor decision that leads to a broken theme. Yes, it’s an edge case, but it’s a case that should be properly handled. If the proper handling is to say “we want to allow overflow to happen”, then that’s fine, but that needs to be explained properly instead of being shrugged off.

      So no, I have to disagree with you and say that the theme reviewers should continue to strive for a minimum level of quality and to continue to raise the bar and improve the quality of themes in the directory as a whole. And if a theme doesn’t adequately address issues like these, or have meaningful responses to back up why they think that these are design decisions, then yes, they should be not-approved and not allowed in the directory.

    • Chip Bennett 4:52 pm on November 10, 2013 Permalink

      I could buy into this approach for the Theme Unit Test Data, but everything else in this list is required for good reason.

      • Lance Willett 4:59 pm on November 10, 2013 Permalink

        Yes, this is for the guidelines in the Theme Unit Test.

        That said—I think most themers would agree with me, and “would-be” themers especially, that other list could stand to be much shorter. It’s scary long and intimidating.

      • Lance Willett 5:02 pm on November 10, 2013 Permalink

        • Chip Bennett 5:09 pm on November 10, 2013 Permalink

          Yes, and complaining on Twitter is quite helpful. The Theme Review Team is comprised of almost 100 volunteers of varying level of Theme development expertise and review experience. Of course it’s not possible for all reviews to be conducted with 100% consistency – though we certainly strive for that, and try to address all meaningful inconsistencies as we are made aware of them.

          The remedy for an inconsistent or incorrect review is to respond in-ticket and work through any issues directly with the reviewer – and if that doesn’t work, to post to the mail-list and ask for an admin to intervene.

          Sadly, random tweets aren’t something that the TRT admins are able to monitor; so Tweeting about issues really doesn’t solve anything.

          • Lance Willett 5:12 pm on November 10, 2013 Permalink

            It’s still valid. No matter what the communication channel, it’s a human being and a voice that should be heard. (Yes, we can also ask Andy Peatling if his Dad wrote up a long-form treatise on his negative intro to WPTRT and WP themeing.)

            • Chip Bennett 5:18 pm on November 10, 2013 Permalink

              With all due respect: “totally broken” is not valid. Since the approximate date of that post, 330 Theme developers managed to navigate the review/approval process for new Themes.

              Is the process perfect? Of course not. It is nearly impossible for the process ever to be perfect. Those who want to help improve the process can avail themselves of one of the many communication channels to provide constructive criticism of the process. (That happens quite frequently, and generates a lot of beneficial discussion, and improvements.)

              Those who just want to rant, and not make any effort to bring issues to our attention so that we can address them? Ain’t nobody got time for that.

    • Edward Caissie 5:02 pm on November 10, 2013 Permalink

      This is definitely a double-edged sword of a discussion whereas I agree with Otto on his points, I can also see validity in the points Lance is bringing about for discussion.

      I, as a Theme Review Team administrator, do not agree with all of the guidelines currently in place (more specifically one that is unfortunately much too long standing) and to be honest it was quite a labored decision whether or not I would continue to have the theme hosted in the repository. (It may be a small item but one I think to be very important.)

      I took my opinion to the appropriate venue for discussion and the majority insisted the guideline was a required restriction on what I consider more an author’s choice and as such the theme remains in the repository but I struggle with this decision for the theme to remain in the repository every time I review it for updates and re-submission … forcing me to use a Child-Theme on my own site(s) because the theme’s native form does not suit my opinion of what the it is meant to display (a content related presentation aspect) and accomplish.

    • StyledThemes 5:25 pm on November 10, 2013 Permalink

      I can understand the need for standards in WordPress coding methods are important, as well, ensuring that most (not necessarily all) of the important features and functions of WordPress becomes part of a theme.

      However, I agree that the review test is extensive and can be intimidating for the new themer. In fact, I almost didn’t go through with submitting my first theme because when I saw the list, I was like wow! Granted, for me it wasn’t as bad as it might be for some others because I came from the Joomla platform and standards are important and I was already used to the idea that it’s going to take more time to put something together for WordPress.

      I totally agree that submitted themes need a review process to ensure proper coding standards are in place that relate to how WordPress works, ensuring that the core basic features of WordPress are part of the theme for continuity regardless of the theme being activated for a user. Perhaps some minor tweaking is needed, but I think for the most part it does help for quality code standards.

      The only one big issue I have is that the review process seems to focus too much on the review list of guidelines and looks away blindly when it comes to the visual design of the theme. When I look at the list of themes in the repository, it’s kind of shameful to see so many themes that look so basic and plain, yet all look the same. I strongly believe that themes submitted should have overall design and creativity included in the review process….almost a 50/50 split of coding quality as well as design. The repository is filled with (I’m really sorry to say this) themes that look like they were designed by people who have absolutely no creative design abilities, and it’s filling up the repository with themes that should not be there.

      A friend of mine found an online tool that can search the net for sites that uses themes. What he found out was scary and might prove some points that the majority of the themes are not being used. Sure they get downloaded a lot but on average, only 3-5% are being used on sites with select themes.

      What I would like to see is more emphasis on visual design and features, and I bet the WordPress repository would be seen a place for serious website and business owners to explore and download professional looking themes. Something to compete with the likes of Theme Forest, Mojo, etc.

      • tskk 5:29 pm on November 10, 2013 Permalink

        What is beautiful is extremely subjective and giving importance will only end up in trouble.
        Can i have the link to this tool you are talking about?

      • Chip Bennett 5:32 pm on November 10, 2013 Permalink

        What I would like to see is more emphasis on visual design and features, and I bet the WordPress repository would be seen a place for serious website and business owners to explore and download professional looking themes. Something to compete with the likes of Theme Forest, Mojo, etc.

        I completely understand where you’re coming from, but it’s not something that’s practical. Design/aesthetics are completely subjective, and it is difficult enough to get conformance to objective guidelines – and to ensure that all reviews against those objective guidelines are consistent.

        I think any design/aesthetic considerations would have to be a second level of curation, over and above the quality guidelines that Themes must pass in order to be hosted in the Theme directory. I’d be fully in favor of such second-level curation, but we don’t really have the tools or infrastructure in place to make that happen.

        • StyledThemes 6:09 pm on November 10, 2013 Permalink

          I understand what you are saying Chip…it really would end up having the requirement of a second level, but then it becomes who would be qualified to do just that, would require unbiased individuals having a design background. Changing something or adding something of this level at this point in time definitely would be a huge undertaking, but not impossible. It would be something in a sense where the design review process happens as a 1st level and if passes, then it goes to level 2 for code reviewing.

          For the record though, with the current review process, the one thing that stands out above sites such as Theme Forest, Mojo, etc., is that the review team takes the time to go through your theme code and often finds things that were missed. But they also continue to provide possible solutions and point out where the issues are, and I believe that is a huge bonus when being reviewed. I still encounter and shown things I missed, but that definitely helps make me more aware with each theme I submit.

          • alex27 7:47 am on November 11, 2013 Permalink

            I also wanted to talk a little about the design quality. It’s true that ultimately users decide on the themes that they like best, but with the amount of poorly designed themes out there it’s just too difficult and too time consuming for the average user to find them. I have a very hard time convincing people that it’s worth the effort and why they should not discard official theme repo out of hand .

    • tskk 5:34 pm on November 10, 2013 Permalink

      All rules in http://make.wordpress.org/themes/guidelines/ have reasons and are easy to follow.
      There are other rules we point out during reviews, wish they are added to the above list so there is less friction during reviews.

      • Chip Bennett 5:41 pm on November 10, 2013 Permalink

        That’s actually intentional. The top-level Guidelines page is intended to be a one-page synopsis of the Guidelines. The sub-pages are used to add any needed clarification/elaboration.

        If there’s anything not covered on the sub-pages, please let me know and we’ll be sure to address it.

    • rclilly 6:46 pm on November 10, 2013 Permalink

      Lance, while I agree that we need to remain aware that theme developers are humans, and that reducing friction in the review process is highly desirable, it doesn’t appear that the current guidelines present too big of a barrier to entry. The theme reposistory should be a sacred place where only themes that meet the guidelines should be allowed entry. We need to be able to trust, without subjective voting up or down, or having to do research, that any given theme in the repo has conformed to a clearly established set of guidelines and it’s presence in the repository is justified.

      Rather than lower the barrier to entry, I believe it’s in everyone’s best interests, including aspiring theme developers, to have to learn what’s required to get a theme approved and then do that. If help is needed to meet one or more guidelines then education is in order, not a dismissal of the guidelines.

    • alex27 7:20 pm on November 10, 2013 Permalink

      While I agree that guidelines may by intimidating to new themers, I don’t think that’s a bad thing. If nothing else, it shows good practices and gives something to strive for, puts a (moderately) high bar. For me undergoing the process of theme review was and still is a great learning experience, and I’m happy when I someone points issues with my themes to me. And theme repo is all the better for it.

    • nofearinc 8:04 pm on November 10, 2013 Permalink

      I tend to avoid conflicts and long discussions as much as possible, but occasionally I’m happy that we have those conversations in public.

      If we focus on the specifics, I completely disagree that this is an edge case for two reasons. First, I have sites that have long titles and take care of medical/bio latin terms, eCommerce stores with some long ID numbers of products etc. Especially for responsive themes where the content area is with a variable width. Not to mention that it’s in the guidelines, which we already mentioned.

      The tricky part though is that I fully agree on the fact that the reviewing process is too tight and people have different views on how this should work. We could see some examples in the comments above by Otto, Chip, Lance and Cais. My statement is a mix of the ones above, or rather – I believe that part of the guidelines are irrelevant, such as “Page With Comments Disabled” or “Clearing Floats” from the test data where I personally see too much regulations and specific cases, and there are too many definitions with “sufficient” and other subjective words that the most pedantic reviewers use to close themes. Part of them lead to annoyed theme authors leaving the repository for good or starting long discussions in the tickets or the mailing list.

      All groups related to the Foundation are actively trying to get people on board, encourage contributors in all aspects and actively update and enhance regulations to make that possible. Restricting authors for tiny subjective details or hundreds of guidelines is not quite constructive from my perspective, as I would agree with Lance here that the basics (spam, security etc) should be the REQUIRED and everything else is “should be taken care of in the next updates” or something.

      As for the “edge cases” which are the current official topic, my personal goal is to allow for people to get all the best options in the open source world. That means – Linux stack, WordPress website, themes and plugins from the official directories, etc. We teach WordPress to students, charities, even foster children where the line between $0 and $1 is infinite. Everyone could get premium themes/plugins and tools/services later, but it’s important to provide working and reliable products for students and newbie users (and starting developers from countries with economical issues). So far getting a free theme on a site, using it for 2 years and ending with a title breaking the UI on a popular blog of a non-technical user is embarrassing and disappointing, especially by the very official theme.

      The last thing I usually mention every few months is that WordPress is already considered a CMS and people already try to utilize it as an application platform, whilst we still try to enforce dozens and dozens of blogging-related regulations. There is no way in the current theme directory to list/apply with business/CMS themes (as there is for BuddyPress ones) and let developers focus on real business websites rather than blogs with optional templates for business sites.

      • tskk 8:37 pm on November 10, 2013 Permalink

        Just as the issue of long title is important to you, page with comments disabled is important for someone else :)

    • Emil Uzelac 9:26 pm on November 10, 2013 Permalink

      Not to mention that lowering the standards will bring less work for reviewers and more for WPORG support. Process isn’t perfect but it works :)

    • Japh 10:11 pm on November 10, 2013 Permalink

      Interesting post, Lance. It’s certainly important to be sure we question the status quo from time to time.

      I agree that there need to be occasional exceptions to the rules, but I also think that generally the rules need to be there. On ThemeForest, our WordPress Theme Submission Requirements are just that, requirements. We deliberately didn’t call them “guidelines”, because while there may be the occasional exception, by and large we need them to be met to help ensure a certain level of quality and compatibility.

      We’ll also be updating them shortly based on some of the feedback we’ve had, which is also an important part of the process.

      Quality and compatibility with the rest of the ecosystem are some of the primary drivers for keeping this level of checking in place, and I don’t think those are acceptable casualties in the pursuit of a more frictionless process.

      • Japh 5:14 am on November 11, 2013 Permalink

        I should also clarify that I think ThemeForest, and other commercial theme providers, are a poor example for this. If money has been exchanged, there’s a different level of expectation.

    • Andy Peatling 2:36 am on November 11, 2013 Permalink

      Great post Lance. I think your post and comments here highlight some fundamental differences of opinion when it comes to the vision of the theme directory.

      My recent experience was a dramatic shift from a few years prior, and resulted in my frustrated tweet linked in the comment above. Here’s how it came about:

      I remember being so excited and energized from releasing my first WordPress theme. I was instantly bitten by the bug. It was the catalyst for my obsession with WordPress and everything I have worked on since. My first theme was poor, but I learnt a ton from all of the feedback, it made me a better designer and WordPress developer.

      I have been teaching my dad programming and WordPress over the past year. I knew having him build and release a theme would provide the same boost and energy needed for him to become as obsessed with WordPress as I am.

      It was tough work from day one.

      I taught him the absolute basics for a functioning WordPress theme. He made sure all base functionality worked correctly, I gave it a double check, we uploaded it.

      Instant fail.

      We were presented with a laundry list of small problems that needed to be addressed before he could even upload the zip file. For someone starting out with WordPress this was incredibly off-putting. He admitted he would have given up there if I hadn’t have stepped him though it. There were a few things we missed that did need to be fixed, but most of the items on the list I would have considered minor issues and nothing that stopped the theme from functioning at a respectable level.

      We fixed issues, re-uploaded, and failed the test a few more times. Zipping up on a mac and the auto-testing script do not play well. Finally we got the zip uploaded. We were into the review process.

      Over the course of four reviews we interacted with three different people. Each person re-reviewed the theme and came up with a whole list of new things that needed fixing each time. I cannot highlight enough of how infuriating and demoralizing this is. It is an absolute momentum killer and sucks the life out of the person who is new and trying to learn. Without me my Dad would never have made it through these steps, which is a terrible shame because all of the items in the review were not blockers and could have been updated later (more on the updated later bit in a sec).

      After a week or so of frustrating back and forth we finally got the theme in the directory. At this point I thought all was lost for being bitten by the WordPress bug. The opposite was actually true, my Dad’s theme was downloaded more than a thousand times in the first three days. He could not have been more excited and couldn’t believe that thousands of people were using something he had built. Now he loves WordPress and has come on leaps and bounds since.

      So despite the pain of going through all of the steps, he still eventually experienced the same rush I did all those years earlier. If I had not been there showing him how to fix all the minor issues, he would never have made it here, and almost certainly would not be working with WordPress still (he may even have given up on the dream of being a web guy entirely).

      Having said that, he has not updated the theme since. I just asked him why. He said — “I have no enthusiasm to go through that process again, it’s too demoralizing”. I think that speaks volumes.

      • Andy Peatling 2:43 am on November 11, 2013 Permalink

        Based on the experience with my dad it’s clear to me that the current process is turning off potential new WordPress designers and developers that need that early encouragement to keep persisting with the platform.

        For me, encouraging new designers and developers into the WordPress community should be one of the primary goals of the repository. Allow new theme developers to feel the rush and excitement of people using something they have built as soon as possible. There is nothing else like it.

        Yes there will be a lot of junk, but as Lance said put the power in the hands of the end-users. The cream will rise to the top and new folks won’t be put off.

        • Justin Tadlock 5:11 am on November 11, 2013 Permalink

          I’m right there with you, Andy. I’ve talked with numerous theme authors who are or have been in the same boat as your dad.

          I’ve got about a 2,000-word essay on this subject. I’ve just been trying to narrow it down to the essentials and decide whether I even want to post it at all.

          • Lance Willett 4:11 pm on November 11, 2013 Permalink

            Please post it, Justin—everyone’s voice needs to be heard. Especially if they aren’t well known or new to the community.

        • alex27 9:57 am on November 11, 2013 Permalink

          I don’t think that cream will rise to the top, unfortunately. As it is, it’s very hard to find good (visually and code wise) themes and from my experience – people just don’t bother. The reason too much junk/very basic/generic themes.

        • Chip Bennett 1:39 pm on November 11, 2013 Permalink

          I don’t think the Theme Directory – at least in its current form – is the best or appropriate place for that. I agree that the project needs a way to encourage new developers to make contributions, but that encouragement shouldn’t come at the expense of end user experience with Themes installed from their dashboard – Themes that have the implied endorsement of WordPress itself.

          Just as I would like to see some second-level curation for beautifully designed Themes, perhaps we need some sort of “step below” repository to fill this need as well: somewhere to encourage/facilitate new developers to contribute their work to the project – somewhere that isn’t integrated into end users’ dashboards. Because while I agree that it is laudable and desirable to encourage such contributions, the Themes that WordPress core offers to end users should be of the utmost code quality.

          It’s not a good experience for end users to install Themes from their own dashboard – again, Themes with the implied endorsement of WordPress core – that then adversely impact their experience with core, or that interfere with their installed Plugins. It is frustrating for end users, reflects poorly on WordPress itself, and creates needless support issues for core, Plugin, and Theme developers.

          Ultimately, encouraging new designers and developers into the WordPress community is a laudable goal, but the primary goal of the Theme Directory must be to enhance and facilitate a great end-user experience. Any other goals will necessarily be subordinate to meeting end users’ needs.

      • tskk 3:05 am on November 11, 2013 Permalink

        Update process is not as rigorous as initial process.
        Even the initial process now is not same as a few months back, as now reviewers get rewarded and are eager to help new themes in. Now all the power is with theme authors. Now only reason for theme to not get in is that theme authors are either lazy or stubborn.
        Link to your dad’s theme please, let see it :)

        • Justin Tadlock 5:22 am on November 11, 2013 Permalink

          Now only reason for theme to not get in is that theme authors are either lazy or stubborn.

          That’s not entirely true and is the type of attitude that has been and continues to be detrimental to the theme review community.

          There are some major philosophical differences in viewpoints between not just theme authors and reviewers but between the various reviewers on our team.

          I’ve got numerous theme design/dev ideas that I know wouldn’t get through the review process. Either that or I’d have to spend multiple days arguing in the theme reviewers mailing list to make people less familiar with the WordPress code base understand. So, I simply don’t bring them up and stick to some of the one-size-fits-all rules we have.

          That has absolutely nothing to do with being lazy or stubborn.

          • alex27 7:14 am on November 11, 2013 Permalink

            Maybe it’s time to bring everyone on theme review team up to speed about general philosophy, any guidelines are secondary to that.
            I think you should upload your more creative themes – the attitude among reviewers has changed a lot lately, so it might not be as difficult process as you think. It would also help if theme authors described their ideas and out-of-the-box design/dev decisions upfront in the ticket (theme descriptions tend to be a bit ambiguous in that regard), not only after reviewer comes back with a bunch of issues.

          • nofearinc 10:03 am on November 11, 2013 Permalink

            I’ve even seen cases where reviewers (not admins) step onto tickets of other reviewers, adding additional subjective details to be verified. From the outside it looks like there is a superior level of reviewers who supervise and monitor the others, it demotivates regular reviewers as well.

            • Justin Tadlock 10:29 am on November 11, 2013 Permalink

              I’m guessing this is directed at me since you replied to my post. Or, maybe you meant to reply to someone else??

              We’ve always held that in-ticket replies are the appropriate way to handle things rather than taking discussion to the mailing list first.

            • nofearinc 10:54 am on November 11, 2013 Permalink

              Yep, that’s an addition to your comment about:

              I’ve got numerous theme design/dev ideas that I know wouldn’t get through the review process. Either that or I’d have to spend multiple days arguing in the theme reviewers mailing list to make people less familiar with the WordPress code base understand. So, I simply don’t bring them up

              And I’m not talking about in-ticket replies, but a review after another review for subjective details that are under consideration.

            • Justin Tadlock 11:30 am on November 11, 2013 Permalink

              Sorry, I don’t follow.

            • nofearinc 12:11 pm on November 11, 2013 Permalink

              I’m saying that not only is the theme review process long and thorough, but a second reviewer could chime in and add more things to be fixed. Demotivating for the author and the first reviewer, and most of that could be subjective and not necessary.

            • Chip Bennett 2:00 pm on November 11, 2013 Permalink

              Demotivating for the author and the first reviewer, and most of that could be subjective and not necessary.

              …and this is why I could buy into a change in philosophy, with respect specifically to the Theme Unit Tests, in which the Theme Unit Tests are treated as *recommended* rather than *required* – since the level of subjectivity in the Theme Unit Tests is definitely higher than the level of subjectivity in the rest of the Guidelines.

              There are other opportunities to make some of the code quality guidelines more explicit, but at some point, we needlessly restrict coding-practice decisions. Theme options handling is one example. (This is also the reason that personally I don’t push for the official WordPress Coding Standards to be incorporated into the Guidelines, as much as I see that as the ideal.)

            • nofearinc 2:11 pm on November 11, 2013 Permalink

              Chip, are you willing to start a long (and probably painful) thread on the guidelines and the test data? I would personally love to see more specifics that would reduce the subjectivity, and probably some official (like in the Codex) prioritization of everything.

              If I have to guess, there are about 10-20 blockers for a theme, around 100 recommended issues and 100+ “nice to have” things. If you see any future in that sort of separation with some regulations about how many “recommended” things are acceptable, that would be great – and definitely progressive after the awesome theme review incentive program that revolutionized the queue processing drastically.

              Another thing that would help is some internal regulation for reviewers. If people take over someone else’s review, there is something wrong. And there are no guidelines for that, who is to blame or what would be the correct flow to reduce the tension and simplify the process (at least IMO).

            • Chip Bennett 2:55 pm on November 11, 2013 Permalink

              Chip, are you willing to start a long (and probably painful) thread on the guidelines and the test data? …If I have to guess, there are about 10-20 blockers for a theme, around 100 recommended issues and 100+ “nice to have” things.

              I’m not sure if that depth of discussion/debate would be beneficial. It might be better to take a broad brush, and say either the Theme Unit Test criteria are all required or else all recommended. In all honesty: if the code review is thorough enough, the Theme Unit Tests almost become an afterthought. If I’m doing a full review, my time is spent 95% in code review, Theme-Check, and install error-checking; and 5% on the front end/Theme Unit Tests. If 805 of review subjectivity comes from 5% of the review process, perhaps the most effective way to deal with that 80% is simply to reduce the criticality of the Theme Unit Tests as a whole.

          • Lance Willett 5:53 pm on November 11, 2013 Permalink

            @chipbennett

            perhaps the most effective way to deal with that 80% is simply to reduce the criticality of the Theme Unit Tests as a whole.

            Yes, please—that’s the whole point of my post. Can we make it happen by updating the Review page and the review team philosophy to make them not required?

            • Chip Bennett 6:13 pm on November 11, 2013 Permalink

              Discussing this among the admins currently, likely to be followed by specific community discussion.

        • Chip Bennett 1:52 pm on November 11, 2013 Permalink

          Now all the power is with theme authors. Now only reason for theme to not get in is that theme authors are either lazy or stubborn.

          I don’t agree. While the process is orders of magnitude better, I’ll never pretend that we’re perfect. Different reviewers bring different personalities, different languages, different levels of review experience, different levels of code expertise, different levels of design/aesthetic expertise, and even different interpretations of the Guidelines. The end result can still be frustrating for developers.

          The Theme Review Team is as big as it is, because it needs to be. Theme review takes more than the half-dozen active people that we used to have in order to be done properly and to keep up with the influx of submitted Themes. But all of those Reviewers come with vastly different experience levels. The only way for Reviewers to improve is to let them conduct reviews, and then educate them through the review process. That’s why I spend almost all of my time now auditing reviews instead of doing my own reviews.

          I think it’s important that we as reviewers take the same approach with the developers who have submitted Themes: they’re new to the review/approval process as well. As reviewers, it is our job to help them through that process, with the end goal of seeing their Theme approved and listed in the Theme Directory. That paradigm shift has been one of the biggest improvements to our efforts, and is bearing fruit. I see far more comments along the lines of “wow, the Theme reviewer was really helpful, and I really learned a lot getting my Theme reviewed and approved”, where before, most comments exemplified the frustration inherent in Andy’s aforementioned Tweet.

      • Frank Klein 9:52 am on November 11, 2013 Permalink

        First of all I’m sorry about the negative experience that your dad had, Andy. I respect everybody that learns a new skill and that puts his creations out there for everybody to see.

        But I cannot agree with your approach to the review process. As you said yourself, you did your first theme a few years ago and it was bad.

        This is exactly why the WPTRT has been created: to bring the quality of themes WP.org to an acceptable standard. And I consider that the team has been very successful at it.

        The WordPress.org repository is there to provide users with great, free to use themes. It’s not there to provide new designers or developers with a fuzzy feel good feeling.

        Of course this can be off putting for newcomers, but lowering the standards just so that sub standard themes make the cut is not a good solution. Moving the goal posts only masks the problem, it doesn’t solve it.

        If you want to see what a low barrier of entry brings you to, then check the Plugin section of the website. I don’t want themes to become the new plugins.

        For me the question is: how can we make sure that developers have enough resources to learn about theme development best practices and about the theme review process in general so that we can avoid such frustrating experiences with the first review?

      • Frank Klein 9:53 am on November 11, 2013 Permalink

        First of all I’m sorry about the negative experience that your dad had, Andy. I respect everybody that learns a new skill and that puts his creations out there for everybody to see.

        But I cannot agree with your approach to the review process. As you said yourself, you did your first theme a few years ago and it was bad.

        This is exactly why the WPTRT has been created: to bring the quality of themes WP.org to an acceptable standard. And I consider that the team has been very successful at it.

        The WordPress.org repository is there to provide users with great, free to use themes. It’s not there to provide new designers or developers with a fuzzy feel good feeling.

        Of course this can be off putting for newcomers, but lowering the standards just so that sub standard themes make the cut is not a good solution. Moving the goal posts only masks the problem, it doesn’t solve it.

        If you want to see what a low barrier of entry brings you to, then check the Plugin section of the website. I don’t want themes to become the new plugins.

        For me the question is: how can we make sure that developers have enough resources to learn about theme development best practices and about the theme review process in general so that we can avoid such frustrating experiences with the first review?

        • Andy Peatling 6:29 pm on November 11, 2013 Permalink

          But I cannot agree with your approach to the review process. As you said yourself, you did your first theme a few years ago and it was bad.

          This is exactly why the WPTRT has been created: to bring the quality of themes WP.org to an acceptable standard. And I consider that the team has been very successful at it.

          That is the difference right there though. He didn’t hack this theme together with no knowledge. I taught him the right way to build a theme, starting with the basics. We used the theme check plugin and everything worked great. Surely that should be enough to get a theme accepted with little issue (assuming no security, spam etc issues)?

      • Chip Bennett 1:27 pm on November 11, 2013 Permalink

        I taught him the absolute basics for a functioning WordPress theme. He made sure all base functionality worked correctly, I gave it a double check, we uploaded it.

        In all honesty, this would have been my same experience had I attempted to upload the first iteration of my own, personal-use Theme. I didn’t know what I didn’t know about Theme code quality. I was self-taught, having ported my old 2005-ish Blogger Theme to WordPress when I made that jump, based only on poking through the Codex to hack my way through template tags.

        I enjoyed the process, and learned a lot. But would that Theme have been an appropriate level of code quality to distribute via the official Theme directory? Certainly not. That principle is embodied in a philosophy espoused by Matt, who has said that we’re not looking for all Themes for the directory, but rather the best. And as tightly as the official Theme directory is integrated into end users’ WordPress admin, that’s exactly as it should be.

        So, I can empathize with your father; I’ve been through the same learning curve – and I wouldn’t change that for anything.

        We were presented with a laundry list of small problems that needed to be addressed before he could even upload the zip file. For someone starting out with WordPress this was incredibly off-putting. He admitted he would have given up there if I hadn’t have stepped him though it.

        Were you or your father aware that the Theme Review Team maintains a Plugin – Theme Check – that can be used during development and prior to Theme submission, and will output all of the same warning/required/recommended/info comments, in greater detail? If you weren’t aware of that Plugin, is there a way that we can better communicate its existence to aspiring Theme developers?

        There were a few things we missed that did need to be fixed, but most of the items on the list I would have considered minor issues and nothing that stopped the theme from functioning at a respectable level.

        Again, we’re not aiming for “functioning at a respectable level”; we’re aiming for Themes that are well- and tightly-integrated with WordPress core, and that inter-operate well with Plugins, to provide the best-possible end-user experience.

        Over the course of four reviews we interacted with three different people. Each person re-reviewed the theme and came up with a whole list of new things that needed fixing each time. I cannot highlight enough of how infuriating and demoralizing this is. It is an absolute momentum killer and sucks the life out of the person who is new and trying to learn.

        This was a known problem, and one that we’ve directly addressed – ironically, around the time of your aforementioned Tweet. We (thanks to Otto and Nacin) implemented some needed infrastructural changes that allowed us to keep reviews for a given Theme in a single ticket instead of generating a new ticket for each Theme revision in an on-going review. We also implemented a procedural change that placed more focus on reviewers working with developers to ensure that a submitted Theme eventually becomes an approved Theme.

        The old process really didn’t work the way we needed it to. The focus was on closing tickets instead of on approving Themes. We’ve fixed that, and it’s working much better now.

        Without me my Dad would never have made it through these steps, which is a terrible shame because all of the items in the review were not blockers and could have been updated later (more on the updated later bit in a sec).

        Ensuring that the reviews performed by over 100 volunteer reviewers will be a never-ending effort. It is one of the primary reasons that we keep the Guidelines as straight-forward, explicit, and objective as possible: to try to eliminate as much subjectivity as possible. And even then, some reviewers still interpret some of the Guidelines differently. It’s our job as admins continually to try to educate reviewers, and work toward more-consistent reviews. Having a process that is largely under control now has freed us up to put more time and effort into ensuring review consistency.

        And we’ll keep working on that. All I can ask is for some patience and understanding that Theme Review Team efforts come entirely from volunteers – across a wide spectrum of experience levels – who are merely attempting to make their own contributions to the WordPress project.

        If I had not been there showing him how to fix all the minor issues, he would never have made it here, and almost certainly would not be working with WordPress still (he may even have given up on the dream of being a web guy entirely).

        Having said that, he has not updated the theme since. I just asked him why. He said — “I have no enthusiasm to go through that process again, it’s too demoralizing”. I think that speaks volumes.

        Please encourage him to submit an update. Perhaps it would give you both a chance to see how the process and system have improved – and/or an opportunity to provide the team with more constructive feedback.

        • Andy Peatling 6:39 pm on November 11, 2013 Permalink

          Thanks for taking the time to give feedback Chip.

          In all honesty, this would have been my same experience had I attempted to upload the first iteration of my own, personal-use Theme. I didn’t know what I didn’t know about Theme code quality. I was self-taught, having ported my old 2005-ish Blogger Theme to WordPress when I made that jump, based only on poking through the Codex to hack my way through template tags.

          I enjoyed the process, and learned a lot. But would that Theme have been an appropriate level of code quality to distribute via the official Theme directory? Certainly not.

          The difference is that the theme was not hacked together and was certainly better quality than my first theme. It followed all the general best practices. It wasn’t a hacked together theme.

          Were you or your father aware that the Theme Review Team maintains a Plugin – Theme Check – that can be used during development and prior to Theme submission, and will output all of the same warning/required/recommended/info comments, in greater detail? If you weren’t aware of that Plugin, is there a way that we can better communicate its existence to aspiring Theme developers?

          We used this plugin, everything worked great and checked out before we started the directory upload process.

          Again, we’re not aiming for “functioning at a respectable level”; we’re aiming for Themes that are well- and tightly-integrated with WordPress core, and that inter-operate well with Plugins, to provide the best-possible end-user experience.

          And I think that is the source of the difference of opinion here. I think that is a good goal to aim for, however I don’t feel it should be at the expense of new folks being able to experience their theme being downloaded early on.

          I feel like there must be a solution that allows someone new to the community more approachable access to the directory, while still maintaining the accessibility of great themes to end users?

          The old process really didn’t work the way we needed it to. The focus was on closing tickets instead of on approving Themes. We’ve fixed that, and it’s working much better now.

          That is great to hear, continuity of reviewer would have helped a ton in my Dad’s situation.

          And we’ll keep working on that. All I can ask is for some patience and understanding that Theme Review Team efforts come entirely from volunteers – across a wide spectrum of experience levels – who are merely attempting to make their own contributions to the WordPress project.

          Definitely, I completely understand that. None of this is a stab at the volunteers, more a questioning of the process itself. I think there are ways that can take more weight off the shoulders of volunteers.

          Please encourage him to submit an update. Perhaps it would give you both a chance to see how the process and system have improved – and/or an opportunity to provide the team with more constructive feedback.

          I’ll ask him again and let him know the process has changed. :)

          • Samuel Wood (Otto) 7:09 pm on December 3, 2013 Permalink

            We used this plugin, everything worked great and checked out before we started the directory upload process.

            For reference, when I wrote Theme Check, I did it with the specific goal in mind of having the exact same code run on the upload process as in the plugin itself. While initially there were a few minor differences there, those are almost completely gone (I think there’s only two or three left).

            What runs in Theme Check is the exact same set of checks that runs on the WordPress.org theme uploader. Same code. Maybe it is not as up-to-date all the time, since I have to update it manually, but if you pass Theme Check, then you *will* pass the uploader.

    • Jen Mylo 5:03 pm on November 11, 2013 Permalink

      To that end, I would love to see something in the theme directory about what is/isn’t guaranteed for the themes we host on .org. It’s an unending source of FUD for users what they can expect/rely on us making sure of for them with the review process for the .org directory.

      • Chip Bennett 5:27 pm on November 11, 2013 Permalink

        I’m sure we can make that happen. Can you provide any specifics regarding the FUD, so we know what to address?

        • Emil Uzelac 8:36 pm on November 11, 2013 Permalink

          Warranty and Liability comes in mind, the basics :)

    • Ian Stewart 5:44 pm on November 11, 2013 Permalink

      Would I give up on theming if I started today and was uploading my first theme to the official directory? I’m not sure. I’m pretty persistent but if it can be a pain for professional WordPress developers I imagine that it can’t be too great for new folks.

      It’d be interesting to see some stats. How many themes are uploaded once but never have tickets made eventually? We won’t know what those looked like but it’d be interesting to do a visual review of screenshots from themes that had one ticket but never went live. (A bunch would be spam, sure.) My hunch — like Andy’s — is that we lose out on a lot of really great WordPress themes and amazing community members at this point.

      +1 to things like making the Theme Unit Tests a recommended item rather than a required one. My guess is that 80% of users of all themes won’t be bothered by a lot of them and that most themes that fail them will fail the “preview” stage. Who doesn’t look at the preview/demo? Let that decide. The good stuff will rise to the top. Even then a lot of great themes will still be useable. I don’t think I’ve ever seen a custom-made one-off theme that passed the Theme Unit test. And I bet they’re used by happy publishers and read by happy readers who would never notice some of the small things on there.

      Also, I’m sure no one but the most theme-obsessed people know about Theme Check. :) The upload page could maybe have a short checklist. Something like this:

      Whoa there, pardner! Before you upload your theme:

      1. Run a Theme Check
      2. Review the guidelines
      3. Run the Theme Unit Test (optional)
      4. Eat a healthy sandwich

      • nofearinc 5:47 pm on November 11, 2013 Permalink

        I might be wrong, but Theme-Check is running on every upload automatically, no?

        • Ian Stewart 5:54 pm on November 11, 2013 Permalink

          The idea is to encourage users to run it themselves first — for a better experience. As noted above …

          We were presented with a laundry list of small problems that needed to be addressed before he could even upload the zip file. For someone starting out with WordPress this was incredibly off-putting. He admitted he would have given up there if I hadn’t have stepped him though it.

          Were you or your father aware that the Theme Review Team maintains a Plugin – Theme Check – that can be used during development and prior to Theme submission, and will output all of the same warning/required/recommended/info comments, in greater detail? If you weren’t aware of that Plugin, is there a way that we can better communicate its existence to aspiring Theme developers?

          I think the better way to communicate this would be on the Theme Upload page as the first item in a short checklist. (That, yes, should include something funny like “Whoa, pardner” and “Eat a sandwich” — working with WordPress should be fun and not a chore.) Working with Theme Check before you package theme code with your hopes and dreams in a ZIP archive is better than uploading and finding out you’re a failure.

        • Chip Bennett 6:13 pm on November 11, 2013 Permalink

          Yes, they’re the same warning/required checks in the uploader as in Theme Check.

      • Chip Bennett 6:15 pm on November 11, 2013 Permalink

        @Otto42 can you make something like this happen on the Theme Uploader page?

        • Samuel Wood (Otto) 10:19 pm on November 11, 2013 Permalink

          We can add any form of wording or text you want to the uploader page. Just come up with what you want it to look like and get everybody to agree or iterate on it a bit.

          Make a meta ticket for it too once you have something we can put on there.

    • Drew Strojny 2:48 am on November 12, 2013 Permalink

      I’d like to echo some of the sentiment already posted by a few folks on here. Like Andy, Ian, Justin, and others, I got started with WordPress themes way back in the dark ages. I decided to try my hand and building a theme. After a month or so I submitted it to the repository and was accepted! I’m sure the code was terrible, but I was nonetheless really excited to see my theme getting downloaded and used across the web.

      This experience really stoked my proverbial fire when it came to building more themes and making my first theme better. As a few years passed, we went on to actually grow a business around WordPress themes. If I had been rejected that first time, who knows what would have happened. I may have just given up and moved on to something else, or maybe I would have stuck with it, and the world would have had a better theme.

      I do know that we stopped submitting to the directory when the new review guidelines went into place. Chip and I have actually talked about this in depth, and I don’t blame the theme reviewers at all. They’re just following the rules and doing their job.

      Why did we stop? For me personally, the process stopped being fun. It was demoralizing and incredibly frustrating. I just simply didn’t agree with the review philosophy. Call me stubborn, but I felt strongly that some requirements weren’t in the best interest of our users. Eventually, I just stopped caring. We were more focused on premium themes at that point, so we just let our existing themes rot on the vine. Since then, we haven’t submitted an update or a new theme in years.

      Ironically enough, we’re now thinking about diving back into the fray, and we’d really like to get some more free themes into the directory. It’s how we started, and I’d love to continue giving back to the community (and getting some marketing) through the WordPress.org repository. I’m hopeful that the process has improved, and I look forward to seeing how things unfold when we move ahead with it.

      I think both sides are seeing this from different angles:

      The “stick to the guidelines” group sees this as a way to improve the WordPress ecosystem and the average user experience. Better theme guidelines lead to better themes, and better experiences for WordPress users.

      The “stop being so strict” group sees this as a choke point for developer interest and growth. After all, if we constantly slam the door in the face of new WordPress theme developers, we slowly starve innovation from the inside out.

      I think both of these come from the right place. Both groups care deeply about WordPress and WordPress themes. I don’t know what the right answer is, but I really do believe (from personal experience) that too much dogma from the gatekeepers about what’s right and wrong for a WordPress theme discourages innovation.

    • Bryan Petty 7:43 am on November 13, 2013 Permalink

      “too much dogma from the gatekeepers about what’s right and wrong for a WordPress theme discourages innovation” — this is basically where my thoughts land, except I would replace “innovation” with “participation” entirely.

      This is one aspect of WP.org that obviously is not run like an open source project normally would (just look at the heated debate going on here). Being a community project, I wholeheartedly agree with Lance on “security, license, no spam” just for gate-keeping purposes only. Why is it such a problem to let the community as a whole decide whether the the item is junk? It’s not like there isn’t a rating and review system in place. It would make submissions quicker and easier to process, and give the TRT more time to work on more constructive and productive projects (like improving the theme repo search, filters, additional tools, and better UI for finding the best themes in the repo – and yes, filtering out the poorly rated ones too).

      It’s quite possible that a theme designer is new to all of this, and really actually just needs some good, quality criticism from the community. Of course their theme is missing critical components and functionality, it’s their first theme. But if they can’t even get it accepted on WP.org for quick and easy installation for family, friends, colleagues, and the community here to install and review, we’ve failed. The TRT doesn’t have the time to help theme designers properly fix every issue they find, and we shouldn’t be expecting some level of perfection from everyone immediately up front.

      Besides, the best way WordPress can recruit more theme reviewers from the community is to actually let the themes be reviewed directly on the theme repository rather than requiring manual theme installation directly from Trac before themes have even been vetted for security. Get them past that first crucial step, then open it up for the community in the most convenient way possible.

      • Chip Bennett 12:47 pm on November 13, 2013 Permalink

        This is one aspect of WP.org that obviously is not run like an open source project normally would (just look at the heated debate going on here).

        Actually, I would counter that the Theme Review Team sets the example among WordPress community-contributor groups with respect to openness. I don’t think you’ll find discussion like this taking place many other places.

        hy is it such a problem to let the community as a whole decide whether the the item is junk? It’s not like there isn’t a rating and review system in place.

        Because, not to put too fine a point on it: the WPORG review and ratings system is broken and doesn’t work, and is entirely insufficient to replace what we accomplish through the current Theme Review Guidelines.

        …and give the TRT more time to work on more constructive and productive projects (like improving the theme repo search, filters, additional tools, and better UI for finding the best themes in the repo – and yes, filtering out the poorly rated ones too).

        The Theme Review Team has zero control over any of those things.

        The TRT doesn’t have the time to help theme designers properly fix every issue they find, and we shouldn’t be expecting some level of perfection from everyone immediately up front.

        I disagree. WordPress end users who find and install Themes directly from their Admin Dashboards – Themes that come with the implied endorsement of WordPress itself – deserve to have those Themes be as well-coded as absolutely possible, to ensure that those Themes don’t interfere with core, interfere with their installed Plugins, or lock them in to a given Theme.

        If the solution to providing a means of encouraging and facilitating new developers to contribute Themes to the project is a second repository of some sort, then that’s something that people above our pay grade can decide and implement. I’m sure we’d support such an effort wholeheartedly. But I am adamantly against anything that would adversely impact the average end user installing Themes from the official Theme directory.

        As Matt says: we’re not looking for *all* Themes; we’re looking for the *best* Themes.

        Besides, the best way WordPress can recruit more theme reviewers from the community is to actually let the themes be reviewed directly on the theme repository rather than requiring manual theme installation directly from Trac before themes have even been vetted for security.

        The most critical security vetting takes place before initial upload, and Themes are verified at the code/file level in Trac before ever being installed locally for review. As for community review: again, the current WPORG rating/review system is broken, and not reliable for any meaningful vetting or replacement for what the Theme Review Team currently does.

    • Ryan Hellyer 10:19 am on November 13, 2013 Permalink

      I think that themes which don’t make the cut should still be allowed in the repository, they just shouldn’t be actively promoted.

      • Zulfikar Nore 1:55 pm on November 13, 2013 Permalink

        In my experience the themes that do not make the cut are the ones that are poorly coded – i.e. they either break something, interfere with core or they are a security hazard.

        Promoted or not those themes just don’t make the cut full stop – they are not fit for the purpose and should never be included in the repository.

        Yes, where the above is not the issue then lets have a more relaxed approach while still maintaining some quality control and keeping end user satisfaction at the forefront.

      • Lance Willett 4:14 pm on November 13, 2013 Permalink

        Yes, I agree (in terms of Theme Unit Test passing).

    • StyledThemes 10:23 pm on November 16, 2013 Permalink

      Wow, this was a long read, lol. Anyway, I went for coffee and started to think more about what Lance brought up of good points, but judging from the ongoing discussion, it appears there is more to just simply submitting a theme and going through the unit test and review.

      I still believe the lack of focus on design quality is part of the whole picture because it seems as though it’s all about the code. Code is important, don’t get me wrong, but that is only 50% of any theme, where the other 50% is design. We seem to forget (or ignore) that people who come to check out, download, and use the themes are not coders and they don’t care or even think about it…they just want the theme to work, but they are also visual, which means they want a theme that also looks awesome and has great features.

      …Downloads are high on many but actual usage is extremely low…I’m going to guess less than 10% average.

      Anyway, this is probably a whole another topic I’m sure, but I’m starting to think about writing up an idea of how to greatly improve on the many facets with my own ideas of how themes are provided to the WordPress user out there. Call it an observation with possible solutions in the eyes of a Designer/Developer/End-User of WordPress.

      To be honest, I see a HUGE potential for the themes repository at wordpress.org and I just might consider giving a lot more of my time to help out more than just simply designing and submitting themes….That’s saying a lot from someone who comes from 6+ years working the Joomla! platform, and now committing to WordPress, lol.

  • Lance Willett 11:48 pm on February 18, 2013 Permalink
    Tags: , , twentythirteen   

    Twenty Thirteen Draft Now in Core 

    Hi theme reviewers,

    Twenty Thirteen is ready for feedback and testing in core: http://make.wordpress.org/core/2013/02/18/introducing-twenty-thirteen/

    Our goal is to have it ready along with the rest of 3.6 for an April launch. Would love your eyes on it for testing, performance, tying in with core features, all that good stuff.

    Also noting several theme-related core tickets, if anyone wants to jump in with comments, patches, and testing:

    We’ll have open office hours Tue/Thu throughout the cycle (see http://make.wordpress.org/core/ sidebar for times), so hope to talk with you soon.

     
    • Emil Uzelac 11:50 pm on February 18, 2013 Permalink

      Will do for sure and Twenty Thirteen looks mighty fine :)

      Emil

    • @mercime 1:06 am on February 19, 2013 Permalink

      Congratulations @matt @lancewillett @obenland @joen and team.

    • Daniel 6:53 am on February 19, 2013 Permalink

      Can we please add the ticket about styling the post comment button?

    • Sallie Goetsch 11:55 pm on February 19, 2013 Permalink

      I like the typography (except the menu font, which is microscopic–PLEASE bear in mind that not everyone using WP is under 25) and the color. It’s pretty and fun. Can’t imagine using the theme in a million years, though, because the sites I build aren’t blogs and do need to be customized to the user. Where does the theme customizer fit in with something that has such distinctive colors?

      I’m also wondering how to fit Twenty Thirteen into my intro WordPress class for May, because I’m not at all sure it will suit my students half as well as either Twenty Eleven or Twenty Twelve.

      • Lance Willett 3:15 am on February 20, 2013 Permalink

        I wish I were 25. :)

        Could you share a screenshot of tiny menu font size? That sounds like a bug.

    • Nathan Reynolds 6:11 am on February 20, 2013 Permalink

      I am wondering if there is a reason that when I post under the link or quote format the .entry-content is empty so it’s just showing the post-meta.

      I am using the built in boxes for URL in link, and quote/source in quote. I just test to see if the post body will show up and it does, just none of the other boxes I filled out.

      • Lance Willett 4:07 pm on February 20, 2013 Permalink

        Hi Nathan, are you using trunk 3.6 bleeding edge? That code is brand new, and doesn’t work with Twenty Thirteen yet.

    • bjornsennbrink 7:40 am on February 25, 2013 Permalink

      Remove hyphens from body.

    • shadow_catcher 2:35 am on December 10, 2013 Permalink

      I second Bjornsennbrink – at least give everyone the option of hyphenating text.

      I can’t begin to tell you how much I HATE the illiterate look of the way WP hyphenates.

  • Lance Willett 6:16 pm on November 29, 2012 Permalink | Log in to leave a Comment
    Tags: data, theme-unit-test, xml   

    Chip brought up a good point on the http://codex.wordpress.org/Theme_Unit_Test named XML file — it always looks out of date because of the naming.

    I renamed it to theme-unit-test-data.xml to avoid that confusion.

    It gets updated fairly frequently, probably once a month to fix 404s and add new test data, so when that happens I’ll update the text on the Codex page to the current date and time to reflect that.

    It’s fresh today from the latest export of http://wpthemetestdata.wordpress.com/ — including a quick cleanup to remove unneeded wp:postmeta nodes for values of (_edit_last|superawesome|geo_public|jabber_published|email_notification)

     
  • Lance Willett 10:38 pm on September 18, 2012 Permalink | Log in to leave a Comment
    Tags: , history, kubrick,   

    Why Default Themes Change Each Year 

    Since Twenty Twelve is coming very soon to the Extend directory, I wanted to share a bit of background on default themes and why they change from year to year.

    In 2005 Kubrick launched as the new default theme, then didn’t change for five years. It became a punchline for the project. With Twenty Ten a new pattern started, with every single year having a new theme, naming it by the year. Twenty ___. This gives the theme an expiration date and it doesn’t have the pressure to be the end-all theme for the ages, because it’ll be replaced in the next year rather than in five years.

    In the time between Kubrick and Twenty Ten the default theme efforts didn’t work too well as there were too many conflicting things. The efforts tried to please everyone: show off everything that’s possible in core, fully educational in every aspect, super nice-looking, and try to solve all the problems a theme can solve.

    Big shoes to fill, as it turns out. Even if one theme can’t do it all, though, the default theme can still strive to be as simple as possible while still sticking to important principles. For example, default themes are coded to be fully internationalized and ready for translation. Even though this effort makes the code more complicated, it’s an important principle in an increasingly globalized world where many people don’t interact with WordPress in English.

    The default theme should show off the latest and greatest features, be flexible enough to gracefully support child themes and encourage customization, work well for a blog or a website, and sport a design that is aesthetically pleasing and a bit different from the last design. Under the hood it should represent the best in coding practices and technical excellence. That said, the default theme isn’t trying to be an end-all-be-all theme. It won’t please everyone.

    To get an idea of how Twenty Twelve is intended to differ from its predecessors, here’s the the core team’s post on which key features they want to see implemented: Core Team Meetup Recap: Default Theme “Twenty Twelve”. Note things like the header image off by default, promoting a static front page, and no featured image in the header. A new look by a different theme designer.

    I think a lot of people are going to really like Twenty Twelve. And Twenty Thirteen. And Fourteen. And … you get the idea.

     
    • Emil Uzelac 10:42 pm on September 18, 2012 Permalink | Log in to Reply

      Good stuff Lance!

    • Brent Leavitt 3:55 am on September 19, 2012 Permalink | Log in to Reply

      Thank you for taking to time to walk though this. I appreciate the shift to promote the static page as a home page. I’ve been using WordPress as a full blown CMS for custom website builds. That’s one of the basic switches i do with every theme that I setup. Does this theme set the static page option by default?

    • Noumaan Yaqoob 9:56 am on September 19, 2012 Permalink | Log in to Reply

      I loved 2011 and it is one of my most favorite WordPress themes of all time. Not just because it is visually pleasent with good typography and easy readibility, but mainly because it is so easy to customize and build child themes upon it. I believe that the default themes are the perfect way to learn WordPress theme development. Can’t wait for 2012, which I think is a bit late, its already september when it will be released?

    • Kim Parsell 10:08 am on September 19, 2012 Permalink | Log in to Reply

      Really looking forward to working with Twenty Twelve. :)

    • jaredatch 8:20 pm on September 19, 2012 Permalink | Log in to Reply

      Well said Lance. You guys have been doing a great job.

      • Lance Willett 10:04 pm on September 20, 2012 Permalink | Log in to Reply

        Thanks Jared—it’s been amazing to see it come together, many hands — especially at WCSF hack day; I was blown away at the contributions and couldn’t keep up with them, heh.

    • kathy@lasvegasinfocenter.com 9:26 am on September 25, 2012 Permalink | Log in to Reply

      Very informative, Thank you. It is difficult to find a theme that will do everything the web author envisions. But it must be even more difficult to try and accommodate everyone with a default theme.

    • Bachsau 7:01 pm on September 29, 2012 Permalink | Log in to Reply

      For non technical users, a huge problem arises when updates to one of the default themes are released (twentyten, twentyeleven, twentytwelve). People without FTP access and knowledge are stuck a with an english frontend even on localized versions of WordPress. Please include the locals in themes packages, so autoupdate of themes work correctly.

    • Freddy K. 4:27 pm on October 2, 2012 Permalink | Log in to Reply

      Would like to see a working menu in IE8, it only shows a “Menu” button on top and then a list of all menu-entries of the complete menu. As my menus have about 30-40 items, this is not usable on desktop.

      • Lance Willett 9:32 pm on October 29, 2012 Permalink | Log in to Reply

        You can follow along with the theme’s development and improvements over on Trac. We’ve addressed this (and many more fixes) recently.

    • LatestBlogPostsCom 12:59 am on October 20, 2012 Permalink | Log in to Reply

      Hey Lance, good article on default themes. Twenty Twelve seems to have it all for the basic WordPress user, but I like learning about all the hooks and template tags to take the basics of Twenty Twelve and twist it into something totally or even slightly different, while using it as a starting point. I do that on AssortedProducts.com.

      Also, Twenty Twelve was the one entity about anything related to web design that got me into HTML 5!

      Bruce

    • richardpd 12:27 pm on February 23, 2013 Permalink | Log in to Reply

      Hi Lance
      Interesting post. It is a tall order to showcase all new WordPress features in a new theme every year. I personally though would prefer the default theme design to stay the same for a longer period e.g. 5 years and have the new code within that year on year. Kubrick was and still is a classic WordPress theme and did a great job for 5 years. 2010 was a great change of direction but to change design every year for 2011/12/13 etc is a bit too frequent for me. I think WordPress should design a classic flagship theme that can stand the test of time for a 5 year period & that can showcase the new code year on year. I think theme design is more of a personal issue in comparison to code dependent theme function and there are benefits to keeping these seperate elements. Mais, chaque un a sans gout! Tres bonne…Best wishes

  • Lance Willett 11:59 pm on August 24, 2012 Permalink | Log in to leave a Comment
    Tags: ,   

    Hi everyone. Are you ready for a new default theme? I am. And, now it’s almost ready.

    I submitted a .9 release of Twenty Twelve today—see http://themes.trac.wordpress.org/ticket/9199. Theme Check had a few warnings, I noted the reasoning for those in the Trac ticket notes.

    If you have some time this weekend could you go through it? We’ve been cranking on it in core a ton and now it’s time for spit and polish, tightening up documentation, and making sure we covered all the bases.

    Note for themes Trac moderators: This theme should not be pushed live after it’s approved, per instructions from the core development team.

     
    • mercime 12:10 am on August 25, 2012 Permalink | Log in to Reply

      So we should be testing Twenty Twelve on WP 3.4.1 and/or WP 3.5 trunk?

    • Japh 2:17 am on August 25, 2012 Permalink | Log in to Reply

      Brilliant, Lance! Very much looking forward to this new theme :)

    • Chantal Coolsma 7:29 am on August 27, 2012 Permalink | Log in to Reply

      I love it. Already found an issue.

    • Lance Willett 2:55 pm on August 28, 2012 Permalink | Log in to Reply

      Has everyone had a chance to take a look and test?

      Today we’re pushing the theme live on WordPress.com and in the announcement it’d be nice to be able to link to Extend for any self-hosted folks who want to try it out before 3.5 officially comes out.

    • Lance Willett 3:25 pm on August 28, 2012 Permalink | Log in to Reply

      Update: after discussion with Nacin and Matt some more here’s the game plan for releasing to WP.org Extend, soon-ish (say 2-3 weeks).

      1. WPTRT continues to review it and test it, then an admin there approves the theme without pushing it live so it has gone through a round of theme review. Keeping it version .9 as we find bugs and fix them.
      2. Come up with a RC version, say .9.x — Lance will keep submitting to Themes Trac with new test candidates
      3. Nacin will handle letting the core contributor group know, via http://make.wordpress.org/core/ site that we’d like to do a formal launch very soon
      4. Then dot the “i”s and cross the “t”s and make sure it is ready for a final WP.org release.

      At that point we’ll submit a new ZIP with the 1.0 final and that one can be pushed live for everyone, with a possible announcement on WP.org news blog at that point (exact details TBD on how to announce).

  • Lance Willett 6:47 pm on July 18, 2012 Permalink | Log in to leave a Comment
    Tags: , tags   

    I’d love your thoughts on adding two new tags to allowed theme tags: see http://core.trac.wordpress.org/ticket/21065.

     
    • Amy Hendrix (sabreuse) 6:54 pm on July 18, 2012 Permalink | Log in to Reply

      +1 to both. There’s some ongoing discussion about what the review standards should be for responsive themes, but I see that as a separate issue to the question of having a tag — tags are about the fact that end users want to search for certain features, and responsive design isn’t a concept that’s going away any time soon. And flexible headers is an easy win.

    • Nicholas Weaver 7:25 pm on July 18, 2012 Permalink | Log in to Reply

      I think this is a great idea, not only because its a feature on WordPress.com already but because I often want to change the size dimensions (height more so then width) in twenty ten and twenty eleven as I use those themes for almost everything I do with WordPress.

      Adding the ‘flexible-header’ tag & allowing 3.4 compatible themes the ability to use the custom header feature is a must as far as I am concerned.

      Adding the ‘responsive-width’ tag isn’t a bad idea. I think as people’s expectations of themes, to be responsive, increases, this will be a patch you will have to make down the road, if you decide against it now. Definitely a step in the right direction.

      I appreciate you reaching out to me for my thoughts and I’d love to help out more in whatever way I can!

      side note: :) I apologize for the lack of Weekly Theme Shows as of late, we are really trying to get the right fit and structure down for the show to make it worthwhile to everyone who listens.

      • Amy Hendrix (sabreuse) 7:30 pm on July 18, 2012 Permalink | Log in to Reply

        Note that the features are up for grabs and any theme developer to use, and flex headers in particular are already in both Twenty Ten and Twenty Eleven — the question here is about adding the tags to the filtered search so users can specifically search for themes that include them.

        • Nicholas Weaver 7:36 pm on July 18, 2012 Permalink | Log in to Reply

          Ah, gotcha. Yeah i read trough that track ticket a little to quickly.

          Themes with those abilities are something I actively look for when dealing with clients, hence the heavy usage of twenty ten and twenty eleven. Being able to do a filtered search for themes with these features would be extremely beneficial, save time, and help to better qualify themes for selection/download, in my opinion.

    • Emil Uzelac 9:28 pm on July 18, 2012 Permalink | Log in to Reply

      There’s no doubt that this isn’t needed, both are definitive (yay).

      To check if Theme is using RWD and how much of that’s true will take as much as time as the standard review. No point really going there, unless there are some obvious issues.

      RWD is not just the layout, it’s everything else around it, such as images, videos, typography etc.

      If an author says that their design is layout super, we can take their word for it. If it’s not it will be classified as false “advertisement” (Theme Description).

      Emil

    • Konstantin Kovshenin 8:30 am on July 19, 2012 Permalink | Log in to Reply

      I like both feature tags, though I wouldn’t use “responsive-width” for several reasons:

      • it’s not clear (for the end users) how responsive-width differs from flexible-width
      • media queries can contain max-height too
      • separate stylesheets (and even markup) based on user agent strings (without media queries) achieve the same goals, except that we don’t get that funky effect we all love, when resizing our browser windows :)

      I think the feature should be called mobile-friendly, device-friendly or okay, maybe responsive-layout, but it should not fall under the width column in the tag filter: http://wordpress.org/extend/themes/tag-filter/

      Just my two cents :) I’d like to hear your opinion.

      • Lance Willett 1:42 am on July 20, 2012 Permalink | Log in to Reply

        Those are good points, it could be hard to explain “responsive-width” from “flexible-width” as you said, but I think it still stands on its own.

        I do think it’s better to add to the width category rather than not adding it at all—themes need to be able to be categorized by having responsive design.

        Should we update the width category to something new? Like “Layout” and change it to fixed, responsive, and fluid? (Flexible is ambiguous—I prefer fluid for themes with a liquid, fluid layout.)

        • Konstantin Kovshenin 2:50 pm on August 2, 2012 Permalink | Log in to Reply

          Hi, sorry never subscribed to this thread after posting.

          After discussion on Make Themes, I think a better approach is to rename
          “Widths” terms to “Layout” and change the three allowed values to “Fixed,
          Fluid, Resonsive”.

          Yes please! :)

    • Lance Willett 1:44 am on July 20, 2012 Permalink | Log in to Reply

      By the way—if anyone wants a fun read—we’ve developed a much broader taxonomy for categorizing themes including new terms for Subject and Style: https://wpcom-themes.svn.automattic.com/demo/theme-taxonomy.txt.

      It’s in use heavily on http://theme.wordpress.com/themes/ and has been well-received by people looking for themes fitting a certain look or style.

      Someday I’d like to rework the core list to include this, if possible.

    • Lance Willett 5:55 pm on August 1, 2012 Permalink | Log in to Reply

      Update: I split out the “flexible-header” and the proposed changes to width -> layout into a new ticket.

      See http://core.trac.wordpress.org/ticket/21442 for the proposal and http://core.trac.wordpress.org/ticket/21065 for just the flexible-header change.

    • Lance Willett 11:53 pm on August 24, 2012 Permalink | Log in to Reply

      The flexible-header tag is now in core with r21604.

  • Lance Willett 4:06 pm on February 16, 2011 Permalink
    Tags: comments, standards   

    After a prompt from Westi I added a note to Comments template standards on the Theme Development Codex page today.

    The comments.php template file shouldn’t contain function defines unless in a function_exist() check. Ideally all functions should be in functions.php.

    Example case: If comments.php contains function defines and the attachment.php loop assumes only one attachment to display and calls comment_template() each time round, you will get function redefines and fatal PHP errors for “cannot redeclare this function that was previously declared.”

     
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