Next Phase of the WordPress Theme Review Overhaul: Open Meeting and Call for Feedback
The WordPress.org Themes Team announced an open discussion and date for a Zoom meeting with theme authors. The team is proposing a new set of guidelines that reduces and simplifies what is currently in place. Comments on the proposal are open through July 26, and the meeting is set for July 28, 2 pm CET.
This is the next step in an ongoing plan to revamp the review system and make it easier for the WordPress community to submit themes. It comes after months of waiting to see the results of earlier discussions unfold.
In January, the state of the theme review system seemed to have reached a crossroads. The Themes Team, a group of gatekeepers that oversees submissions to the official WordPress.org theme directory, had been making strides in the previous couple of years. Its members had cleaned up most of the submissions backlog, but they still had a lot of work ahead to smooth out the review process. On the whole, a series of incremental improvements seemed to be working at the time, albeit slowly.
Then, WordPress project lead Matt Mullenweg dropped a bombshell via the Post Status Slack:
The .org theme directory is particularly bad when you compare it to any half-decent commercial theme marketing page, or the designs available on other site building services or Themeforest directories. The .org theme directory rules and update mechanism have driven out creative contributions, it’s largely crowded out by upsell motived contributions.
It was an age-old discussion of whether the theme review guidelines were too high of a barrier for entry into the directory.
Were WordPress users missing out on the best themes because the most innovative theme authors were not playing in the .ORG sandbox? If so, were the rules driving them away?
No one can know if a more lenient, free-for-all atmosphere would have unleashed a mountain of creativity paralleling or besting commercial theme producers. But, perhaps if the team opened things up, it would test the theory.
That initial post led to a series of discussions and a decision to overhaul the system. However, the Themes Team would need some help from the Meta Team to implement more automation of its grunt work, such as security and other code checks. Behind the scenes, pieces of that system have been put into place in the months since.
Guidelines Proposal and Questions
Themes Team representative Carolina Nymark listed a set of 13 overarching guidelines, each with sub-guidelines of their own. The proposal significantly simplifies the current rules for submission into the directory.
She asks that theme authors review the proposal and answer the following questions in the comments ahead of the meeting:
- Will the updated requirements make it easier for you to submit themes?
– If no, what is making it difficult for you to submit themes? - Will the updated requirements make it easier for you to review submitted themes?
– If no, what is making it difficult for you to review themes? - Are there requirements that need to be removed, and why?
- Is there anything in the list of requirements that is unclear? Describe the issue.
- Can the formatting of the page be improved to make it easier to read?
The current proposal is more expansive than the shortlist of guardrails WordPress executive director Josepha Haden Chomphosy mentioned in a post that laid out the next steps. Most of these were not meant as blockers for submission.
“Rather we should use the list to flag themes that have/don’t have each thing and show them in results accordingly,” she wrote. “Likely exceptions to this would be proper licensing, adherence to fair use of the trademark, and a ban on child pornography or other images of anyone unable to provide consent.”
The goal was to put more responsibility into the hands of users, granting them privileges to say whether a theme was working or not. This would take a lot of the work off the shoulders of the review team.
Another part of the original proposal was to mark themes with “quality tags” that went above and beyond the baseline for approval. For example, internationalization (i18n) and accessibility (A11Y) are items that do not stop a theme from technically working. Instead of making these requirements, themes would merely be tagged if they met those standards.
Presumably, there would be incentives for taking those extra steps for theme authors, such as higher search rankings, the ability to be featured, and more. It is not that i18n and A11Y standards are unimportant, but they are sometimes hindrances to first-time authors. And, they definitely fall within the range of things that end-users can dock themes for in the ratings.
Many will take a hard stance on i18n and A11Y, but they are merely examples. A less controversial guideline might be the one that proposes that themes can only recommend plugins directly hosted on WordPress.org. Why should that be a blocker for inclusion in the directory? Some will say there is no good reason for it since themes are disallowed from installing plugins anyway. There are no technical issues with allowing such recommendations.
It is these sorts of rules that have plagued the theme review process over the years. Often, it moves discussions into ideological territory that most users do not care about. They just want themes that work.
Under the new proposal, moving to 100% blocks would further reduce requirements for developers. Currently, classic themes have a more extensive list of rules they must adhere to. Many of these are unnecessary for block themes, essentially cutting everything back to including a few required files. Most of this can and should be automated in the long term since they are necessary for a functioning theme.
Right now, the 13 guidelines (and their sub-guidelines) are only a proposal. Theme authors have a voice, but they must use it. As is so often the case, decisions are made by those who show up. Far too often, the team is shouting into the void, awaiting a response that rarely comes.
For theme authors who are invested in the future of the WordPress theme directory, that July 28 meeting is a can’t miss opportunity. Early responses via the comments on that post will also help shape the conversation.
22 Comments
·
Thank you Justin for the coverage.
Report
·
For me a major turn off was the underwhelming previews of themes over the years. Having all the org themes installed with the same conditions and dataset made for a very poor preview experience. Specially when a theme had been tailored with custom settings for landing pages or special settings to make it shine… the default WordPress preview mostly makes it look really bad or doesn’t even allow to leverage the Autor to set it up in the needed way.
Report
·
True, the wordpress.org theme repository preview always has been almost completely useless.
Report
·
In all the years that I’ve been designing and submitting themes to the .org repo, the “Preview” has always been a major problem. Yet, even though this has been brought up in discussions in the forums and meetings, nothing ever seems to take root in solving it.
I find it hard to believe that the preview button cannot have a link to an actual demo website, either from a link in the theme’s style.css header, or another method.
I would love to see a completely new theme directory established–then phase out the old one.
Report
·
Maybe it’s time to overhaul the ancient theme submission process, too…
Report
·
Bastian, what does that mean, exactly? What would help you submit themes?
Report
·
Use SVN, just like the plugin repo. Or better, use GitHub.
Report
·
OK, so do I understand correctly that your statement is not actually related to the theme requirements?
It has two sides to it.
Having to setup svn and using that to submit theme updates, compared to only submitting a zip file via a form, it increases the difficulty for some.
It does not lower the entry barrier for submitting themes, which is a big part of what the WordPress leadership has asked the themes team to do.
I hope that eventually we (theme authors) will be able to choose between the form upload and git. That both will work.
The themes team does not work with the backend, -or even the theme directory code. The meta team does, so even if this is something that the themes team would support, the decision and implementation is not up to the team.
Report
·
The theme directory is quite frankly a mess. From the available themes trying to upswell premium services to the long winded and backwards review process; it’s just not worth it.
Plus, with blocks becoming a theme, themes really are just glorified colour palettes now because why would you want to lock yourself into a theme when you can basically build something completely custom?
I think plugins and themes need to be reworked into some kind of extension directory because the lines between what they are are getting more blurred with each release.
Report
·
Imho when having a Woo Store I would still go with a theme from Yith or Woostify, because it is custom built for Woo. But for personal blogs and single page websites I’ll go with blocks. And many people would still opt for magazine themes as it provide all necessary feature for them.
Personally I can’t code, so when my requirement for a theme is like the above mentioned I’ll go with a theme rather than reinventing the wheel
from the very first.
Report
·
These are the two opinions where the theme directory will never be able to please everyone:
Make it easier to upsell.
Allow themes to recommend or require third party plugins.
This would:
1) Lead to themes being used only for upselling these plugins.
2) Lead to a shorter review process.
*Don’t allow upsell. This would:
1) Take away the incentive to submit themes from those who need food on the table.
2) Lead to a longer review process.
Please help me understand what you mean when you say “long winded and backwards review process”. And more specifically, what would help you submit themes?
Report
·
A file upload option into a proper theme database rather than uploading a zip for it to be attached and reviewed within Trac.
Use git instead, or some other variation to allow updating only single files where needed.
The current process takes too long and could t for the most part be automated. In fact one thing that is automated is checking certain classes exist within the style.css file which is ridiculous as it doesn’t fix an actual problem.
I’ve submitted one theme (Nude) and even that’s that was an edge case, the whole experience has completely turned me off wanting to submit another. It takes too long, is too complicated and the directory pages don’t focus on show casing the actual theme working to it’s potential.
That’s why the quality of themes is so low to be perfectly honest. A complete overhaul of themes (and plugins) is needed but .Org has never pushed real change.
Report
·
I can’t remove blockers, if no one is every willing to say “this is blocking me”. I appreciate everyone who takes the time, but I still need the feedback to be specific to be able to adress it.
I have already responded about git above. But I want to clarify again that
the theme directory preview, the upload process and the review process are 3 separate things. They are handled by different WordPress.org teams.
When they are seen as one, it makes it more difficult for us to separate the concerns and improve the theme review process, because it becomes unclear what they main issues are.
The theme review queue is about one hour, so I strongly disagree on that point.
Report
·
typo: if no one is ever willing
Report
·
Here are my questions:
What is going to happened to the themes currently there that don’t follow the new rules? Will they be grandfathered in or removed?
In the plugins side, I seen some plugins that have not been updated in 6+ years. Not sure about themes but anything that has not been updated for years should be removed
Report
·
As far as I can tell, there are no new guidelines in the current proposal. It’s a rewording and reorganization of existing guidelines minus a lot of old ones.
As for plugins, I have some that have not needed an update in over six years. That’s generally not the case for themes. I like the current system of not showing themes/plugins older than two years in search and also putting a notice on the page.
Report
·
I often wondered if the directory should be set up to de-list or completely remove themes that are a certain age and that have not been updated. The trick would be to determine the criteria by which this would be implemented.
However, as I just posted in a comment above to Max Ziebell, I would love to see a completely new theme directory built and then phase out the old–much easier to do it from scratch than fighting with the old one. Although, developing a new directory from scratch is a huge undertaking.
Report
·
Andre, this de-listing already happens to themes that have not been updated in two years.
Yes rewriting is a huge undertaking, just consider the amount of effort and time that has gone into the new pattern directory.
Report
·
Here is my problem. Sometimes the plugin needs an update, but does not show anywhere. This is very agitating, to me at least. When I update plugins there is always one that does not show in the list to update. I read in a thread somewhere that it is a deleted plugin that still has stuff in the database that has not been removed. So my question is this. Is there a way to find out what is causing it, and to delete it? Perhaps a plugin that will do it? I have searched for such with no results.
Report
·
If WordPress is not on latest release (because reasons), some plugins do not show updates any longer, as they only are marked to support two releases back, e.g. Yoast SEO plugin will not show any plugin updates at all, no matter of installed Yoast SEO version, if you do not have WordPress 5.6 minimum. This can lead to unexpected situations.
Report
·
Same here miss Jenna Anderson😕
Report
·
Hi Justin,
Thank you for updating us on the next phase of the WordPress theme. Hope for a fruitful discussion, now we are eager to know the upshots.
Report