Major Changes to Guidelines Should Have a Request for Comments Time Period

For the last three years, the WordPress Theme Review Team has tried to encourage theme authors to adopt the Theme Customizer. In April, the decision was made by the TRT to no longer encourage, but require all theme options to be in the customizer. Although the decision was three years in the making, the community didn’t have an opportunity to provide feedback until after the requirement was put in place.

The Timeline

Estimated Reading Time Featured Image
photo credit: Eyesplash – let’s feel the heatcc

Those who follow the official TRT blog likely saw the writing on the wall. With the release of WordPress 3.4 in 2012, which introduced the theme customizer, the TRT held discussions on proposed changes to the theme review guidelines. One of the proposed changes recommended theme options be incorporated into the theme customizer. Of particular interest is a conversation between Justin Tadlock and Chip Bennett on whether or not the customizer should be recommended so early.

In November of 2014, the team held a meeting to discuss modifications to the theme review guidelines. Up until this point, theme authors were allowed to create theme options in one of three ways, Theme Customizer, Settings API, or with custom options pages using the Theme Mods API.

During the meeting, Tadlock suggested that the team should strongly recommend theme authors to use the customizer. Members in attendance agreed and the theme review guidelines changed to strongly recommend theme options be placed into the customizer.

A few days after the meeting, Tadlock published a post asking how do we solve the theme options problem? He highlights the lack of educational resources on the customizer as one of the major culprits of its slow adoption.

One of the things I’ve always hoped the TRT would become is more of an educational team. I firmly believe that if we didn’t have to spend so much time dealing with theme options, we could spend more time on educating in other areas of the dev/design.

I’m writing this post because I believe this to be the biggest hangup with themes today. It’s the hardest part of the review process. It’s also one of the most critical because theme options means potential security issues.

The post opened up a dialogue to discuss ways of dealing with several issues related to getting developers to adopt and use the customizer. Bennett published a post a few days later that explained APIs related to theme options. It was later followed up by Tadlock with a post on choosing Theme Mods API or Settings API.

The Vote

Fast forward to April 2015, the team held a meeting and unanimously agreed to require theme authors to place theme options into the customizer. A day later, Tadlock explained why the change was made and how the team came to its decision.

First, I want to say that the team did not take this decision lightly nor did we make it quickly. In fact, this has been an ongoing discussion for nearly 3 years (since the customizer was first introduced in core). Many of us had originally hoped that we could take a more organic approach to this and allow theme authors to naturally make the switch on their own given enough time.

The decision created a passionate, lengthy conversation with several people chiming in after the fact on WP Tavern.

A Request for Comments Period

Future Of Commenting Featured Image
photo credit: Marc Wathieucc

On the TRT blog, there are several blog posts that encourage feedback, especially on guideline proposals. In this instance however, feedback, concerns, and criticism weren’t encouraged until after the decision was made.

The TRT usually publishes an agenda that highlights what topics will be discussed during the meeting. An agenda was published for the April 14th meeting but not for the April 21st meeting. This means only those in attendance were able to voice an opinion and vote on the issue, as there was no advance notice.

I understand the team has discussed this change for the last three years, but I would like to have seen a request for comments period for at least a month on the TRT blog.

This way, people could comment on the decision before it was implemented. The team could have controlled the conversation, provided a more accessible way of participating in the discussion versus Slack, and heard legitimate concerns from theme developers.

I hope major changes like this in the future are addressed in a way where the public can be more involved. The notion that concerned parties should have been in Slack during the meeting to voice concerns before the decision was made is unacceptable. People have things to do and while I think Slack is easier to use than IRC, a blog post with a comment form is accessible to a lot more people.

An RFC period doesn’t make sense for a lot of what takes place in the world of WordPress development but a change that affects current, past, and future themes in the directory is a great example of where it does makes sense.


55 responses to “Major Changes to Guidelines Should Have a Request for Comments Time Period”

  1. Perhaps one way to inform theme/plugin authors is to email them. Those that have written a theme or plugin within x time period gets notified about feedback request etc. Most people dont hang around on the make blogs.

    • Most people don’t hang around on the make blogs.

      Well, there’s one major reason why there should be a buffer between a major change like this and its implementation. The discussion of the change shouldn’t have happened on the Tavern, it should have taken place on the Theme Review Team’s blog post announcing that this change was coming and that it would come to a vote.

  2. As much as it would be nice for everyone to agree, you’re never going to make everyone happy. Leaving it up to hundreds or even thousands of people will not get you anywhere, as there will be opinions going in every direction.

    While it may be a seemingly unpopular decision, more unison in how themes work will lead to good things.

    • I understand what you’re saying. It’s akin to the argument that all people will do during a request for comments time period is bike shed. So be it. At least those people would have an opportunity to voice their opinion and express there views BEFORE the change gets implemented, not AFTER.

  3. I’m still liking the Customizer and the decision made, although easy for me to say because I’ve been using it in my themes for 2+ years now (both my free and premium themes). The one thing Justin said that I agree was/is the lack of educational resources for the customizer. It’s even been suggested in the Slack that perhaps some kind of newsletter for theme authors should exist when important changes and decisions are discussed or about to be made…a newsletter sent to an author’s inbox (perhaps a requirement).

    As for customizer documentation and tutorials, I still to this day see bits and pieces here and there spread out across the net from the Codex, to Gihub, to personal blogs, but never anything comprehensive.

    I just had a free theme approved at and still there were things that I didn’t know with regards to the customizer as Ulrich Pogson pointed out to me during the review…things that are nowhere written. Needless to say, the theme was approved and doing well, so I am taking what I got from Ulrich and adapting it to all my themes.

    I’m hoping for theme authors, the team puts together some solid resources and documentation (with lots of examples) to help everyone through the transition. It’s going to be a rough ride for many.

    • In a perfect world, theme authors who host themes or want to host themes on the free directory should at least subscribe to the Theme Review Team’s blogs RSS feed. As for education resources, I came across this in my Twitter timeline today which looks like a good start.

      Is the Theme Customizer requirement a good choice? I don’t know. What I do know is that the way it went down doesn’t sit well with me and that’s the point I addressed in the post.

      • Perhaps it’s a learning experience for the review team. Thanks for that link too Jeff…Never seen that one before (I’ve bookmarked it), but I agree, it’s a good start.

  4. I find this editorial to be a bit ironic. Of all the community contributor groups, the Theme Review Team is the most open, most communicative, and most inviting of outside input.

    I think the move to Slack, and the decision (above our pay grade) to close the email lists, has certainly changed the nature of our work/discussions. But that doesn’t mean there is no discussion. The themereview slack channel is open to all. We have weekly meetings. We publish our meeting agendas.

    To add to the irony, I hated the decision to eliminate the email groups and force all communication into Slack. Because of the nature of my work, it forces me to miss out on most real-time communication. But the decision was made for good reasons, and I’ve adapted.

    The same is true for the Customizer.

    • Ordinarily TRT publishes meeting agendas, but this time they did not. The vote taken during that meeting affected thousands of WordPress themes and has ripples into the community at large. Given it has been under discussion for years, it would have been good to see it mentioned in a meeting agenda post.

      • If the argument is that the TRT didn’t communicate this specific change well enough, no problem. Valid criticism. But in general, the TRT makes every effort to involve the community at-large in all decisions. My issue is with the general premise of the exitorial, and not with any valid criticism of how this specific change was handled.

      • Out of curiosity, what part of WordPress operates as a democracy? Core development? The Plugin Review Team? The forum mod squad? Any other community contributor group?

        The TRT has exactly zero control over any commercial endeavor. We admittedly have not made economic impact to commercial developers one of our primary considerations. The Theme directory exists for end users’ benefit, and end users are our primary concern.

        And what accountability do you propose for TRT decisions?

        • You mean end users who prefer non-customizer themes over customizer themes?

          There is a reason less then 25% of themes adopted the customizer in 3 years. End-users downloaded just as many CyberChimps themes in that time as Automattic customizer themes. There’s absolutely no evidence or number that supports end users preferring customizer themes. With 18 themes we nearly had the same number of downloads as 60 Automattic themes. Our themes were more popular.

          As the former owner of one of the largest theme shops on .org, we sold both non-customizer and customizer themes and the non-customizer themes outsold the customizer themes by nearly a factor of 3. Customizer themes do not sell as well as custom theme options and we sold singicantly less customizer themes by comparison.

          End users prefer theme options to the customizer. I would have been more then happy to share this data had anyone bothered to consider it.

          • There is a reason less then 25% of themes adopted the customizer in 3 years.

            That reason, primarily, is because Theme developers chose not to implement the Customizer. Your number is also inaccurate. About half of all directory-hosted Themes provide a Theme Settings page. About 25% of directory-hosted Themes use the Customizer. Those two numbers certainly overlap, but at a minimum, 1/3 of all Themes that provide options expose them via the Customizer.

            There’s absolutely no evidence or number that supports end users preferring customizer themes.

            And that’s a straw man, anyway. Nobody has argued that end users “prefer” the Customizer to custom settings pages, and that argument was not part of the basis for the TRT decision.

            As the former owner of one of the largest theme shops on .org, we sold both non-customizer and customizer themes and the non-customizer themes outsold the customizer themes by nearly a factor of 3. Customizer themes do not sell as well as custom theme options and we sold singicantly less customizer themes by comparison.

            Correlation does not prove causation. I doubt that the only difference between the Themes in question was the use of the Customizer API vs. the Settings API.

  5. I think this is a great idea.

    However, TRT isn’t a democracy, it never was, and I’m pretty sure there is no intention to allow it to be. I didn’t get to select or vote for any of the people in power, they’ve all been appointed through other means.

    For years now TRT has been making decisions that have impacted theme authors without their feedback or consent (preventing theme authors from using their own theme names for follow up releases, the theme review contest, featured theme selection, etc).

    Unfortunately TRT has routinely failed to consider the economic impact of their decisions on the greater community. They make technical decisions without human consideration. Top theme authors have had zero say on the present or future of their themes and TRT has made it pretty clear that’s how it is.

    I personally put in more then 5%, donated thousands of dollars to the WordPress Foundation, donated hundreds of hours of development time to theme reviews over the years, and still ultimately had no say on any of the decisions mentioned above. I couldn’t even release “Responsive II” as a theme name and was forced to rename it “Responsive Mobile” because of a rule that no one even really agreed with.

    The way TRT operates currently and pretty much always has is that of a dictatorship. Whatever they decide is, and unfortunately even if they give us a month of advanced notice before making a decision it likely won’t sway anything as long as TRT have no accountability for their actions.

  6. First of all, great article! :)

    Second, let’s not forget that we encourage everybody to join the meetings. In fact, that is where most, if not all, of the decisions are made. These meeting have been going for quite some time ( August -2014, I was the person who revived them ). Prior to that it was just the mail-list and the occasional blog post. The time hasn’t changed since we first began them. If you want to read the notes from the first meeting:

    The only thing that changed is using Slack instead of IRC. But really, we added the blue info bar just after WCSF with all that information. :)

  7. 3 years was plenty notification and open source projects as big as WordPress require decision making else the ship will drift at sea! Way to go TRT!

  8. Jeff, while I agree with you to some extent, you’re not actively involved in TRT, so you fail to see that we get very little communication from theme authors when we actually do post things beforehand. If you go through the Make blog posts and look at the comments, you’ll notice few of them are involved. Most of the comments are from TRT members. It’s not until afer we make a decision (this one and others) that people all of sudden have an opinion.

    Like Chip above, I didn’t like the initial dropping of the mailing list and move to Slack. But, it has proven a very useful tool and gotten more theme authors involved. That’s been a great thing. However, it’s still not at the numbers I’d like to see.

    The truth is that we can’t force participation. I can only hope that this whole thing gets theme authors more involved. If having your theme hosted on the repo is something you’re passionate about, you need to be involved with the process.

    Just like that post you linked to of mine from last November, pretty much everyone there was a team member. We were trying to solve some major issues with theme authors’ themes, but they didn’t bother to communicate with us. I don’t remember people writing about that either and spreading the word (sorry if I missed that Tavern post). What are we at now? Three weeks of discussion on this change? Where was the three weeks of discussion when we were trying to fix a big part of the problem 5 months prior?

    • What incentive does anyone have to participate in being dictated to?

      While I truly respect the technical knowledge of TRT, I fail to see why TRT even has the authority to make non-technical decisions for an entire community.

      I’ve been plenty vocal in fact I’ve been in this community long before you were promoted to admin on .org. Not a single thing that I’ve warned the TRT about has been taken seriously. I tried to warn TRT about the traction I was receieving from being featured, and how powerful it was; yet the TRT moved forward with the review contest anyway flooding the repo with all the poorly coded themes you’re all dealing with now. I tried to prevent millions of websites from being broken by allowing me to release a follow up to Responsive in its own repo, but even that wasn’t allowed. I’m one of the few authors who isn’t afraid to voice my opinion and the more I did, the more TRT came after my themes and my theme shop. Other authors don’t want to be targeted like I was so they don’t speak up out of fear.

      I’ve been pulled aside in private by dozens of theme authors at WordCamps, on Skype, Slack, and email thanking me for standing up for theme authors but it’s to no avail because TRT does whatever it wants reguardless of the feedback of even its largest theme author.

      Admittingly I didn’t make the transition to Slack because after I attended WCSF’14 and was asked not to participate in the community summit I decided it was in my best interest at that point to sell my theme shop rather then participate in this “community” any further.

      I suspected TRT was going to force the customizer on everyone and destroy theme authors ability to communicate with users. TRT had already prevented me from maintaining my branding with my theme names, remove all my theme notices, and cripple much of the functionality of my themes over the years despite the fact my themes were more popular than even Automattics. The writing was on the wall.

      It doesn’t really surprise me that a random vote would occur like this forcing such a major decision without any consideration for the greater community.

      When you ignore your top theme authors, continually make decisions to limit their capabilities, fail to come to reasonable solutions, and force unpopular features and decisions on them what incentive do they have to participate?

      Luckily I’m no longer impacted by TRT rules as I’ve essentially been forced out of the community because of decisions like this.

      Lastly I’m only replying here because I think it’s important for TRT and other members of the WordPress community to understand that these kind of decisions destroy businesses and people’s livelihoods unless handled and considered properly. WordPress is supposed to be open source but apparently that’s no longer true if you wish to release a theme on Once more developers are exposed to the practices of TRT they will leave.

  9. A public announcement that the issue was going to be discussed and a decision made would have been a good idea. If there were people who wanted to oppose the change they would have had a chance to show up and make themselves heard, but also, such an announcement would benefit the TRT because then people could not complain that they were blindsided. This post make a good point and suggests a best practice for the future.

    Now lets move on. The TRT are volunteers and to a certain extent they get to make the decisions because they show up to the meetings and do the work. They also tend to be pretty darn helpful when people approach them nicely and ask.

    Somehow I doubt that theme submissions will decline.

  10. I went for a coffee and was thinking about all this some more….in a nutshell, I came to the conclusion that sometimes changes and decisions are needed, even the unpopular ones. It also allows things to move on with a fresh new direction.

    Reminds me of Joomla when they started from Mambo. It took some time but to get from 1x to 1.5 then 2x was a major change with challenges…not to mention a lot of sacrifices and frustration ensued, only to see how things got way better. I know this because I have 8 years of Joomla experience.

    It’s all part of growth…as long as changes are logical for good reason(s).

        • Because for several years, Automattic donated use of mail servers for WordPress project team use. Most/all of those mail lists have been retired/archived in the past year, and nearly all project-related communication happens now on Slack.

      • It owns it in all but rights =). JetPack violates policies but is allowed anyway. We have built in Gravatars that violates privacy laws, violates user privacy etc, that is owned by Automattic, we have Akismet also owned by Automattic. Several core members are employees of Automattic or parent company of Automattic or subsidiaries etc. I would say that Automattic related people pretty much control WordPress. Either they are extreme fanboys or they are employees. We all know about capital_p_dangit =).

        • It is true that Automattic gets special treatment, but that doesn’t mean that Automattic owns WordPress, or even has a majority say in project-related decision-making. Unless something has changed, a majority of core developers/core committers are not affiliated with Automattic.

          You know my opinion of special treatment, and especially of things like capital_p_dangit(). But it is untrue to say that Automattic owns WordPress.

  11. I’m not a theme developer, but as someone who’s been among the WP community for a while, I can’t help but wonder (in hindsight, yes, but perhaps a lesson can be learned)… if the customizer was that important, were there any sessions at WCSF 2014 about the topic? I don’t see anything on the schedule that looks related.

    Supposedly it’s *the* official conference of the project…

      • I was asked not to attend the community summit due to a supposed lack of space. I actually live in San Francisco and blocked out the entire week of my schedule so I could attend and still wasn’t allowed.

        By the numbers, before I sold CyberChimps I was the second largest theme developer on .org besides Automattic.

        It is no coincidence that the largest theme author was asked not to attend the community summit and then a decision like this was forced upon the entire community without warning.

        Theme authors unfortunately have no say with the way the TRT is setup.

        • It is no coincidence that the largest theme author was asked not to attend the community summit and then a decision like this was forced upon the entire community without warning.

          Yes, actually. It is pure coincidence. The Theme Review Team had no control over or input into decisions regarding who attended the Community Summit. Those of the team who attended were there as mere attendees, just like everyone else. There is also the small matter of the TRT decision being removed from the 2014 community summit by half a year.

          • That’s not true. TRT had several members present at the community summit and the WordPress Foundatuon even paid for at least one of you to attend. The foundation could have allowed me to attend given my standing in the community.

            The foundation and likely several members of TRT didn’t want me there because they knew I would defend commercial theme shops and theme authors rights. You guys and gals claim to want to get feedback and be open with the community, but the second anyone says anything against TRT they are either ignored or collectively countered by multiple members of the TRT or in my case simply not allowed to attend a volunteer community summit.

            My voice was not heard, along with all the other theme authors I was trying to represent. I was trying to volunteer my time to work through these issues in person once and for all to prevent situations like this one right now. Instead once again I was ignored, and the TRT screwed up handling a major decision like this once again.

            I was trying to help.

            • What, exactly, did I say that was untrue?

              Further, and again, the TRT had nothing to do with your participation, or inability to participate, in the community summit.

  12. WordPress basically love-hates on themes. WP has devastated the ‘theme-community’ before. Now it’s happening again. It’s hard to take all the Customizer and “TRT” drama seriously.

    First (long ago) WP fosters an independent theme-hosting ‘game’. Then, no, forget all that and get them on the Org repository. Now it’s only do options with our Special Sauce tool.

    It’s like health care. Real issues with our system are used to justify a gigantic political mud-wrestling contest. Are the actual problems with the medical industry (or insurance) getting fixed? Is the cost falling from that omg 18%?

    It’s not about fixing health care. It’s not about addressing problems with themes.

    WordPress started issuing its own new themes annually, half a decade ago. They don’t need hundreds of independent (often one-off) authors and dozens of little & big software shops.

    Com ran a promo to draw theme-writers into a biz-op with their captive hosted sites. Then they hung the respondents out to dry. Uhh.

    Interestingly, Drupal does this too.

    • WordPress started issuing its own new themes annually, half a decade ago. They don’t need hundreds of independent (often one-off) authors and dozens of little & big software shops.

      The TRT has literally nothing to do with core-bundled Themes, or the teams that create and maintain them. The TRT is not privy to any secret plan to eliminate non-core Themes, or to put commercial Theme shops out of business.

      • You are right Chip. I will say, however, you have no motivation anywhere to uphold the enterprise of the Theme Shops, nor do many of you have personal motivation.

        Also you have the example of the rest of Automattic.

        I just think what this article is about is more awareness for big decisions. I think it’s valid and needs to be done appropriately. Especially for decisions like this.

        But I am confident that the TRT is in no way evil. They’re normal people! There just needs to be better processes.

        • Again, I think it’s fair criticism that we could have done better regarding communication of this decision. Our modus operandi has always been to post on Make/Themes regarding intended changes, and solicit feedback, and then incorporate that feedback into the decision. We do things a bit differently now, in the post-Slack environment; and we’re adjusting to it in our workflow, just like everyone else. So we could have done better.

          The reason I found the editorial to be a bit ironic is because, of all the myriad decision-making processes in the WordPress development world, the TRT is the one that most tries to solicit input and feedback. There is no RFC for core decisions. There is no RFC for Plugin Review decisions. Wash/rinse/repeat for all the rest of the teams.

          And honestly, nor should there be. The development of the entire project would come to a standstill if every major decision had to go through an RFC.

          There already exist channels and means of communication to provide input into most WordPress-related decisions. That people don’t know about them, or choose not to use them, does not constitute a good rationale to implement RFCs.

      • The TRT is not privy to any secret plan to eliminate non-core Themes, or to put commercial Theme shops out of business.

        I believe that. Inside actors at WP routinely blink when asked about activities & directions not precisely in their job-description (and even within it). “How would I know”? The Left Hand at WordPress is not privy to the aims of the Right Hand. That’s both an organizational/operational known-strength, and a known source of trouble.

        That the TRT is 3 years (and counting) on their mandate ‘says things’, in and of itself. That the TRT was clearly vested with policy-powers from the beginning, as well as performing the routine service of “Review”, is additional ‘head-scratching’ info. A cocked eyebrow reaction to TRT appears warranted.

        I have a very old & dear friend who once confided to me (a non-secret) that her husband has been getting drunk and beating her up, for their entire 16 year marriage. “Sixteen years, now, every couple weeks or so”? She flushed & looked away … and today it’s 31 years.

        Three years is a long time in WordPress’ field. Is TRT getting anywhere? Three years to sit on, mull a policy-decision … that doesn’t speak to a refined Executive-expertise. Yeah, there’s some problems with themes … but that TRT is actually part of the/any solution, is not obvious/convincing. Hasn’t been, and like with my friend, I’m not expecting much to change.

        • That the TRT is 3 years (and counting) on their mandate ‘says things’, in and of itself.

          It’s actually been five years next month.

          That the TRT was clearly vested with policy-powers from the beginning, as well as performing the routine service of “Review”, is additional ‘head-scratching’ info.

          The “policy powers” relate specifically to content hosted on and distributed by, and do not extend in any way to any developer who chooses not to release/host a Theme on

          A cocked eyebrow reaction to TRT appears warranted.

          The Theme Review Team has always been entirely open, and has never shied away from input, feedback, or criticism. Cocked eyebrows are more than welcome.

          Three years to sit on, mull a policy-decision … that doesn’t speak to a refined Executive-expertise.

          Core developers take four years to decide whether a favicon setting should be included in core, or left to Plugins. Somehow, I don’t think that the TRT taking a measured, planned approach to a somewhat major Theme development component is unusual or unwarranted.

          Yeah, there’s some problems with themes … but that TRT is actually part of the/any solution, is not obvious/convincing.

          I’ll stand behind the five-year-long work of the Theme Review Team, as well as the the results of that work. I’ll put the quality of Themes up against any Themes, anywhere.

          Further, I’ll stand behind the volunteer contributions of a couple hundred people, who freely give of their time to review Themes – perhaps a million man-hours over the past five years.

          The Theme Review Team has led the charge to improve overall Theme quality, to drive Themes to implement core features rather than roll their own, to drive Themes to using core APIs properly, so that Themes work well both with core and with Plugins, as well as with Child Themes.

          Most importantly, the Theme Review Team has led the way in ensuring that Themes are secure, and implement options properly, so that they do not introduce security vulnerabilities.

          The work of the Theme Review Team extends beyond the Theme directory. Ask commercial Plugin developers, such as GravityForms, WooCommerce, and Easy Digital Downloads, if their businesses are impacted by better quality Themes, driven by the efforts of the Theme Review Team. And Envato would not have made nearly the effort to institute their own code quality requirements for ThemeForest, if not for the work of the Theme Review Team. Even Automattic has been influenced by our work, in their own requirements for Themes available on

          (And that effort is a two-way street, even if much of it is behind the scenes.)

          That’s just the tip of the iceberg. If you haven’t seen the Theme Review Team as being part of the solution, then quite frankly you haven’t been paying attention.

        • For the record, and in the heat of this editorial scrum, I would like to establish that I’ve long regarded Chip Bennett as the most valuable Theme authority at WordPress. He is in the best senses a ‘straight arrow’ who resists the buffeting. His contributions derive from the kinds of motivation we all like to see folks working under, and anything he is associated with (the Theme Review Team, prominently) benefits from association with him.

          Chip Bennett’s own Oenology theme:

          … is designed to be a simple, minimalist, yet feature-complete and fully documented Theme intended to serve as a base for child Themes and as an educational reference for Theme development using WordPress functions, action/filter hooks, and template tags.

          If you are following along with this lively & intriguing Post, and wondering whether you might (finally?) take a more active hand in theming your WordPress installation, there is no better guide to the art than Chip’s Oenology example-theme. Especially if are one of those who learn best from real, working examples.

  13. While this will be very helpful for what I am working on, I disagree with the the strong arm tactics and I think they will eventually have to walk this back, otherwise the number of orphaned sites will increase dramatically. The other possibility is someone will set up an alternative theme repository.

    • That’s a really good idea! If I find time at some point I may investigate that idea. I’m envisaging something which is suitable for any themes which are free, good, but not able to pass the dot org requirements. I wouldn’t want to see something competing against dot org, but something for the stuff which isn’t deemed suitable for there would be useful.

  14. While I agree with the TRT’s decision, I also agree with Jeff that the process by which it came about could have been handled better. After three years of “encouraging” the abruptness of the final decision came as a bit of a shock. Sure, discussion beforehand may not have changed the outcome, but it would still have been better if the TRT had announced that they was going to make it *very soon* and then moderate the discussion before the decision rather than make it and put out the fires afterward. They’re responsible for making decisions about the repository. I don’t get a say, never have, and probably never will. I can accept that — maybe because I appreciate that someone is doing that work that I don’t have the time for. So I consider it a service that someone is maintaining some kind of standard as a starting place for my own theme related work. For me it was more the “surprise, we made a decision” aspect of it that sat poorly.

  15. What’s the process for dumping themes that aren’t compliant and won’t get compliant by the end of the six months (I recall that being the deadline, sorry if it’s wrong) they have to do so? They’ll just disappear from the repo and anyone with that theme will no longer have the ability to get support or updates?

    Things do change, and authors really should keep themselves updated on those changes. With that said, likely most do not and the first inkling they’ll have of a problem is when they can’t find their theme in the repo any more… but that doesn’t help anyone who has downloaded and is using a nice theme they found in the repo that’s going to get the boot.

    • There is no plan to remove Themes from the directory. Existing Themes will remain just as they are. When/if the developer attempts to update the Theme, the updated Theme will not pass the review/approval process unless/until it conforms to the Customizer requirement for any Theme options.

      Note that, separate from the work of the Theme Review Team, Themes (and Plugins) that have not been updated within two years are automatically hidden from directory search results. So, yes: if a Theme goes un-updated for too long, regardless of the reason, it will eventually not be searchable. (Though such Themes can still be found directly.)

      That people think that Themes will “get the boot” is not an idea propagated by the Theme Review Team. More likely, the misconception is borne out of incorrect/incomplete reporting, or false assumptions.

  16. I think an RFC period is a great idea, especially for major changes such as this Customizer one. While I can certainly understand the need for standards and why the decision was made, I don’t agree with the decision to make the Customizer mandatory. The current incarnation of the Customizer is a horrible user experience.

    Whilst I try my best to keep up with discussions in Slack along with emails from the various Make WordPress teams, it’s not always possible to know of every single change that is being discussed. Like others here, I already contribute way more than 5% of my time to the WordPress project, from organising monthly Meetups & WordCamps through to supporting themes & plugins. And I’m happy to do this, as I love the community, but again, being across everything is impossible, especially when you still need to do client work to pay the bills.

    I think some advanced notification of major changes, even if it was a blog post on the .org site (and I’m talking about the ‘News’ section, not tucked away in one of the many Make WordPress sections) would be great. News items there certainly get more exposure than the updates in the individual Make groups.

  17. Has the TRT directly contacted authors of existing themes in the repo that will be affected by the new requirement to warn them about future updates?

    The six month period means little if authors aren’t made aware of it.

    • Has the TRT directly contacted authors of existing themes in the repo that will be affected by the new requirement to warn them about future updates?

      No, and we have no way of doing so.

      Again, existing Themes in the directory will be entirely unaffected, unless/until they are updated – at which time, the new guideline will be enforced during review of the update.

      • Hi Chip,

        Not sure how it works and restrictions, but has the email address of every theme author and apparently it is possible to crawl the theme directory to find themes using the previously allowed theme option frameworks. Couldn’t an email then be sent to those theme authors with a heads-up?


        • While may have the email address of every Theme developer who has a Theme hosted in the directory, the TRT does not have that information, or that access.

  18. There is no question that commercial development of themes and plugins, as well as the use of WordPress as a framework on commercial web sites, has helped promote the adoption of WordPress. With that reality in mind, all development teams, and decision making groups, for WordPress should include elected members from big and small companies, and some regular users who wish to run for election, so everyone has an open source voice from the “community,” which DOES NOT just include “end users,” for themes and plugins, but also commercial themes and plugins. The number of non-elected members should never be a majority, so that all the elected members can stop decisions they don’t agree with if they unite together to “make their votes count.” Until a truly community representative development and other decision making environment exists, opinion will continue to turn negative against WordPress as a whole. Negative sentiment will prime the pump for another PHP framework to take a large amount of market share away from WordPress until WordPress is forgotten. Don’t think it can’t, or won’t happen. Make the changes now before history repeats itself. WordPress is a product, and like any company that has a product, the customers/users must have more of voice, or they will go elsewhere.

    Another suggestion. Setup a place on that allows WordPress users to find quality commercial plugins and themes that do and don’t meet standards. Only judge the products by quality, reliability, usability, and security, so personal bias doesn’t eliminate good products. Also, don’t just choose companies that “know someone” at, WordPress VIP, or Automattic. Choose products from companies also that are right now considered “outsiders,” because they don’t follow the WordPress guidelines, but still have good products, because this “outsider” attitude creates an us against them that only promotes hostility, which in turn hurts the entire community, and erodes support as a whole.

    If, as Justin said, more people do not participate, then give them representatives, that truly represent them, that can vote for proposed changes. Don’t just pick companies and people you know, or the circle jerk that WordCamps are now will continue to perpetuate, and cause more hostility towards those with the real power and authority. Listen to the people, or become irrelevant.

    • Interesting ideas. In addition to a “commercial” advocate, I would suggest a “designer” advocate as well. I tend to think in terms of what makes sense as a developer and forget what might make the most sense for a designer.

      While what is helpful for those selling themes should not be the main basis of any decision, I suspect they have good insight in issues and as you mention are part of the wider WP community.

  19. Forcing developers to use the theme customizer was a big business decision, which I haven’t seen any mention of. It directly risks alienating a lot of users, and from a marketing perspective, it’s a nightmare. Another example of great developers, poor business people. The “3 years in the making” was 3 years of letting a known problem develop.

  20. I started really messin’ with Customizer last evening as a friend wanted some theme customization done. Its actually pretty slick.

    The only thing bugged me is the inline stylesheet so I have it writing into a CSS file instead that is last in the priority enqueue. He’s throwin me a few bucks to fix it all up. The theme (I wont mention which) was from TF, last week I did a few things for him. But I ran source output html through the W3C HTML validator, 1347 errors. Its down to 412 now.

    Towards this end, dunno if Customizer core be interested. I am kickin around XML for all the customizer field definitions .vs. its array based mechanism.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: