Denis Žoljom, the automation representative for the WordPress theme review team, proposed moving much of the theme review system over to GitHub. The idea is to move the interactive parts of the review away from the current system. The proposal claims such a move would streamline the process via automated tools and make the manual, reviewer-to-author interactions easier.
Currently, the theme review process takes place on Trac. For many theme authors and reviewers, the software can feel archaic. It does not have the feature set that developers have become accustomed to with other solutions. With the move of major parts of WordPress, such as feature plugin development, to GitHub over the past few years, it might be time to reevaluate other areas of the core project.
Žoljom noted in the proposal that reviews handled through Trac are cumbersome. As a former theme review team lead and reviewer, I know how many on the team feel. Right now, much of the review process is manual. It is handled via a lot of back-and-forth communication between the reviewer and author. There is no good way to leave a note or comment on a specific line of code when there is an issue. This ongoing discussion between reviewer and author is sometimes hindered by a language barrier. The experience of comparing changes between code updates is lackluster at best. Plus, the only automated check is handled by the Theme Check plugin.
Handling reviews on GitHub opens a new world of possibilities that could make reviews more efficient and provide a better experience on both ends of the process.
From 2015 through 2019, I ran a side business with a partner where we performed code reviews on plugins and themes. The majority of that business was working with commercial theme shops. Around 90% of the reviews were handled on GitHub.
At the same time, I was still volunteering with the WordPress theme review team. There was no comparison in terms of user experience. GitHub won hands down. This experience turned me away from wanting to perform reviews for the official directory. Nothing there was streamlined. It was tougher to point to specific code issues and check if a problem was corrected when an author sent in an update.
Žoljom’s initial proposal outlines a system where the theme author submits their theme through the WordPress theme upload page. If it passes the initial check, the system would automatically create a new GitHub repository with the theme. Theme authors can then fork this newly-created repository to work on code changes based on reviewer feedback. Theme updates would also work through GitHub.
“I think that forks are a good middle ground,” said Žoljom. “Authors have forks on their own GitHub accounts and can update those, and make updates that way even. That would definitely help us with people who are trying to trick the system by updating their themes once they go live with things that break the requirements.”
The proposal is merely an idea to explore at this stage. Much of the process could change if it is given the green light to proceed.
“In the end, I hope this initiative will go live and help us bring the review queue down,” said Žoljom. He has hopes the team can integrate more automated checks such as the WordPress Coding Standards. With more automation, it could also mean the theme review team could focus on other projects it works on, such as preparing for the future of full-site editing and continuing education.
Beyond the Review Process
One of the primary issues the team has faced over the years is educating authors on writing cleaner and more secure code. Some issues like sanitizing data on input and escaping it on output are still prevalent during reviews. The team’s history of communication via Trac has not seemed to help with education on the whole.
“The main point is the fact that many people can be involved in the review process, and then you have experienced reviewers who can show why some code is not good or needs improvement,” said Žoljom. “This provides a way for many people to see what is wrong with the code and how they can improve it. Plus the forked theme stays in their repo, so they can see the changes that they made and why.”
Žoljom has a few items in reserve for the long-term wish list. One possibility for the future may be setting up themes on Packagist for installation via Composer. He admits that it is a longshot at best.
“I see this as an opportunity to bring one aspect of WordPress up to par with other modern PHP frameworks like Laravel,” he said. “Plus, utilize automatic tools at our disposal. From PHP CodeSniffer, PHPStan, ES Lint, and a plethora of other tools, we could also show authors how they can set these tools on their projects and make their coding skills better. Maybe throw some automatic integration tests in the mix. The possibilities are really endless.”
All this sounds fabulous, even if you get to apply it, I don’t know to what extent I can review a theme less than 4 months for an approval, if this is not resolved it is not very useful to pass it to github if the slowness continues.