Proposal: Retiring Older Default Themes

Since 2010, WordPress has released a new default theme every year but one. Each default theme (though sometimes stylistically opinionated) is meant to provide a solid and flexible foundation that site owners can use to build out their new WordPress site.

Though only the three most recent bundled themes are included in new WordPress installs, all 13 of the default “Twenty” themes are currently actively maintained. The level of effort to support 13 themes is not insignificant, especially in the times of the rapidly evolving 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. editor. The burden of maintaining these themes has historically fallen on the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team to ensure they continue to receive any needed updates.

Because there are so many, it’s not uncommon for it to take several months before older default themes properly support newer features added in WordPress Core. Additionally, themes created prior to the existence of certain APIs are often unable to fully take advantage of these new features (global styles, block patterns, etc.).

Trimming the number of default themes actively supported will allow contributors to be more effective at providing the best possible experience in modern WordPress through the block editor for sites using newer default themes. It also helps clear the path for work on new block theme-focused experiments and initiatives (such as the Community Themes Initiative) attempting to refine the role that themes will have in the block editor era.

This post summarizes the current state of bundled themes in WordPress before proposing new support states for bundled themes, as well as two potential ways to decrease the total number of themes receiving regular updates.

Documentation and Data

Before proposing any changes to the bundled theme support policy, it’s important to fully document the current state of bundled themes, how they are maintained, and the bundled theme life cycle (which can roughly be divided into three stages).

Bundled Theme Life Cycle

  1. Build Out: Once per year, a new default theme is announced and planned in coordination with a major version of WordPress (typically the final one of the calendar year). A small team of contributors build each theme out on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ over the course of 1-3 months before it’s merged into the WordPress Core SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. code base for release and future maintenance.
  2. Active Default Theme: The theme is released with the next major version of WordPress where it receives its time in the spotlight being activated as the default for all new sites. The original theme authors typically continue to work on improving the theme and fixing bugs during this stage. Active default themes are usually the first bundled theme to receive support for new features added to Core. Every effort is made to ensure full support when the next version of WP is released within reason and where appropriate. The active default theme ideally shows the full capability of what WordPress can do.
    Note: “active” default theme is currently not an officially recognized designation.
  3. Maintenance: The next default theme is built and merged into Core and activated for new sites. The previous theme continues to be maintained, but those involved with creating it often are not able to keep up with maintaining it long term, or are assigned to other projects and initiatives. Bundled Theme component maintainers and other Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. become almost entirely responsible for maintaining the theme, in addition to all others that came before it.

Defining Maintenance

Maintenance means many things in different contexts. Here is an incomplete list of typical maintenance currently required by and performed on bundled themes in no particular order:

  • Ensuring compatibility with new versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher.
  • Fixing reported bugs.
  • Adjustments to code utilizing pre-existing WordPress APIs and functions to prevent additional bugs.
  • Deprecations related to jQuery and other 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/. Library updates.
  • Utilizing new functions, APIs, or best practices as necessary.
  • Changes required to adhere to new and more modern web standards and requirements.
  • Adding support for new features in the block editor and throughout Core.
  • Updating npm dependencies and build scripts.
  • Security updates.
  • Curating changelog updates.
  • Bundling, testing, and pushing releases to the theme directory.

Along with these maintenance tasks, there are some factors that need to be considered and make 

  • When themes are built, they target support for specific browsers and versions. This does not change over time and the support policy is “locked in” for the life of the theme. As an example, older bundled themes likely still contain code that specifically targets IE6-9. It’s usually not worth the effort and risk to remove this code because it’s impossible to anticipate the impact in the wild, especially for any child themes that have been created.
  • The minimum version of WordPress required for default theme when released is set to the version of WordPress it is initially released with and does not change. As an example, Twenty Ten still technically supports back to WordPress 3.0.
  • Shipping patterns in themes that support WordPress 5.0 and up is particularly complicated since valid block syntax changes over time (see #53617 for an example).
  • Adding support for new features is not always straightforward and takes a substantial amount of time to test, especially for older themes (see #56487 for an example).

Current Default Theme Usage

Another important factor to consider before making any changes to a support policy is overall usage. Here is a rough breakdown of the active install counts for the “Twenty” default themes (according to 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/) as of April 26, 2023 (note: this does not include sites running child themes of any “Twenty” themes):

  • Twenty Ten: 90,000+ installs (~0.3%)
  • Twenty Eleven: 100,000+ installs (~0.4%)
  • Twenty Twelve: 90,000+ installs (~0.3%)
  • Twenty Thirteen: 50,000+ installs (~0.2%)
  • Twenty Fourteen: 100,000+ installs (~0.35%)
  • Twenty Fifteen: 100,000+ installs (~0.45%)
  • Twenty Sixteen: 100,000+ installs (~0.7%)
  • Twenty Seventeen: 700,000+ installs (~2.5%)
  • Twenty Nineteen: 200,000+ installs (~1%)
  • Twenty Twenty: 600,000+ installs (~2%)
  • Twenty Twenty-One: 800,000+ installs (~3%)
  • Twenty Twenty-Two: 800,000+ installs (~3%)
  • Twenty Twenty-Three: 1M+ installs (~3.5%)

Some interesting findings:

  • Twenty Thirteen is the least used default theme at roughly 50,000 installs (0.2%).
  • Twenty Fifteen and older are all active on less than 0.5% of all WordPress sites each. Cumulatively they account for slightly more than 2% of all sites.
  • Twenty Sixteen and older all have less than 1% of all installs.
  • Twenty Twenty-Three is currently the most used default theme active on 1M+ sites.
  • Twenty Twenty through Twenty Twenty-Three all have roughly 2% of all sites or more each, cumulatively accounting for nearly 12% of all sites.
  • Twenty Seventeen through Twenty Twenty-Three accounts for 15% of all sites.

Defining and clarifying the different default theme states

This proposal is also a good opportunity to refine and clarify what the different states of bundled themes are before deciding if any default themes should be retired. Currently, there is only “actively maintained”. In order to retire older themes, there needs to be a new retired state defined. It would also help to have an intermediary state (similar to long-term support or LTS) where some support and maintenance is performed, but not all.

Actively supported state

This state is for all themes included with new WordPress installs (three most recent). Ensuring the themes in this state are fully compatible with the latest version of WordPress when released is top priority. Themes in this state will receive:

  • All types of bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes.
  • All types of compatibility fixes (PHP, WP, etc.).
  • Support for all new features added to WordPress (when they are relevant).
  • Security updates.
  • Changes to utilize new functions or APIs.
  • Changes to adhere to best practices or modern web standards.

Maintained state

This state is for all themes that have not yet met the requirements for retirement but are no longer included with new WordPress installs. Themes in this state will receive:

  • All types of bug fixes.
  • All types of compatibility fixes (PHP, WP, etc.).
  • Security updates.

Retired theme state

These themes have met the requirements for retirement and are no longer actively maintained. Themes in this state will receive:

  • No new enhancements, features, or bug fixes.
  • Security updates.

In addition, the “Tested up to:” value will no longer be updated with each WordPress release. Any tickets currently open on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for a theme being placed in the retired state will be scrubbed and closed. 

Retiring older bundled themes

Regardless of which methodology is used to identify when themes should be retired, the following points should be considered:

  • Policies can always be altered as themes and WordPress continue to evolve. What constitutes a theme currently evolving being re-explored. Any support policy set after discussion can always be revisited in the future with new context.
  • A review of the actively supported themes will be conducted annually. After a new default theme is built and released, the list of default themes will be reviewed using the criteria chosen from this proposal. When a theme qualifies for retirement, a proposal will be made on the Making WordPress blogblog (versus network, site). Barring any compelling evidence that the theme should continue to remain in maintenance state, the open tickets for it will be scrubbed and closed appropriately and the theme will be retired after the next major WordPress release.

Proposed Criteria for retiring bundled themes

The following criteria is proposed as the requirements to retire a bundled theme:

  • Themes must be supported for a minimum of 5 years. Even if a bundled theme is not widely used, it must be actively supported for at least 5 years.
  • Themes must be active on fewer than 1% of all WordPress sites (as determined by WordPress.org data).

Themes that would be retired today with this criteria:

  • Twenty Ten
  • Twenty Eleven
  • Twenty Twelve
  • Twenty Thirteen
  • Twenty Fourteen
  • Twenty Fifteen
  • Twenty Sixteen

Themes that would be moved to maintained status

  • Twenty Seventeen
  • Twenty Nineteen
  • Twenty Twenty

Themes that are actively maintained (currently shipped with WordPress)

  • Twenty Twenty-One
  • Twenty Twenty-Two
  • Twenty Twenty-Three

This proposal uses a minimum percentage of active installs as the criteria for retiring default themes.

While percentages like 1% may seem low, it’s important to call out that when applied to WordPress installs, even 1% equates to a few hundred thousand sites. As more new WordPress sites are created and this number is greater, the policy can be revisited and altered if necessary (see above).

Pros

  • Brings the number of actively supported themes from 13 to 6.
  • Drops support for themes with an outdated aesthetic (less emphasis on visual elements, content visually “contained” within a boxed layout, etc.).
  • Results in both fully block-based themes (2) and some classic-style themes (4) being actively supported or maintained.
  • Establishes a clear criteria for an annual review going forward.
  • Reduces the maintenance burden for 3 themes by refining what it means to be maintained vs. actively maintained.

Cons

  • A non-zero number of WordPress sites currently use these themes (roughly 730,000).

Conclusion

This post presents a thoroughly refined recommendation as a result of feedback from several contributors listed below. However, it is only a proposal and is not concrete. Adjustments can be made to this proposal based on feedback from contributors in the comments below. If you have any thoughts, please do leave them below!

Unless there is a need to republish a modified version of this proposal for further feedback, after a consensus is reached and any needed approval from leadership to implement this proposal is received, the following action items would need to be addressed:

  • The Making WordPress Core handbook should be updated in the appropriate places to outline the annual process to review for retirement candidates.
  • Contributors should scrub all tickets for themes being retired and either close them out with a message why, or complete them before the theme retirement date.
  • A post on WordPress.org/news announcing the retirement of any themes being retired and clarifying what that means.
  • Any other action items identified while discussing this proposal.

Props @jeffpaul, @flixos90, @poena, @annezazu, @jorbin, @chanthaboune, @joemcgill, @azaozz for contributing to this post through providing feedback and proof reading.

#bundled-theme, #themes

WordPress 6.2 Performance improvements for all themes

With the latest WordPress release out in the world, this post seeks to recap the performance improvements available for all sites. According to this analysis done by @flixos90 that you’re encouraged to dig into, WordPress 6.2 loads 14-18% faster for 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 2-5% faster for classic themes. Server-side performance is seeing a major boost of 17-23% for block themes and 3-5% for classic themes. These changes demonstrate WordPress’s continued commitment to ensuring that websites built on the platform are optimized for performance.

This builds on efforts done in the past that you can read about in the following posts: Need for Page/Post Speed and Performance Matters.

Thank you to @oandregal and @flixos90 for collaborating on this post!

What’s changed

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

Leading up to WordPress 6.2, theme.json related code received more performance related attention partially thanks to an understanding that this newer configuration file has an important role to play in the future of themes. This work aimed to improve Time To First Byte (TTFB), a metric related to server-side performance. It focused on three aspects:

According to this analysis, caching wp_get_global_settings had the most impact in the release, improving classic themes by 9% and block themes by 24%. For context, while wp_get_global_settings was introduced in WordPress 5.9, it’s usage expanded to cover many more use cases, including querying data for rendering front-end blocks. As a result, it benefitted immensely from caching the response.

Lazy-loading images for block themes

While Time To First Byte (TTFB) was a big focus of the 6.2 release, there was also a major change to Largest Contentful Paint, the main user-perceived performance metric: the first image or iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. of the post will no longer be lazy loaded for block themes.

As a reminder, lazy-loading images landed in WordPress 5.5. After an analysis reported that lazy loading images above the fold negatively impacted user-perceived performance, a fix landed in WordPress 5.9 with WordPress 6.2 following up to ensure block themes won’t lazy load the first image or iframe.

Front-end metrics

Outside of the work done to directly improve performance, there was also a focus on making front-end metrics readily available to all. The aim being to ensure developers have the necessary information to make new features performant and catch regressions earlier, all aiding in creating performant future major releases. All Pull Requests in the Gutenberg and wordpress-develop repositories now include front-end performance information. This information is also reported in the following places for a more comprehensive look:

  • The Gutenberg dashboard now collects a number of front-end metrics:
    • Largest Contentful Paint (LCP): tracks the overall user-perceived performance.
    • Time To First Byte (TTFB): tracks server-side performance.
    • LCP-TTFB: tracks client-side performance.
  • There is a new WordPress core dashboard that reports the following server-side metrics:
    • Total: tracks server-side performance. Equivalent to TTFB in the 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/ dashboard.
    • Before template: tracks the time it takes to dispatch the template_redirect hook.
    • Template: the difference between total time and the time it took to dispatch the tempate_redirect hook.

Get involved

If you’re interested in working on improving performance across the project, make sure to join #core-editor, #core-performance, and attend meetings for both. 

These “CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor Improvement…” posts (labeled with the #core-editor-improvement tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.)) are a series dedicated to highlighting various new features, improvements, and more from Core Editor related projects. 

#block-themes, #core-editor-improvement, #performance, #themes

Multisite registration and activation pages have new HTML and CSS

In WordPress 6.1, the forms for the wp-signup.php and wp-activate.php pages have several enhancements to both the markup and the styles.

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)-related improvements

Indicating relationships:

  • Fieldsets, with visible legend text, group the radio buttons.
  • Form field description information connects to its related field with aria-describedby.
  • When present, error messages also connect to their field with aria-describedby. The generic error has an ID in case custom fields should refer to that.

Preventing errors:

  • Required text fields have the required attribute.
  • The Site Name label indicates that users should enter the subdirectory only, and the Site Domain is only the desired subdomain.
  • The Username field’s description text now specifies that letters need to be lowercase.

Color contrast:

  • If the activation page has an error message, its default dark gray text color contrasts against the light background.
  • The default style for links within the registration page’s bordered message (.mu_alert) includes an underline and matches the text color of the rest of the message. For example, Twenty Twenty-One’s dark mode assigns a light link color, so the new style makes it readable and identifiable as a link. If a theme uses a bottom border or box-shadow on links, however, this underline could be inappropriate.
“Options page” link had light gray text in Twenty Twenty-One’s dark mode
Links were sometimes difficult to see
“Options page” link is in the same dark gray text as the rest of the message
Links match the surrounding text color, underlined, in 6.1

New elements and styles for the registration page form

  • The fieldset and legend elements reset margin, padding and border properties.
  • The legend styles are consistent with the default label font size, weight and margins.
  • Radio buttons are inside paragraphs without a top margin, following the legend.
  • Text input fields and the submit button, which were set to 100% width plus padding, are only as wide as their container now.
screenshot of account setup page in WordPress 6.1
New account setup, step 1, allowing both sites and usernames

When people create an account:

  • Descriptive text for the Username and Email Address is inside paragraph tags. Because these immediately follow the input, the paragraphs do not have a top margin.
  • Options for creating a site and/or a username are grouped in a fieldset with a new, visible legend.
  • Elements with the “wp-signup-radio-button” class wrap these options’ radio buttons and their labels, and with “display: block” the options stack vertically.
screenshot of form with Site Name (for subdirectory installations), Site Title, Site Language and Privacy options
Form fields for an administrator (logged in) to create a new site

When an administrator creates a new site:

  • A “wp-signup-blogname” container wraps the Site Name (or Site Domain) input with the domain, so themes could arrange them side-by-side.
  • For right-to-left languages, the domain and its input field remain in the left-to-right direction.
  • The “privacy-introfieldset uses paragraph tags inside it to retain most paragraph styles from the theme.
  • By wrapping “Privacy:” in a “label-headingspan, it appears above the rest of the legend. This text maintains the same default font size and weight given to the legend and label elements.
  • The “Yes” and “No” labels have moved next to the radio buttons, instead of inside them. Without the strong emphasis tags, these can match the default label font weight of 600. If any theme overrides the “.mu_register label.checkbox” selector to block display, that property will need updating to an inline style.
  • In this fieldset, “wp-signup-radio-button” containers remain next to each other, with a small margin between them.

Site activation page styles

screenshot of site activation page with Twenty Twenty theme
  • The activation form’s container is centered, to match the signup page.
  • The input field and submit button cover the full width of the container, with box-sizing: border-box to prevent them from extending beyond 100%.
  • The form and .error selectors now include .wp-activate-container so that the styles do not affect elements in the headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. or footer.

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

This is not new to 6.1, but block themes should continue to include header.php and footer.php template files for these pages. To make a header template more specific to the networknetwork (versus site, blog) pages, its filename can be header-wp-signup.php or header-wp-activate.php.


For more information about the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. and CSSCSS Cascading Style Sheets. changes, view tickets #40361 and #54344.

Props: Thank you, @ironprogrammer, @webcommsat, @audrasjb and @joedolson, for peer review and editing.

#accessibility, #core-multisite, #dev-notes, #dev-notes-6-1, #multisite, #themes

Reference Styles values in theme.json

With WordPress 6.1, theme developers can style elements with references from other settings.

Theme designs often require consistency in the styles applied to blocks. This can be achieved by setting Styles properties which are inherited by blocks using the inheritance of the CSSCSS Cascading Style Sheets. cascade. In some cases blocks want to apply settings from Styles to a different property of the 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. – for example the button element might want to use the global text color for its background color and the global background for its text color.

To solve this problem, themes need to be able to share Styles settings with blocks. This will make it easier for users to update these shared properties across all their blocks. Again, as example for button element the developer wants to use the text color for its background. If the button element is set up as in the example above, then when a user edits the global text color, the background color of their buttons will also be updated, too.

To achieve this, a new ref property was added to 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. which allows one property to set itself to the value of another, for example defining this for button elements:

"elements": {
	"button": {
		"color": {
			"background": {
				"ref": "styles.color.text"
			},
			"text": {
				"ref": "styles.color.background"
			}
		}
	}
}

Styles will convert {ref: "styles.color.background"} the value at: styles > color > background in theme.json.

Limitations

It is currently only possible to use ref to get one value from theme.json; a ref value cannot point to another ref. This also prevents circular refs from causing problems.

Props to @bph and @webcommsat for review of this post.

#6-1, #dev-notes, #dev-notes-6-1, #styles, #themes

Theme-focused changes and filters in WordPress 5.9

A few theme-related notes are already published in the Miscellaneous Core Changes developer note, including:

  1. The comment text field is now marked as required, and some themes that have special styling for the asterisk or that create a custom logged_in_as or comment_notes_before message may have a reason to update.
  2. The role="navigation" attribute is removed from <nav> elements.

The following changes are especially relevant to theme authors as well.

A CSSCSS Cascading Style Sheets. custom property to offset the adminadmin (and super admin) toolbar height

This new custom property, --wp-admin--admin-bar--height, reflects the admin bar’s height and adjusts responsively on smaller screens. Offsetting content can prevent the admin bar from overlapping it, without needing to copy the media query.

Adjusting for fixed headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. navigation

When clicking “Continue reading” or “Skip to content” links, a header fixed to the top of the page can cover where that content starts.

With the --wp-admin--admin-bar--height CSS variable and scroll padding, modern browsers can compensate for the admin toolbar (when it shows). The toolbar offset of 32 or 46 pixels—depending on screen width—is available on the front end without editing the theme:

html {
	scroll-padding-top: var(--wp-admin--admin-bar--height);
}

Themes that have a fixed header element can add to that. For example, Twenty Seventeen has a fixed header 72 pixels tall, so the scroll padding for the theme includes that measurement:

html {
	scroll-padding-top: calc( var(--wp-admin--admin-bar--height, 0px) + 72px );
}

Twenty Sixteen does not have a fixed header, but the border styling requires a little more scroll padding because it uses a pseudo-element on the body:

html {
	scroll-padding-top: calc( var(--wp-admin--admin-bar--height, 0px) + 21px );
}

For more information, see TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets #52623 (CSS variable) and #46371 (scroll padding for anchor links).

Custom header image attributes

Alternative text is customizable (and the alt attribute is empty by default)

Custom header image markup now applies the alternative text assigned to the image (in the Media Library). The alternative text was always the site title, which is not relevant in most use cases. The header image is often decorative only, so the attribute is empty when the text is not supplied.

This affects the following functions:

  • get_header_image_tag()
  • the_header_image_tag()
  • get_custom_header_markup()
  • the_custom_header_markup()

If a theme allows linking the header image (for example, with the get_header_image_tag filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.), restoring the site title as backup alt text could prevent “empty link” 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) errors.

function linked_header_image_markup( $html, $header, $attr ) {
    // This variable might be a theme option instead.
    $header_image_link_option = home_url( '/' );

    $output = '';
    if ( ! empty( $header_image_link_option ) ) {
        $output .= '<a href="' . esc_url( $header_image_link_option ) . '">';
        // Replace empty alt text with site title when image is linked.
        $output .= str_replace( 'alt=""', 'alt="' . esc_attr( get_bloginfo( 'name' ) ) . '"', $html );
        $output .= '</a>';
    } else {
        $output .= $html;
    }

    return $output;
}
add_filter( 'get_header_image_tag', 'linked_header_image_markup', 99, 3 );

New attributes filter

The get_header_image_tag_attributes hook allows developers to filter the attributes of the header image HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) before they are escaped, concatenated, and returned in the get_header_image_tag() function.

Filtering with this hook externally and preemptively intercepts the array of attributes, in a manner similar to the wp_get_attachment_image_attributes hook.

Adding classes is one possibility:

function header_image_add_class( $attr ) {
    if ( isset( $attr['class'] ) ) {
        $attr['class'] .= ' special classes';
    } else {
        $attr['class'] = 'special classes';
    }
    return $attr;
}
add_filter( 'get_header_image_tag_attributes', 'header_image_add_class', 10, 1 );

If an attribute should change due to part of the $header object, the filter has a second argument:

function header_add_data_thumbnail_url( $attr, $header ) {
    if ( ! empty( $header->thumbnail_url ) ) {
        $attr['data-thumbnail'] = $header->thumbnail_url;
    }
    return $attr;
}
add_filter( 'get_header_image_tag_attributes', 'header_add_data_thumbnail_url', 10, 2 );

For more information, see Trac tickets #46124 (alt attribute) and #38942 (filter).

Note that this pertains to the Classic RSS widget; the 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.-based RSS widget does not include the icon.

With the new rss_widget_feed_link filter, some people may remove or replace the markup for the icon link instead of hiding it with CSS. This can prevent accessibility errors such as empty links, or it can simply remove undesired markup.

If the image is hidden but not the link, that can result in an empty link. A theme that hides .rss-widget-icon in the styles can update the stylesheet with an additional .rss-widget-feed selector.

.widget_rss a.rsswidget .rss-widget-feed,
.widget_rss a.rsswidget .rss-widget-icon {
    display: none;
}

If the theme uses :first-child or :first-of-type to target the feed link, including :not(.rss-widget-title) can support people using the filter as well as people still using older versions of WordPress.

For example, Twenty Seventeen floats the link to the side:

.widget_rss .widget-title .rsswidget:first-child:not(.rss-widget-title) {
    float: right;
}

Twenty Twenty hides the link, when it is in the markup:

.widget_rss .widget-title a.rsswidget:first-of-type:not(.rss-widget-title) {
    display: none;
}

Themes and plugins can remove the icon link with the rss_widget_feed_link hook:

add_filter( 'rss_widget_feed_link', '__return_false' );

For Twenty Twenty-One, the after_setup_theme action contains the filter.

For theme authors who want a custom image or some other change, the filter also allows new content.

function remove_link_from_rss_widget_image( $feed_link ) {
    $feed_icon = includes_url( 'images/rss.png' );
    $feed_link = sprintf(
        '<img class="rss-widget-icon" style="border:0" width="14" height="14" src="%1$s" alt="%2$s"%3$s /> ',
        esc_url( $feed_icon ),
        esc_attr__( 'RSS' ),
        ( wp_lazy_loading_enabled( 'img', 'rss_widget_feed_icon' ) ? ' loading="lazy"' : '' )
    );

    // Output is the image without the link, but this replaces both the link and the image.
    return $feed_link;
}
add_filter( 'rss_widget_feed_link', 'remove_link_from_rss_widget_image', 10, 1 );

Additional revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. to the default output

  1. Themes can style the feed link with the rss-widget-feed class and/or the title link with rss-widget-title, as long as they require at least 5.9.
  1. The image includes the lazy loading attribute when support is declared, either in all situations or specifically in the rss_widget_feed_icon context. 
function disable_rss_widget_image_lazy_loading( $default, $tag_name, $context ) {
    if ( 'img' === $tag_name && 'rss_widget_feed_icon' === $context ) {
        return false;
    }
    return $default;
}
add_filter( 'wp_lazy_loading_enabled', 'disable_rss_widget_image_lazy_loading', 10, 3 );

For more information, see Trac ticketticket Created for both bug reports and feature development on the bug tracker. #52224.


Thanks @ryelle for help with the toolbar section, and thanks to @joedolson and @ryokuhi for reviewing.

#5-9, #dev-notes, #themes

Register theme feature API

Themes use the add_theme_support 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. to declare support for a particular theme feature. For instance, add_theme_support( 'align-wide' ) declares that a theme supports the wide alignment feature.

When the Themes REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. controller was introduced in WordPress 5.0 , a minimal set of theme features were exposed (see #45016). In WordPress 5.4, this was expanded to all WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. theme features (see #49037). Support for custom theme features was not included because there was not a safe way to validate their shape and ensure the associated data was not private.

In [48171] the new register_theme_feature() API was introduced to declare the format of a theme feature. This does not indicate that the current theme supports that feature, merely that it is available to be supported.

Features that are registered with show_in_rest enabled will have the add_theme_support() value exposed in the REST API themes endpoint. This allows for 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 developers to access the theme support values over the REST API. Currently, the REST API is the only consumer of the registered theme features.

WordPress Core registers the list of built-in theme features in the create_initial_theme_features() function.

The API

The register_theme_feature() function takes two arguments. The first, $feature, is the name uniquely identifying the feature. The second, $args, is a list of arguments detailing the feature. If the feature is successfully registered, the function will return true. Otherwise, a WP_Error instance is returned.

Type

The type argument specifies the 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. Schema type of the value that should be passed to add_theme_support(). The acceptable values are string, boolean, integer, number, object and array.

The object type refers to a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher associative array (an array of key, value pairs). The array type refers to a PHP numerical array, in other words a list of values without specific keys.

Variadic

The variadic argument specifies whether the feature utilizes the variadic argument support of add_theme_support(), or if the feature is entirely described by the first argument. Theme features in Core aren’t variadic.

add_theme_support( 'html5', array(
	'search-form',
	'comment-form',
) );

If the html5 feature was variadic, add_theme_support() would be used like this.

add_theme_support( 'html5', 'search-form', 'comment-form' );

Description

The description argument is meant to be a short description of the feature intended for developers. The REST API surfaces this description in the schema for the Themes API.

Show in REST

By default, theme features are not included in the REST API. To opt-in to this behavior, the show_in_rest flag can be set to true or an array with additional arguments to describe the feature.

Schema

The show_in_rest.schema argument specifies the JSON schema describing the format of the feature. If the feature type is an object or array specifying a schema is mandatory.

For an array type, the schema should contain an items definition that describes the format of each entry in the array. For example, the html5 theme feature is described with the following schema.

array(
	'items' => array(
		'type' => 'string',
		'enum' => array(
			'search-form',
			'comment-form',
			'comment-list',
			'gallery',
			'caption',
			'script',
			'style',
		),
	),
)

For an object type, the schema should define each of the properties of the object that should appear in the REST API. This isn’t always every field that can be registered. For instance, the custom-header omits the various callback flags because they aren’t safe to include in the REST API.

array(
	'properties' => array(
		'default-image'      => array(
			'type'   => 'string',
			'format' => 'uri',
		),
		'random-default'     => array(
			'type' => 'boolean',
		),
		'width'              => array(
			'type' => 'integer',
		),
		'height'             => array(
			'type' => 'integer',
		),
		'flex-height'        => array(
			'type' => 'boolean',
		),
		'flex-width'         => array(
			'type' => 'boolean',
		),
		'default-text-color' => array(
			'type' => 'string',
		),
		'header-text'        => array(
			'type' => 'boolean',
		),
		'uploads'            => array(
			'type' => 'boolean',
		),
		'video'              => array(
			'type' => 'boolean',
		),
	),
)
Default

The show_in_rest.schema.default argument can be used to specify an alternate default value to be shown in the REST API if the current theme does not support the registered feature. By default, the feature will have a value of false. The post-formats feature declares a default of [ 'standard' ].

Name

The show_in_rest.name argument can be used to specify an alternate property name for the feature when it is displayed in the REST API. For example, the post-formats feature declares a name of formats.

Prepare callback

The show_in_rest.prepare_callback argument can be used to customize how the feature is formatted in the REST API. By default, the REST API sanitizes the raw value from get_theme_support according to the specified schema.

The post-formats feature uses a custom prepare_callback to ensure that standard is always included as a supported post format.

function ( $formats ) {
	$formats = is_array( $formats ) ? array_values( $formats[0] ) : array();
	$formats = array_merge( array( 'standard' ), $formats );

	return $formats;
}

The prepare_callback function receives the following parameters.

  1. The raw feature value from add_theme_support().
  2. The args describing the feature from register_theme_feature().
  3. The feature name.
  4. The WP_REST_Request object being responded to by the REST API.

Example

This example registers the editor-color-palette theme feature. Theme features should be registered on the setup_theme action.

function myplugin_setup_theme() {
	register_theme_feature( 'editor-color-palette', array(
		'type'         => 'array',
		'description'  => __( 'Custom color palette if defined by the theme.' ),
		'show_in_rest' => array(
			'schema' => array(
				'items' => array(
					'type'       => 'object',
					'properties' => array(
						'name'  => array(
							'type' => 'string',
						),
						'slug'  => array(
							'type' => 'string',
						),
						'color' => array(
							'type' => 'string',
						),
					),
				),
			),
		),
	) );
}
add_action( 'setup_theme', 'myplugin_setup_theme' );

For more information, refer to the related ticketticket Created for both bug reports and feature development on the bug tracker. on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (#49406).

Props @desrosj and @justinahinon for reviewing.

#5-5, #dev-notes, #rest-api, #themes

Controlling the Block Editor

One of the important use-cases of the 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.-editor is the possibility to control the experience programmatically. Controlling the experience means allowing agencies and developers to configure or restrict the usage of the different features available in the editor. This has always been one of the priorities while adding features to 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/ and it will continue to be.

As of today (included in WordPress 5.3), the block editor comes with a number of 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. to achieve this:

Blocks

Blocks are the main extensibility API of the editor. Thus, developers have the possibility to register custom blocks but they can also restrict the list of available blocks. This can be done both server-side and client-side. Here’s one of the available techniques to do so:

function my_plugin_allowed_block_types( $allowed_block_types, $post ) {
    if ( $post->post_type !== 'post' ) {
        return $allowed_block_types;
    }
    return array( 'core/paragraph' );
}
 
add_filter( 'allowed_block_types', 'my_plugin_allowed_block_types', 10, 2 );

Refer to the documentation for more block types restriction techniques.

Block Style Variations

Several coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks offer style variations. For instance, the Buttons block comes with two variations “Fill” and “Outline”. The editor provides APIs to register custom style variations and to remove existing ones:

// Registers a style variation for quotes.
register_block_style(
    'core/quote',
    array(
        'name'         => 'blue-quote',
        'label'        => __( 'Blue Quote' ),
        'inline_style' => '.wp-block-quote.is-style-blue-quote { color: blue; }',
    )
);

// Unregisters the style variation named "fancy-quote"
unregister_block_style( 'core/quote', 'fancy-quote' );

Locked Templates

Locked Templates offer a way to restrict the content of Posts, Pages, CPTs to a given format.

For example the following template can be used to restrict the content of a Books CPT to an image, a paragraph for the author and a description.

array(
	array( 'core/image', array(
		'align' => 'left',
	) ),
	array( 'core/heading', array(
		'placeholder' => 'Add Author...',
	) ),
	array( 'core/paragraph', array(
		'placeholder' => 'Add Description...',
	) ),
)

Refer to the documentation more information about the Templates API.

Theme Supports

Colors

Several blocks offer color customization features. Developers can customize the default color palette to provide a consistent color scheme across the whole website.

add_theme_support( 'editor-color-palette', array(
    array(
        'name' => __( 'Strong magenta', 'themeLangDomain' ),
        'slug' => 'strong-magenta',
        'color' => '#a156b4',
    ),
    array(
        'name' => __( 'Light grayish magenta', 'themeLangDomain' ),
        'slug' => 'light-grayish-magenta',
        'color' => '#d0a5db',
    ),
) );

Users have the possibility to choose a custom color as well. This feature can also be disabled:

add_theme_support( 'disable-custom-colors' );

Additionally, it is possible to define an empty color palette to remove all color customization panels from the editor.

add_theme_support( 'editor-color-palette', array() );

Font sizes

Some blocks also allow the user to tweak the font size and developers have the possibility to define their own set of font sizes.

add_theme_support( 'editor-font-sizes', array(
    array(
        'name' => __( 'Small', 'themeLangDomain' ),
        'size' => 12,
        'slug' => 'small'
    ),
    array(
        'name' => __( 'Regular', 'themeLangDomain' ),
        'size' => 16,
        'slug' => 'regular'
    )
)

Developers can choose to remove the ability to use a custom font size.

add_theme_support( 'disable-custom-font-sizes' );

Additionally, it is possible to define an empty font sizes set to remove all font size customization panels from the editor.

add_theme_support( 'editor-font-sizes', array() );

Gradients

Recently, the ability to use gradients was added to the editor (only available in the Gutenberg 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). Similarly to colors, developers can define a custom gradients palette, disable custom gradients, or disable the gradients entirely.

// Define a custom palette.
add_theme_support(
    '__experimental-editor-gradient-presets',
    array(
        array(
            'name'     => __( 'Vivid cyan blue to vivid purple', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%)',
            'slug'     => 'vivid-cyan-blue-to-vivid-purple'
        ),
        array(
            'name'     => __( 'Vivid green cyan to vivid cyan blue', 'themeLangDomain' ),
            'gradient' => 'linear-gradient(135deg,rgba(0,208,132,1) 0%,rgba(6,147,227,1) 100%)',
            'slug'     =>  'vivid-green-cyan-to-vivid-cyan-blue',
        ),
    )
);

// Disable custom gradients.
add_theme_support( '__experimental-disable-custom-gradients' );

// Disable gradients
add_theme_support( '__experimental-editor-gradient-presets', array() );

Third-party blocks

One of the strengths of the block editor is its block library. The community have built dozens of block plugins. But, while Core blocks do support the controlling APIs exposed above, a lot of third-party blocks don’t adapt properly to these options.

For more consistency between the different block libraries and the Core blocks, block authors are encouraged to support these options in their custom blocks.

The block primitives made available to block authors to build their blocks (e.g. the FontSizePicker component, the experimental useColors and useGradient hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.) do support these options by default, but if you’re using custom UIs, you’re encouraged to adapt to these options. You can access these settings by using the select( 'core/block-editor' ).getSettings()selector.

/*
 * @property {Array} colors Palette colors
 * @property {boolean} disableCustomColors Whether or not the custom colors are disabled
 * @property {Array} gradients Gradient palette
 * @property {boolean} disableCustomGradients Whether or not the custom gradients are disabled
 * @property {Array} fontSizes Available font sizes
 * @property {boolean} disableCustomFontSizes Whether or not the custom font sizes are disabled

 * @property {boolean} __experimentalEnablePageTemplates Whether the user has enabled the Page Templates
 */
const settings = wp.data.select( 'core/block-editor' ).getSettings();

Going further

As shown above, the block editor already provides a big number of APIs to control the experience, but it’s fair to acknowledge a lack of consistency and a few missing APIs (for instance to disable drop caps in Paragraph blocks).

In order to address this, I’m proposing a new block_editor_features hook that looks like this:

// Non-exhaustive representation of the block-editor configuration options.
$block_editor_features = array(
    'colors' => array(
        "enabled" => true,
        "colorPalette" => array(),
        "allowCustomColors" => true,
        "gradientPalette" => array(),
        "allowCustomGradients" => true,
    ),
    'typography' => array(
        "enabled" => true,
        "fontSizes" => array(),
        "allowCustomFontSizes" => true,
        "allowDropCap" => true,
    ),
);

apply_filters( 'block_editor_features', array $block_editor_features, WP_Post $post );

And these would be made available to block authors using a dedicated selector.

const features = wp.data.select( 'core/block-editor' ).getFeatures();

In addition to the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., this configuration can also be made available in the proposed theme.json file.

#block-editor, #core-editor, #gutenberg, #themes

Miscellaneous Developer Updates in 5.2

New wp_body_open Theme Hook

5.2 will introduce a new wp_body_open() function that is used to trigger a wp_body_open action. This action is intended to allow developers to inject code immediately following the opening <body> tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.).

Themes are encouraged to begin using this hook as soon as 5.2 is released. The function should be placed just inside the opening <body> tag of the template file. For example:

<body <?php body_class(); ?>>
<?php wp_body_open(); ?>

Usage of this hook should be reserved for output of unseen elements like <script> tags or additional metadata. It should not be used to add arbitrary HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. content to a page that could break layouts or lead to unexpected situations.

Backward Compatibility

In order to support previous versions of WordPress, it is recommended you use a shim in your theme to prevent fatal errors from the undefined function.

if ( ! function_exists( 'wp_body_open' ) ) {
    function wp_body_open() {
        do_action( 'wp_body_open' );
    }
}

Note that if your theme is going to be submitted to the theme repository, then you won’t be able to use the wp_ prefix, as it will get flagged by the Theme Check. An alternative is to call do_action directly where the wp_body_open() function is placed in the first example, like this:

<body <?php body_class(); ?>>
<?php 
if ( function_exists( 'wp_body_open' ) ) {
    wp_body_open();
} else {
    do_action( 'wp_body_open' );
}

Plugins can detect the use of this function in a theme by calling did_action( 'wp_body_open' ) and falling back to alternative methods if the action has not fired.

See #12563 and #46679 for more information.

Login HeaderHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. Adjustments

The <h1> on wp-login.php previously used the title attribute inconsistently between multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site and single site. In multisite, the value of this attribute was the title of the networknetwork (versus site, blog), but on a single site, it merely duplicated the link text. As part of #24766, many of the title attributes throughout coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. have been removed, as they are often redundant or useless.

In WordPress 5.2, this title attribute has been removed and its associated filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., login_headertitle, has been deprecated. If the deprecated filter is used, it now applies to the link text. A new login_headertext filter has been added in its place.

In addition to the <h1> changes, the link on the WordPress logo now always points to 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/ by default. In prior versions, it would point to the primary site of the network on multisite. This URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org can still be filtered using login_headerurl.

See: #42537

Editor Image Caption Styles

In the 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. editor, the font-size and color attributes were removed from the figcaption element unless the active theme has opted into default block styles.

Additionally, a margin: 0; attribute applied to .block-editor-rich-text__editable was removed from the RichText component, so as to allow theme styles to control those margins without high specificity. If your 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 relied on this margin, you’ll need to add this back to the necessary elements.

See: wordpress/gutenberg/pull/14366

Walker_Category HTML Attributes

A new category_list_link_attributes filter has been added to Walker_Category to allow customization of the HTML attributes applied to a categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. list item’s anchor element.

This complements the page_menu_link_attributes filter in Walker_Page and the nav_menu_link_attributes filter in Walker_Nav_Menu.

See #40666

New Additional Content Filter on User Delete Action

When users are deleted from a site, WordPress checks to confirm that they do not have posts or links assigned to them. However, there are cases where a plugin may have content associated with them outside of a post_author or link_owner relationship.

WordPress 5.2 introduces a new users_have_additional_content filter, which allows plugins to run additional checks for custom content relationships.

Note: This filter specifically doesn’t override the system users_have_content checks to avoid any undesired suppression of the reassign functionality. Instead it enables the ability to flag that a user has additional content.

Developers should note that this filter doesn’t conduct the reassignment operations on the data, this will be done by the delete_user or deleted_user actions which provide the ID of the user as well as the ID of the user for reassignment if selected.

Using the Filter

Below is a simple example of how a plugin could use the filter along with the delete_user action to allow the re-assignment of non-standard content.

First the filter returns true to signify that users have additional content. This triggers the content reassignment UIUI User interface to appear in the adminadmin (and super admin) for all users being deleted.

It then uses the delete_user action hook to reassign additional content at the same time as any standard core content.

function myplugin_users_have_additional_content( $has_content, $user_ids ) {
	if ( ! $has_content ) {
		// Check if any of the the users being deleted have additional content
		if ( myplugin_check_users_have_content( $user_ids ) ) {
			return true;
		}
	}
	return $has_content;
}
add_filter( ‘users_have_additional_content’, ‘myplugin_users_have_additional_content’, 10, 2 );

function myplugin_reassign_user_content( $deleted_user, $reassigned_user ) {
	if ( $reassigned_user ) {
		// Re-assign the content from the deleted user
		myplugin_reassign_coauthor( $deleted_user, $reassigned_user );
	}
}
add_action( ‘delete_user’, ‘myplugin_reassign_user_content’, 10, 2 );

See: #36860

Other Updates of Note:

  • As part of the 2019 focus of improving automatic updates, the sodium_compat library will now be included in WordPress. Sodium Compat is a polyfill for the Sodium cryptography library for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions <7.2. Including this will facilitate security enhancements, with the initial focus of enabling more secure signing and verification of update packages. See: #45806
  • Twemoji is now updated to version 12.0.1. See: #46805
  • Fixed a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. where an Allow header was not being returned for OPTIONS requests to the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.. See: #45753
  • A $domain parameter has been added to translate_user_role(). This will allow translations of custom user roles added in plugins. See: #38736

#5-2, #dev-notes, #editor, #themes

Developer Focused Privacy Updates in 5.2

WordPress 5.2 brings several improvements for developers working with Privacy Policy pages and data exports.

New Privacy Policy Page Helpers

Four new features have been added to make customizing and designing the Privacy Policy page easier:

  • A new function, is_privacy_policy(), can be used in conditionals to identify whether the current $wp_query is for the Privacy Policy page.
  • A new theme template file, privacy-policy.php, is used for rendering the page assigned as the Privacy Policy.
  • .privacy-policy has been added as a body class and is inserted when the currently rendered page is the Privacy Policy page.
  • .menu-item-privacy-policy has been added as a menu item class to specify the menu link that points to the Privacy Policy page.

Backwards Compatibility

The only backwards compatibility concern with using these new helpers is with the is_privacy_policy() function, which would trigger a Call to undefined function fatal error.

Themes and plugins that would like to support the is_privacy_policy() function in older versions of WordPress can use the following shim:

if ( ! function_exists( 'is_privacy_policy' ) ) {
    function is_privacy_policy() {
        return get_option( 'wp_page_for_privacy_policy' ) && is_page( get_option( 'wp_page_for_privacy_policy' ) );
    }
}

For more information, see #44005.

Loosened Tag Restrictions in User Data Exports

User Data exports no longer use a hardcoded list of allowed tags, limited to just <a> and <br>. They will now use the default list of allowed tags in wp_kses().

Furthermore, the code facilitating the export now passes a personal_data_export context to wp_kses(), so that the allowed tags and attributes can be filtered using the wp_kses_allowed_html filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. and checking for the personal_data_export context.

Here’s a filter example that adds support for the <sub> and <sup> tags to the personal data export:

function prefix_allowed_html_filter( $allowedtags, $context ) {
	// Only target personal data export.
	if ( 'personal_data_export' !== $context ) {
		return $allowedtags;
	}

	// Add support for the sub tag.
	if ( ! isset( $allowedtags['sub'] ) ) {
		$allowedtags['sub'] = array();
	}

	// Add support for the sup tag.
	if ( ! isset( $allowedtags['sup'] ) ) {
		$allowedtags['sup'] = array();
	}

	return $allowedtags;
}
add_filter( 'wp_kses_allowed_html', 'prefix_allowed_html_filter', 2, 10);

For more information, check out the documentation for the wp_kses_allowed_html filter.

See: #44044

#5-2, #core-privacy, #dev-notes, #privacy, #themes

Site Health Check Project review at WCUS

This is a verbose set of notes to record the discussions that took place at WCUS and to reflect the work that has been done across multiple teams.

The Site Health Check project is a collaborative multi-team project with a focus on encouraging better site maintenance.

This project benefits not just WordPress users, but also the surrounding PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher ecosystem as a whole. Our hope is that this will prompt a lot of PHP updates across the web.

It started as a project to focus efforts on getting users to update their hosting version of PHP from 5.2 to something where the End of Life has not already passed.

The project was initially called ServeHappy, homage to the BrowseHappy project which was a global tech effort to move away from Internet Explorer 6. The problem with the project name was that, when tested with users who did not know about the ins and outs of the project, the name was confusing and was not clear what the project’s intentions were.

The project is now known as the Site Health Check project. It encourages and hints to users that if they run a website, they should have a routine of checking and updating not just WordPress but underlying technologies that the site is built on. It also builds positive website ownership and habits.

The project is split into what can be considered 3 parts – changes to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. itself, a site health 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 and the site health check community support.

Upcoming changes to WordPress Core

The core-centric side of the project still reflects the Servehappy origins. This includes:

  • An information page 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/ explaining the importance of updating PHP. The team has been working on improving the language used to benefit non-technical people and have clear instructions of what to do if they find out their site is running an old version of PHP.
  • A dashboard notice that will inform users if their site is running on a PHP version that WordPress considers outdated and plans to drop support for in a future update.
    • The version shown in the dashboard is 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.-driven which means that WordPress leadership has a centralized “knob” to tune the PHP version distribution.
    • The dashboard includes a link to wordpress.org/support/update-php which has generic information on what the notice means and how to update PHP on their servers.

  • There will be an environment variable or a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. which allows hosting companies to modify the link to the “Update PHP” page on their servers so that it goes to something more relevant for their customers.
    • There are some concerns of security problems and abuse over the link redirection.

  • The team has been working on a feature to add white screen protection, which the hosting group felt was helpful and cool. The white screen protection catches any fatal errors that a PHP update might produce. From the front facing side of the website, the site will still be white screened, but with the protection in place, the user can still access the adminadmin (and super admin) panel.

  • There was a discussion whether it would be better for the site to be slightly broken rather than completely broken, but the general consensus was that it is better to white screen because from the Core Team perspective, they cannot be sure of what the PHP error causes, and thus can’t be sure that all the information being shown is meant to be public.

    It is better to white screen the whole website but ensure that access to the admin panel is still accessible. Once logged in, there will be a general notification regarding the WSOD.

PHP minimum required headers

Plugins

For a while, WordPress plugins have been able to set a minimum PHP required comment as part of the plugin headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. To date it has not done anything but set the intention that the plugin author is able to declare what PHP minimum version they are willing to support.

Work is being done so that the Add New Plugin admin screen will show all plugins a user searches for, but will not be able to install any plugins that require a newer version of PHP without updating that first. Another task being worked on is blocking plugin updates if the newer version requires a higher version of PHP, same as it currently works if the update requires a higher version of WordPress.

This gives plugin authors better control of what PHP versions they are willing to support, and will hopefully encourage people to upgrade their version of PHP at the same time.

This change will allow plugin authors the choice to use more modern PHP functionality and syntax without worrying their plugin will break for the end user.

Themes

For themes, the Requires PHP header is not implemented yet, as they didn’t have the same readme.txt file up until recently: https://make.wordpress.org/themes/2018/10/25/october-23rd-theme-review-team-meeting-summary/

Now that new themes do have that requirement, there is an expectation that the header will be implemented as well in the foreseeable future. Here’s a ticketticket Created for both bug reports and feature development on the bug tracker. for that: #meta-3718

Relevant TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. Tickets

  • #43986 Disable “Install Plugin” button for PHP required version mismatch. This has already been committed to core.

  • #43987 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. plugin updates if required PHP version is not supported – Plugins screen

  • #44350 Block plugin updates if required PHP version is not supported – Updates screen

The latter two trac tickets are currently slated for 5.1 as well, planned for February 21: https://make.wordpress.org/core/5-1/

The feature merge deadline is January 10 though, so it needs to be discussed at the next #core-php meeting whether making it into 5.1 is still feasible.

A prerequisite for these changes is the WSOD protection that needs to be completed and committed by the deadline: #44458

Join in

The group has weekly meetings on Mondays 16:00 UTC on in the #core-php channel of WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/: https://github.com/WordPress/servehappy

Site Health Check Plugin

The site health check plugin is a way for users to be able to see technical details of their website setup without going into the server side of things. It is useful to conducting top level investigation work without accessing the server directly.

The 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. version of the plugin takes the best practices from the Hosting Team’s documentation and checks the server against that. This includes: WordPress version number, plugins and themes are up to date, PHP version number, if HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. is active across the whole site as well as a number of other things.

When Health Check gives notifications about upgrading things, it hands users off to plain English documentation to walk them through the process. For example: https://wordpress.org/support/update-php/. Notifications for plugins and themes being up to date are based on the version inside the plugin and theme repo. If a theme or plugin is not present in the repo, it will assume it is up to date and will not give an error.

Eventually, a lot of the Site Health Check plugin will be in core.

The Site Health Check Plugin uses a traffic light system to flag up the importance of a suggested change. The definition of critical vs non-critical update notifications is from a security perspective. If it is a security issuesecurity issue A security issue is a type of bug that can affect the security of WordPress installations. Specifically, it is a report of a bug that you have found in the WordPress core code, and that you have determined can be used to gain some level of access to a site running WordPress that you should not have., it’s critical.

Early user testing with the community has shown that the plugin suffers from a lack of designer eye. During WCUS, we have had a designer volunteer to review the interface and give feedback.

This should help with the usability of the plugin and balance it between positive reinforcement of things that are set up as guided by best practices whilst not over-burdening people with extra technical information.

There is some useful documentation on how to use the Site Health Check Plugin: https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/

Join in

– Github: https://github.com/wordpress/health-check

– WP.org : https://wordpress.org/plugins/health-check

Site Health Check Desks & Community Support

In-person support is invaluable. When a user is unsure of what to do, they can find in-person support at their local meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. and WordCamps. To omit any surprises, we can encourage our community to pre-warn and prepare as many people as possible.

The idea of Site Health Check desks has been tested in 3 different WordCamps and 1 meet-up with improvements and suggestions being fed back to the plugin and fliers.

Site Health Checks is an extension of the Happiness Bar, and by asking the simple question “Do you know what version of PHP your website is running?”, people either:

  • Know & it is up to date – get a high-five. Say Awesome and keep up the good work. Pre-warn the next EOL of PHP Dates.
  • Know & it is out of date – highlight the EOL date has already passed and recommend they update their PHP version.
  • If they don’t know, Check if they know how to check. If they do, suggest that they check and that they want it to be 7.2 or higher. 7.1 EOL is in a year.
  • If they don’t know and don’t know how to check, invite them to sit down and the volunteers can help them check using the Site Health Check plugin. DO NOT scrape the site. They can end up being blocked off the servers.

Postcards were created with 5 core things to check. As well as printable table toppers. They are used as fliers for people to know where to download the site health check.

Meetup organisers have also shown an interest in running the site health check and promoting it at their meet-ups.

This is where much of the user testing of both the “Update PHP” information page and the Site Health Check plugin is happening.

Plugins and Themes Plans

Plugins and Themes served from WordPress.org can be automatically checked and updated to be compatible with 7.X. This is because there is access to the SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. where these plugins are being pushed from.

Ideally, plugin authors who have a plugin in the plugin repo will update their plugins to be compatible with PHP 7.X. There are already plugins such as the PHP Compatibility Checker which people can use to check how compatible their websites are with a version of PHP.

How are premium plugins and themes going to be handled?

The plugin team at WordPress.org can contact authors, but ultimately it is up to the plugin author to action the suggestions that are made from the WordPress.org team.

If there is no answer, or the author does not wish to fix errors, then this is a dead end.

Target Dates

WordPress 5.1  ->  ServeHappy notice + White Screen of Death protector

WordPress 5.2 ->  Site Health Check plugin

Where hosting companies come into play

We would like hosting companies to go aggressively, pushing their communities forward before WordPress does.

We know that, as a hosting company, many of you will see the same issues come up during a PHP update. It would be useful to the rest of the group if any information of any PHP errors that are being seen repeatedly and information about which plugin or theme is causing it. It will allow the rest of the team to prioritise which plugins and themes need attention to be fixed across the whole community.

It will also help the support team if any solutions are found to be shared, so that they know what to be suggesting in the forums. We may be able to add notices before a PHP update into the health check which highlights problematic plugins.

Hosts with PHP lower than 5.6 may see some initial notifications before that date.

Hosting company teams are most likely to know other people working in the hosting sector. Above all else – get the word out.  Big hosts are represented well here, but as a community we are aware and worried about the smaller, independent hosters. Talk to your hosting friends. Let them know this is coming. Invite the small hosting companies to join the Hosting Team on WordPress.org for up to date information of what is upcoming and will be effecting hosters.

The more we can update in batches the less burden there is across the whole industry.

Where plugin and theme authors come into play

If plugin and theme authors ensure that their plugins have a PHP minimum version set in their required header, then their plugins and themes will be ready once the PHP requirement is being enforced.

Plugin and theme authors should also ensure that their plugins are compatible with PHP 7.X. Tools such as PHP Code SnifferPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS. (PHPCSPHP Code Sniffer PHP Code Sniffer, a popular tool for analyzing code quality. The WordPress Coding Standards rely on PHPCS.) or the PHP Compatibility Checker as mentioned above should help.

Actions from the meeting

– Ensure there is communication with the hosting team regarding release date plans.

–  #core-php should be cross posting ServeHappy notes to the Hosting P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. as well.

– WordPress.hosting has been taken, unsure by who. It would be handy to have WordPress.hosting symlink to Hosting Team P2 to help getting other hosting companies to join the Hosting Team

– Recommend that Hosting Team check and sync up the Best Practices documentation.

– Can someone from the hosting team please review and ensure that Health Check plugin is checking against everything that exists in the “Hosting Best Practices” doc.

– Recommended to Health Check plugin to check out Lighthouse plugin UIUI User interface.

– Write up more in-depth info for meetup and WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. organisers, have postcard and table toppers online so they can be shared and translated easily.

Thanks

The effort to raise the minimum PHP version requirement of WordPress is a big cross- team effort. Big thanks to

  • @brettface for the notes.
  • #core-php, #plugins, #themes and #meta team for their hard work
  • the #hosting team for their input and support
  • @alexdenning from #marketing team for the content review
  • @clorith from #forums for the health-check plugin development
  • WordCamp London 2018, WCEU 2018 and WordCamp Brighton 2018 organisers for allowing us to test the Health Check help desk concept
  • And to the #polyglots team who will be asked in the near future to translate our work for the whole community.

#recap, #servehappy, #wcus