On Wednesday, WordPress executive director Josepha Haden Chomphosy posted the next steps forward for themes and reviews for the official theme directory. In the post, she describes the tools and types of access the Themes Team needs. She also laid out some other goals for the system. The timeline is to have much of this in place by early 2022.
Two months ago, things were coming to a head. Project lead Matt Mullenweg saw much of what we have all been seeing. Creative contributions to the free directory were few and far between, many of the submissions merely being stripped-down “lite” themes with commercial interests.
There was some disagreement on why the directory was not producing the high-quality projects users should expect from an official source. Mullenweg cited the rules and update mechanism as problem areas.
However, others like Joost de Valk, the CPO of Yoast, said the reality of the situation is that money is now a part of the equation. Producing high-quality products, maintaining them, and supporting them is not sustainable without the financial resources in place. Because WordPress.org provides no path for developers to make money directly, upsell-motived themes are the result. Eric Karkovack expanded upon this in his piece for Speckyboy, Are High-Quality Free WordPress Themes a Thing of the Past?
Some of the Themes Team members disagreed that the rules were the problem. At the heart of the team’s handbook is the idea that themes should be GPL-compatible, secure, and not break things.
The problem is not necessarily specific guidelines but the process. Mullenweg wanted to switch to a post-commit strategy that would see themes move into the directory more quickly. The goal is to be a little more like the plugin directory and let users guide others through the star-rating review system.
However, themes and plugins are different beasts. Themes must follow some standard patterns and do some specific things to actually work. The best way to make that happen is with automated tools performing the grunt work that humans have been doing for the past decade. Many guidelines could become a line of code in a script. Each new line would lighten the burden on volunteers.
The Themes Team agreed with his assessment of the theme quality. However, some did feel like the theme system was the oft-forgotten stepchild who received all the hand-me-downs from its preferred sibling, the plugin directory. They needed resources from the community to drive any sort of change. Team members had little power outside of their gatekeeping responsibilities and were short on volunteers.
Changing Hearts and Minds
Haden Chomphosy published notes on the meeting in February. The post detailed the ideas and what took place. However, much of it seemed vague in terms of actionable items. It was the groundwork phase.
In a private discussion with one of the Themes Team reps, they said the meeting was productive not because of action taking place but through the changing of outlooks. More of the team reps warmed to the idea of reducing the requirements and moving forward with a change. The meeting was more about winning hearts and minds, which was a necessary first step.
This changed outlook did not mean throwing caution to the wind and flipping the switch overnight. The team wanted to set some guardrails in place, particularly surrounding high-priority issues like proper licensing.
“In the meeting, we discussed the need to change the review process,” said team rep Ari Stathopoulos. “All guidelines have a reason they exist. They were all added after some things got abused. But the process followed had an unfortunate side-effect; the rules that were added to avoid abuse by a few bad apples are the same rules that hinder innovation and deter people from submitting a theme in the repository.”
He brought up the universal rules of not doing evil things, disrespecting others, or abusing the system. Citing them as the foundation of what the guidelines should be. “But then, of course, everyone has a different definition of evil, disrespect, and abuse, so something a bit more verbose may be needed but obviously not as verbose as the dozens upon dozens of guidelines we currently have.”
The Next Steps: Tools and a User-First Strategy
The first goal is to have access to a functional meta environment for testing. One of the team reps currently has this. However, others would need access in the long term. Moderator tools are also on the list for reviewers, likely similar to what the Plugin Review Team has.
Those are some of the baseline things. The next item will be more automation. Dion Hulse is currently working on automated security checks, which should help with a consistent problem area. Steve Dufresne is working on an automated code-scanning solution.
One idea for a post-commit strategy is flagging themes with “quality tags.” These include items like Gutenberg-ready, security, last updated, translation-ready, and accessibility. It is not clear how this system would work, but it could be a way to surface themes in the directory that meet standards. Perhaps a new featured-theme algorithm should be in the works?
The last piece of the proposal introduces the concept of a yes/no voting mechanism for end-users. These would be “trust tags” that allowed users to mark themes as updated, visually broken, and more. The goal is to hand over much of the gatekeeping responsibility to users, putting them in the driver’s seat of what they want out of the theme directory.
Firstly, I want to say that what I’m seeing from Josepha is highly encouraging, and the first real progress toward meaningful change in years.
Having said that, I’m glad to hear that the Theme Team pushed back when Matt said this (which is complete rubbish): “The .org theme directory rules and update mechanism have driven out creative contributions, it’s largely crowded out by upsell motived contributions.”
Contrary to Matt’s assertion, you have nailed the real issue: you simply can’t separate the financial motives behind most/all of the developers who are producing the highest-quality Themes, and the Theme directory nor the Theme Team has ever had the infrastructure to accommodate such motives or such developers.
As a result, the shining-star Themes and theme developers got lost in the deluge of bad code, bloatware, and copycat Themes being submitted. (And that doesn’t even get into the legitimately bad actors, who could much more easily slip through the cracks.)
Reviewing such Themes manually takes a non-trivial amount of time. (Remember: no real, automated tools for most things. ThemeCheck helped, but it really wasn’t sophisticated enough to know if core functionality was incorporated/hooked/filtered and implemented properly, etc.)
Most of the Theme Team wanted either to help new developers improve their Theme development skills, or to use the Theme Team to improve their own skills – laudable goals that I hope remain today. Unfortunately, all that time spent buried in the deluge left little time for helping people.
I also disagree with the suggestion that the guidelines somehow stifle innovation. The guidelines enforce following core WordPress coding practices and implementation. Themes should not encourage “innovation” in a way that breaks core functionality, code, and methodology. Innovation should come through implementing core functionality, code, and methodology in innovative ways.
Ultimately, a huge part of the answer to this impasse is improving the underlying Theme submission and automated vetting infrastructure, process, and code checking. (Again: something the Theme Team has been requesting for years.) Allowing direct SVN commits, with a post-commit vetting process (I repeat myself: something the Theme Team has been requesting for years) will remove barriers for experienced Theme developers, and will facilitate and encourage iterative remediation of Theme issues and continuous improvement of submitted Themes.
So, I look forward to see what Josepha, the Meta team, and the Theme Team can implement to make these improvements a reality.