Discussion: How to handle custom settings screens in block themes

In 2015, the Themes Team implemented a guideline that required all theme settings pages to use the Customize APIAPI 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.orgWordPress.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: blockBlock 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 customizerCustomizer 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.

Now that the block theming system and the Site Editor are about seven months out of betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process., it means that theme authors will continue building more and more block themes. And with that, the Themes Team should expect to see more experimentation around this new paradigm. There really is no guidebook on what to expect as theme authors try to solve both old and new problems in a world that is heavily based on the block system and modern JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/..

In particular, the expectation is that theme authors will begin trying new things with ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.-based JavaScript components that are bundled with WordPress. Not only are interfaces changing, but the underlying programming language now involves much more JavaScript.

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.

The questions:

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

The other thing to be aware of is that any decision to loosen that specific guideline can impact active reviewers. That means making sure that they are up to date on modern WordPress JavaScript coding standards and can handle an upward trend of more themes with heavier JavaScript code bases. Otherwise, the progress over the last few years to have a faster review queue could also be lost. With that in mind, it’s important for any active reviewer to voice any concerns about any potential changes.

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.

#discussion-topic, #guidelines