Discussion: Requirements for full site editing themes

As explorations of the minimum viable full site editing theme continues and the outreach program is starting, it is time to have a first discussion about requirements 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. themes in the theme directory.

Having basic requirements is one of the steps needed for us to be able to open up theme submissions:

  1. Requirements
  2. Update the Theme Check 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 to allow full site editing themes
  3. Strengthen reviewer knowledge
  4. Activate 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/ on the theme previewer -Completed

These are discussions points and not a complete proposal.

You can compare the items below with the current requirements.

New code requirements:

Valid 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. markup: There must be no block validation errors on theme switch.

For this requirement, we need to research if it is possible to validate the block markup automatically.

Minimum required files:

  • style.css
  • readme.txt
  • functions.php
  • index.htmlHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. (placed inside the block-templates folder)
  • Temporary: Comments.php is required as without it, a 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. http://php.net/manual/en/intro-whatis.php. warning is shown.
  • Theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. (or experimental-theme.json).

Requirements that may need to be adjusted:

Plugins: Themes are allowed to require Gutenberg as long as Gutenberg is needed to enable full site editing.

Options and Settings
Theme options may only be included as:

  • Theme_support
  • Global style settings
  • Block patterns
  • Block variations
  • Block styles

Items under this requirement that become irrelevant or confusing because blocks are used instead of PHP functions:

  • Use 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. for implementing theme options
  • Save options in a single array
  • Don’t use transients for things they shouldn’t be used for, like storing theme options
  • Use sane defaults and don’t write default setting values to the database

Presentation vs Functionality: Images that are not plain placeholder images and essential for the design are allowed.

Items under this requirement that become irrelevant or confusing because blocks are used instead of PHP functions:

  • The theme options should not be pseudo custom post types and save non-trivial user data
  • Non-design related functionality is not allowed

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Functionality and Features

Items under this requirement that become irrelevant or confusing because blocks are used instead of PHP functions:

If incorporated, features must support the WordPress functionality:  

  • Sidebars
  • Navigation Menus
  • Post Thumbnails
  • Custom Headers
  • Custom Backgrounds
  • Editor Style
  • Logo

Use template tags properly

Include comments.php (via comments_template())

Requirements that remain the same:

  • Licensing
  • 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) (temporary exception for skip to content link)
  • Readme file
  • Importing or downloading
  • Documentation
  • Naming
  • Screenshot
  • Image guidelines (exception for placeholder images that are essential for the design)
  • Stylesheets and Scripts
  • Privacy
  • Selling, credits, and links
  • Child themes

Requirements that it is not currently possible to follow:

Language / translation ready


Request for feedback

  • Which of the current requirements are relevant for full site editing themes?
  • What new full site editing specific requirements needs to be added?
  • How do we best present the requirements for full site editing themes?
    • On a separate page
    • In a separate section of the current requirements page
    • Other, describe your suggestion in the comment

#full-site-editing, #guidelines, #themes

New Project: Rewriting the requirements

Project description

Purpose

Making the requirements clear, easy to follow and easy to check.

Prerequisites

This project will not be starting with a blank slate, but make the best of what we have.

Tasks

In no particular order:

  • Review whether current requirements and recommendations are valid
  • Add new requirements when necessary
  • Reorganize requirements and topics
  • Rewrite requirements to make them easier to understand

 

Project format, mandate, timeline and meeting times

Suggested format

A smaller project group with a separate meeting time is preferred, that way the Theme Review Team can still hold the regular meetings on Tuesdays to discuss other topics.

Mandate

The group should have a mandate to change the wording of the requirements and examples with some exceptions:

Project leads/key reviewers should have access to making changes to the actual documents.

Major changes like completely removing a requirement should still be brought up during a Theme Review meeting.

Suggested meeting times

Every other Thursday at 19:00 CET,  alternating with the automation project meeting.

The Theme Review shindigs on the first Saturday of each month could also be used for longer meetings.

Timeline

The project would need to decide on partial goals, for example monthly or bi monthly milestones to ensure that the project moves forward.

Suggestions:

  • March 4 shindig: Requirements that have been voted on but not added,  should be added to the current requirements page.
  • In june, all requirements that are checked by the new Theme Check 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 should be separated from the rest of the requirements.

 


Our first meeting will be on Thursday, February 23 at 19:00 CET.

Agenda

  • Introduction
    • Let’s see who are interested in helping out.
  • How can we work on the requirements together?
    • How do we record and share our work in progress? Do we need any external tools?
    • Decide who our target audience is to be able to set a “tone” of our content and level of difficulty for the examples.
    • In what format do we present the requirements, keeping time limits and milestones in mind?
  • Decide priorities for march-april
    • Missing requirements (band-aids)
    • Reordering and regrouping current requirements

March 4 Shindig

Requirements that have been voted on but not added should be added to the current requirements page.


Our second meeting will be on Thursday, March 9 at 19:00 CET.

Agenda

  • Continue discussing any previous topics that were not finished during the last meeting.
  • Reordering and regrouping requirements
    • Is the requirement under the correct topic or does it need to be moved or placed under a new topic? We also have topics with only a few requirements that perhaps could be combined into one, like Naming and Screenshot.
    • Are there recommendations that should be moved to the required list? For example the Theme and Author URI.

#guidelines

Using Sane Defaults in Themes

With the release of WordPress 3.9, one of the changes to the Theme Review Guidelines is that Themes must use sane defaults. That means that Themes must not write default setting values to the database. For many Themes, this may seem like a major change; but it doesn’t have to be. This post will step through a few ways to implement sane defaults.

Portability/DRY

To make this method easier, put all of your defaults inside a function:

function themeslug_get_option_defaults() {
	$defaults = array(
		'option_1' => 'value_1',
		'option_2' => 'value_2',
		'option_3' => 'value_3'
	);
	return apply_filters( 'themeslug_option_defaults', $defaults );
}

(Note: by making the return valuable filterable, the Theme defaults can be easily overridden by a 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/. or 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.)

We’ll make use of this function later.

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

Most Themes use the Options API, and will use get_option() to put Theme settings into a global:

$themeslug_options = get_option( 'theme_themeslug_options' );

Knowing that this get_option() caall will return FALSE if the option has not yet been saved to the database, Theme developers have taken to saving default values to the database as part of Theme initialization, like so:

if ( false == get_option( 'theme_themeslug_options' ) ) {
	update_option( 'theme_themeslug_options', themeslug_get_option_defaults() );
}
$themeslug_options = get_option( 'theme_themeslug_options' );

But this is entirely unnecessary. And everything needed to implement a better solution already exists.

As a first step, consider that get_option() includes a second parameter, which specifies the default value to return, if nothing is returned from the database:

get_option( $name, $default );

So, the simplest solution is merely to tell get_option() to return the defaults, using the function we previously defined:

$themeslug_options = get_option( 'theme_themeslug_options', themeslug_get_option_defaults() );

This works, but isn’t perfect. It will return the Theme-defined defaults if the user hasn’t saved settings to the databse. But if later versions of the Theme add, remove, or change options, this might break, since the return value is either/or: either the database-saved setting, or else the defaults. So, if the user saves settings, and then a new setting is added in a later Theme version, the new setting value won’t be included in $themeslug_options unless/until the user saves settings again.

The solution is to merge the arrays, rather than to return one or the other. WordPress has a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. function specifically for this purpose: wp_parse_args(), which will use the settings array, and “fill in the blanks” with the defaults array:

wp_parse_args( $settings, $defaults );

Caveat: bearing in mind that wp_parse_args() expects both parameters to be arrays, and knowing that get_option() returns FALSE by default, be sure to specify get_option() returns an empty array by default: get_option( ‘theme_themeslug_options’, array() ); otherwise, wp_parse_args() will (might – see note below) choke if the user hasn’t saved settings to the database.

The construct will look something like this:

$themeslug_options = wp_parse_args( 
    get_option( 'theme_themeslug_options', array() ), 
    themeslug_get_option_defaults() 
);

This is perhaps the simplest, most elegant way to implement sane defaults.

(Note: according to Otto, passing an empty arrayy() as the second parameter to get_option() isn’t necessary. In his words: “The wp_parse_args() function checks for the first parameter to be an object or an array. If it’s neither, then it calls wp_parse_str on it, because it can take a GET URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org-like array of parameters too. The wp_parse_str() function calls 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. http://php.net/manual/en/intro-whatis.php.’s parse_str on it, and does a deep strip_slashes if magic quotes is on, then filters the result. So, because false maps to the empty string, parse_str will return an empty array for it, so passing false to wp_parse_args should be A-OK and probably has been like that for a very long time. Doesn’t hurt to add the empty array(), but doesn’t really change anything.” YMMV.)

Theme Modification API

Using the Theme Modification API (get_theme_mod()/get_theme_mods()) is fairly similar.

An individual setting can be called via:

get_theme_mod( $name, $default );

But perhaps more useful, all settings can be called via:

$themeslug_options = get_theme_mods();

Since get_theme_mods() returns an array, you can use the same technique as with Options API settings:

$themeslug_options = wp_parse_args( 
    get_theme_mods(), 
    themeslug_get_option_defaults() 
);

Portability/DRY (Part 2)

To be able to use this method throughout the Theme, wrap the wp_parse_args() call inside a function:

function themeslug_get_options() {
    // Options API
    return wp_parse_args( 
        get_option( 'theme_themeslug_options', array() ), 
        themeslug_get_option_defaults() 
    );
    // Theme Mods API:
    /*
    return wp_parse_args( 
        get_theme_mods(), 
        themeslug_get_option_defaults() 
    );
    */
}

Then, wherever you need access to Theme options:

$themeslug_options = themeslug_get_options();

From there, you can globalize $themeslug_options, or cache/transient it, etc. When you need to add a new option, simply add the new option default to the defaults array, and the Theme will handle it automatically.

#guidelines, #sane-defaults, #settings-api, #theme-mods-api

How To Ensure Your Ticket Passes Final Approval Audit

Over the past couple of months, the number of approved tickets that have been reopened due to issues found during final-approval audit has declined, but many still get reopened. As a team, we want to ensure that tickets get approved (so that new Themes get added to the directory, and into the hands of end users), and we want reviewers to be able to take advantage of the incentive program.

So I want to step through the things I check when performing a final review audit. We’re looking for some high-level and/or high-impact things that would cause problems for end users:

Overall File Structure

  • Does the Theme look like it is derived from a common Theme (Underscores, Twenty Ten-Fourteen, etc.)? Are there included functional files that I’ll need to check. Are there asset folders (fonts, scripts, etc.) that I’ll need to check?

style.css

  • Check ThemeURI and AuthorURI. Are they appropriate?
  • If ThemeURI or AuthorURI reference commercial Themes, are those Themes sold as 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?
  • If the Theme appears to be derived, does it include a proper derivative-work copyright/license attribution?

readme.txt

  • If the Theme has bundled resources/assets, are they listed in the readme with copyright/license attribution, or will I need to check file headers?
  • Is license for all bundled resources GPL or GPL-compatible?

header.php

  • Are Theme options properly escaped on output?
  • Is favicon, if used, disabled by default?
  • Does the TITLE tag include anything other than the call to wp_title()?
  • Does wp_nav_menu() reference theme_location, and not menu?
  • Are any stylesheet or script links output instead of being properly enqueued

footer.php

  • Does the Theme only use one credit link? Is that credit link exactly ThemeURI or AuthorURI, with no SEO-seeding of link text, title attribute, etc.?
  • Are any footer scripts output instead of being enqueued properly?

index.php

  • Does template markup look generally appropriate?

Front/Home Page Templates

  • Does the Theme have front-page.php? If so, is it used properly? Does it account for both a static page and the blog posts index as site front page?
  • Does the Theme have home.php? If so, is it used properly as the default blog posts index template?
  • Does the Theme have any custom page templates intended to be used as either front-page.php or home.php?

comments.php

  • Does the Theme properly output wp_list_comments() for the comments list?
  • Does the Theme properly output comment_form() for the comment reply form, rather than hard-coding the form?

page.php

  • Does the page template properly call comments_template()?

functions.php

  • Are all functions and other things in the public namespace properly prefixed?
  • Is all functional output properly wrapped in callbacks and hooked into appropriate actions?
  • Is any of the functionality 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 territory?
  • Does any of the functionality replicate coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. functionality?
  • Does the Theme use Theme options? Are they handled properly (single DB entry, proper settings page, sanitized on input, etc.)?
  • Do any of the Theme options replicate core options?

This list comprises 99% of what I look for in an audit, and accounts for the vast majority of issues encountered that require reopening tickets. So, if you verify these things before resolving the ticket as “approved”, the chances that your ticket will get reopened will go down considerably.

(Note: @emiluzelac may have other things to add to the list, for things he checks during an audit.)

#guidelines, #review-incentive, #review-process

Discussion: Theme Activation Standards

Currently, we are proposing a change to the Guidelines that would blanket-prohibit Themes from adding admin notices, redirects, or other similar functionality on Theme activation. The intent of the Guideline is to curtail the proliferation of nuisance/obtrusive Theme marketing in the user’s Admin.

In the vast majority of cases, such activation functionality should not be needed. Themes are required to use add_theme_page() to add a Settings page, which ensures that end users can always find the Theme’s settings page under the Appearance admin menu. The new requirement for sane defaults will ensure that Themes will always work “out of the box”, at least at a baseline (i.e. no-broken-sites) level. The recommendation for Themes to hook settings into 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. will help ensure that end users can visually preview Theme settings changes via the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Customizer (Appearance -> Customize). And the Contextual Help 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. ensures that Theme developers can add as much rich-text setup/configuration detail as necessary.

That said, there is still room for appropriate, standardized admin interventions on Theme activation. If we can agree on a consensus for standard admin interventions, then the Guidelines could reflect that consensus, and reviewers would have an objective standard to use when reviewing Themes.

So, let’s discuss. What’s appropriate? What isn’t? How can we define appropriateness objectively?

#guidelines