In 2015, the Themes Team implemented a guideline that required all theme settings pages to use the Customize API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This was after the API had been in WordPress and stable for nearly three years.
There were two primary reasons for this:
- It meant that users could expect a standard options interface from any theme in the WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ theme directory.
- It simplified the review process because all the code was built on top of the exact same API. This made it easier to check for security issues, in particular, and shorten the time it took to review a theme.
Over the years, this guideline was generally accepted as the best path forward by members of the Themes Team.
In large part, the decision single-handedly cut out the vast majority of insecure settings pages that were being implemented in themes (mostly from a couple of copy-paste scripts that were popular around the web). That was a big win for theme authors, reviewers, and users. The importance of this change is not to be taken lightly and is very much at the forefront of any discussion around theme settings.
Fast forward to today—now eight years later. The Themes Team is at another pivotal moment that could partially shape what the theming landscape looks like for years to come.
A new era: block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes and custom settings screens
When the customizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. guideline was introduced, it was during the classic theming era. There was no concept of block themes at the time. While it is possible for a block theme to use the Customize API today, it is no longer part of the expected user experience for users who have activated a block theme.
In fact, there’s no real expectation that a block theme will have any settings screen at all outside of what’s possible via Appearance > Editor in the admin.
The discussion: feedback wanted
In the October 10, 2023 meeting, the Themes Team began the discussion on what to do about the settings page requirement going forward. The decision from that meeting was to open the discussion up for feedback from the wider community.
The Customize API requirement is well established for classic themes, so this discussion is solely focused on block themes.
- Should the team loosen the requirement on the current settings page requirement for block themes, allowing experimentation with React components?
- If so, what guardrails—if any—should be put in place on what themes can do?
It’s also important to frame this conversation within the overall guidelines and not get into the weeds of unrelated topics. For example, settings would still need to fall within “theme territory” (i.e., they should be related to design). The decision that needs to be made is focused solely on the settings page guideline:
Use the Customizer for implementing theme options.
Now the floor is yours. How would you handle the settings page guideline for block themes going forward?
Props to @kafleg and @ndiego for feedback and review on this post.