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
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
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.
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.