New requirements for settings pages & onboarding in themes

As discussed in our last meeting, we’d like to hear your thoughts on what should or shouldn’t be allowed when developing settings pages or onboarding processes in WordPress themes.

We’ve brainstormed a list of requirements, but we’d really value your input on this:


Admin notice / Theme activation

Themes must use the admin_notices hook to provide any custom messages to the user. These admin notices must either be a one-time message or permanently dismissible. This notice can be used to link to a settings page or start an onboarding process, for example. Popups are not allowed upon theme activation.

Admin page

Themes may optionally add custom sub-pages under Appearance in the WordPress admin. 

They should only contain coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WordPress UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. elements and generally match the WordPress admin design.

If necessary, themes can include custom styles or scripts for their admin pages, but they cannot leak/spill out to other WordPress admin pages. Enqueue styles/scripts on the admin_enqueue_scripts hook and use $hook_suffix parameter to determine the page.

For 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 admin pages, make use of Core components for features if they are available.

Additionally, themes must reference the correct user role capabilities when performing any action inside of the WordPress admin. They must also use an appropriate capability selector or function, such as canUser or current_user_can().

Inserting posts/pages via wp_insert|update_post() can be used if the action is done with user consent.

Options

Themes must use the Settings and Options APIs when storing custom settings in the database. 

Themes must also only add a single database option, which should be an array when storing multiple settings. This option must also be prefixed with the theme slug.

Themes may optionally custom core WordPress options that only affect the front-end and how the website displays (e.g., site logo, front page settings), as long as the user is notified that their saved options will be modified. User consent is required.

All data passed to add_option(), update_option(), or other functions for saving to the database must be validated and/or sanitized with the correct function or method for the data type.

Not allowed

The following features are not allowed as part of an admin menu or onboarding process:

  • Demo imports
  • External calls
  • Tracking/Affiliate links

As an example, you can check the Ollie Dash plugin. Based on a first review, we would not allow the child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. and updater functionality.

Our goal is to put these requirements into action starting from the first month of next year, immediately following our upcoming meeting on January 9, 2024. Meanwhile, we’d appreciate it if you could share your opinions.

Wishing you a Happy Holiday and a joyful New Year! 🙂

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

Summary: Let’s chat about WordPress 6.3 and block theming

On June 15, 2023, a Hallway Hangout was held to discuss the WordPress 6.3 roadmap, the major changes coming in the next release, and how they will impact building 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 managing themes from within the Site Editor. 42 community members attended, including the facilitator @ndiego

The meeting was recorded live over Zoom and is now available on WordPress TV:


The meeting began with introductions and a review of the 6.3 timeline and current roadmap, as well as the latest call for testing. The following resources were shared:

@ndiego then provided a demonstration of the major changes coming in 6.3, including the content editing flows in the Site Editor, the new Library, changes to the Query LoopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block, dimension controls, and improvements to navigation. There was also a discussion around the need for user permission controls in the Site Editor and more general extensibility.

These additional resources were shared:

The next Hallway Hangout will be held in July. The focus will be on extending block themes beyond what is available in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Stay tuned for the official announcement. In the meantime, you can test out the latest functionality coming to WordPress 6.3 by using Gutenberg 16.0 or by completing the latest FSE Program Testing Call #24: Momery Makeover.

#hallway-hangout

Summary: Curating the Editor and building block themes for clients

On May 25, 2023, a Hallway Hangout was held to discuss ways to curate the Editor experience in WordPress, building 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 challenges you might encounter when building with blocks for clients. 40 community members attended, including facilitators @ndiego and @greenshady

The meeting was recorded live over Zoom and is now available on WordPress TV:

The meeting began with introductions and a quick review of the timeline for 6.3 and Phase 3 of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. The following resources were shared:

@ndiego then provided a brief overview of the concept of “curation.” He then demonstrated new functionality in WordPress 6.2 that allows users to modify block settings in the Editor using client-side filters. This generated a lively discussion about the pain points builders are currently facing with block themes and additional functionality that’s needed.

One attendee asked how to restrict template part editing by user capabilities (roles). This included providing more granular access to the Site Editor. Attendees mentioned that they are hesitant to give clients full access to the Site Editor but want to provide them with some access. For example, some users need access to menus and specific template parts but nothing else.

Folks were excited about the upcoming changes to patterns. Partially synced patterns will address many pain points. One attendee noted that their agency explicitly does not use patterns currently since they cannot sync and easily update a pattern’s design.

The following resources were shared:

While time ran short, @greenshady also shared a quick preview of his new starter/educational theme, First Draft.

The next Hallway Hangout will likely focus on building block themes and will be announced here on the Make WordPress Themes blog. In the meantime, please share your thoughts in the comments about any pain points you’re currently experiencing or new functionality that would make building for clients easier.

Props to @greenshady for co-hosting the meeting and for feedback on this follow-up post.

#hallway-hangout

Meeting Notes | Themes Team and Theme Authors Regarding Requirements Change

Date: 28th July 2021

Purpose: This meeting was called to discuss the proposed requirements changes for themes. 

Meeting Video: WordPress.Tv

Attendees Themes Team:

  1. Ganga Kafle (@kafleg)
  2. Carolina Nymark (@poena)

Attendees Theme Authors:

  1. Shiva Shanker Bhatta
  2. Ashish Shrestha
  3. Theme Ansar
  4. Yam Chhetri 
  5. Ankit Dubey 
  6. Umesh Ghimire 
  7. Prashant 
  8. Quamruz Zaman

Meeting Overview: 

On July 20, the team published a Request for feedback on requirement changes.

In the post, Carolina mentioned that the themes team was going to do a Zoom meeting with theme authors, and asked participants to sign up.

The meeting started with an introduction. We increase the meeting time to 90 minutes. We did not cover all agenda items.

Attendees Questions and Concerns

The attendees were very interested in the future of themes, how to add support for FSEFSE Short for Full Site Editing, a project for the Gutenberg plugin and the editor where a full page layout is created using only blocks. to existing themes, and migrating custom widgets.

  • One of the attendees, Umesh Ghimire asked about making a hybrid theme (PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. + FSE). 
  • Shiva asked how to add full site editing support to existing themes.
    • Carolina replied that this is complex but that you can start adding partial support by adding a theme.json file to enable the Template Editing feature. Carolina added that she personally only recommends this for new themes because it can take time to update the existing CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site..
  • Will existing themes be required to convert to FSE? No.
  • Is there a future date when only FSE themes will be supported in the theme directory? No.

Discussion on proposed Requirements Changes

The themes team wants to know the theme authors’ opinions of the proposed requirements changes.

Most of the theme authors agreed and they didn’t find anything additional to remove from the requirements.

One of the proposals included allowing theme authors to use custom blocks in themes. We discussed how to migrate existing custom widgets to 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. patterns or blocks without breaking the website on the theme switch.

Further exploration and tests are needed to see if we can find a way to allow custom blocks in themes, no conclusion was reached at the current time.

Carolina recommended theme authors to use block patterns and block styles, but also to provide examples of converted widgets that we can test with.

Another proposal came up in the discussions for updating the theme page in the theme directory to make it more like the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party directory.

During the meeting, we went over a few guidelines one by one:

Single Themes Rule

Only submit one theme at a time.

@kafleg brought up trying to remove the single theme rule. Once theme reviews are automated, there will not be a queue, and then the rule has no purpose.

The participants preferred to keep the rule for now.

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Requirements 

Theme authors are fine with the current requirement and agree that it’s good to have these features in themes.

License of images

Participants brought up that it is difficult to find images that are GPLGPL GPL is an acronym for GNU Public License. It is the standard license WordPress uses for Open Source licensing https://wordpress.org/about/license/. The GPL is a ‘copyleft’ license https://www.gnu.org/licenses/copyleft.en.html. This means that derivative work can only be distributed under the same license terms. This is in distinction to permissive free software licenses, of which the BSD license and the MIT License are widely used examples. compatible and asked what licenses were allowed and if Unsplash images could be allowed.

@poena mentioned that there will be a new image service on 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/ where theme authors can download compatible images.

@kafleg mentioned that if anyone knows of image providers with compatible images, please share the links so that the team can add them to the list of recommended resources.

There was an additional question about images in the demo content. The themes team does not check the images that are used in external content. Theme authors are recommended to discuss possible implications with their own legal team before using and sharing any images that they have purchased or downloaded.

License of Icons 

Theme authors want to know if they can use trademarked icons such as social sharing icons in the theme screenshot.
The recommendation is to avoid them, and if there are take-down requests the theme may need to be temporarily removed until the screenshot is updated.

Updated screenshot requirements

There was a question about if a theme can display a design in the screenshot, that is not possible to create with the theme or with a free downloadable site or starter template.

Carolina replied that the team is loosening the screenshot requirements. That this screenshot in particular was probably missed because it is not possible for a reviewer to test all templates that are offered, especially if plugins need to be installed.

Readme file

There was a question about why the readme file is required and if there needs to be a changelog, or if the changelog can be remote.

-The changelog is not required now, but the plan is to display the readme file content in the theme directory, including the changelog.

Design and Code Copy 

All code and design should be your own or legally yours. Cloning of designs is not acceptable

The theme authors brought up that this requirement is unclear and it is too difficult to know what the themes team considers a design clone.

We discussed different scenarios and agreed that it is difficult to decide when a theme is too similar to another theme and if it brings value to the theme directory.

We talked about how we could make it easier to identify clones and how to report them.

No conclusion was reached on how to improve this requirement.

Anish Shrestha asked how much code theme authors can copy from another theme. We discussed how copying code is allowed as long as the license is respected and credits are included.

Manipulating the WordPress.org theme preview

Theme authors brought up that they were unsure of what this requirement refers to. Because violating this requirement can lead to suspension, it is especially important that the information is easy to understand.

The team will update the wording and add examples. An article about using the theme starter content with the preview will also be published.

Language and translation ready

Some theme authors wanted to remove, and others wanted to keep the translation-ready requirement as mandatory. No change to the requirement is planned.

Theme Check

The current version of the Theme Check plugin only works for parent themes.
Some theme authors were not aware about this limitation in Theme Check and were confused about why it shows more errors in the child themes. 

@kafleg made it clear that the theme check plugin only works for parent themes and not for child themes.


Wrapping up

The themes team wants more trust from theme authors regarding guidelines. The themes team expects quality themes from regular authors. But, authors who submit themes on a regular basis also missed the guidelines. 

We want theme authors to regularly attend meetings, contribute to automation tools (theme check and theme review action), and review themes. 

Carolina brought up that the team needs help with finding ways to remove more requirements. Some requirements are listed because there are limitations in WordPress and the theme directory, and can be removed if those limitations are lifted.

At last, thank you all for attending this zoom call and providing your feedback.

#meeting, #meeting-notes, #themes-team