What’s new in Gutenberg 13.6? (6 July)

“What’s new in 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/…” posts (labeled with the #gutenberg-new 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 posted following every Gutenberg release on a biweekly basis, discovering new features included in each release. As a reminder, here’s an overview of different ways to keep up with Gutenberg and the Full Site Editing project.


The Gutenberg 13.6 release comes with four major highlighted features, many smaller enhancements, a number of 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) improvements, and twenty-six 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. To make developing with Gutenberg easier, a number of refactors to the codebase occurred for typescript rewrites. Work around improving performance continues with many changes shipped in this release expected to lead to noticeable results when the broader efforts are completed in future releases. Finally, the Style Engine work has progressed with the option for extenders to use these features with the correct 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. shape for now and more options in the Styles UIUI User interface planned for future releases.

Table of Contents

Provide patterns to select from when creating any post type

In WordPress 6.0, an 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. was introduced that allows patterns to appear in a modal every time a user creates a new page so that, instead of starting from scratch, a user starts with content to work from. For example, this means a user could choose between patterns for a contact page or an about page and then just fill in the details that are unique to their site.

Thanks to feedback from the community, this release expands this feature to allow the same modal to be presented to a user on other post types. For example, if a user has a book post type, they could now be presented with different ways to show the book based on patterns in a modal (book cover on the left, description on the right, book cover in the center with description below, etc).

In order to take advantage of this new API powering the current experience, you need to include core/post-content in the blockTypes for your pattern and include the postTypes where you want the modal to show in the postTypes array. If postTypes are not provided the modal just appears on the page.

Create more template types in the editor

Expanding the types of templates that can be created from within the Site Editor continues to be a high priority to open up more creative options for folks to control every aspect of their site. With Gutenberg 13.6, it’s now possible to create a template for all of the posts of a specific post type (ex: single-$postType) and, to get more granular, a template for a specific post (ex: single-$postSlug). This is all handled with a very simple UI and doesn’t require needing to know post types identifiers or post slugs, making it easy to work with.

Other Notable Highlights

Gutenberg 13.6 includes several, more general enhancements and accessibility improvements.

Clearer layout controls

For example, the “Inherit Default Layout” controls have been updated to a more understandable toggle to help users and themers alike make the design decisions they want:

More keyboard shortcuts

Two keyboard shortcuts (Strikethrough or Inline Code) have been added and a previously missing keyboard shortcut to link to a post is now properly documented in the shortcuts modal:

Simplified post scheduler

The post scheduler UI has been updated to use “Today” and “Tomorrow” when possible to make the experience more readily understandable at a glance.

New template selection UI

Previously, the template selection options took up a lot of space in the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. to allow you to pick and choose what you wanted. With Gutenberg 13.6, this experience has switched to being a popover allowing it to take up far less space and blend in better experience-wise with other post details.

Explore the expanding theme.json engine

Gutenberg 13.6 builds on previous work to expand theme.json to allow you to create a cohesive design across blocks by allowing you to change the styles of all buttons. This relies on targeting elements which are pieces of the UI that appear in multiple blocks and whose style you should be able to change across all implementations. With this work, it means you can control a button’s style across your site in everything from the general Buttons 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. to the Search block.

For anyone building third-party blocks with buttons, this same feature can be used to interact with your block assuming the block you create provides the correct markup. Keep in mind that there’s a difference between changing the styles of an individual block on a page, which will just impact that block, and changing the style at the element level, which impacts all button blocks.

Alongside the button element, captions have also been included so you can control the style of captions across all blocks with captions, from an Image block to a Video block. That element controls the styles of captions across all the blocks. For now, captions can only be controlled using theme.json but, in the future, there will be a way to manage this in the UI.

Keep in mind that this work around targeting elements will be fairly contained as it only impacts items that can’t be codified as blocks (links, captions, buttons, etc). Because these new features are in the early stages of development, please test your themes and blocks and report any issues you might find. It all helps as development continues.

Accessibility continues to be a focus and this release has some improvements to focus management and adding in previously missing aria labels.

Changelog

Enhancements

UI

  • Increase fade intensity during spotlight mode. (40454)
  • Improvements to “inherit default layout” toggle. (41893)
  • Make it easier to select “Edit visually” when in “Edit as HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. (41516)
  • Abbreviate post schedule date when possible. (41738)

Global Styles

  • Add support for caption elements. (41140)
  • Add UI for button elements (41659) and fix the button element selectors. (41822)
  • Support pseudo selectors on elements in theme json. (41786)
  • Add the ability to unset duotone in themes with default duotone set. (39564)
  • Allow references to values in other locations in the tree. (41696)
  • Lower specificity of elements block css. (41931)
  • Add border to frontend style engine. (41803)
  • Add schema support for styles.filter.duotone. (41920)
  • Add an API to make it easier to get class names. (41753)
  • Update Theme JSON $schema to account for pseudo-selector support. (41936)

Patterns

  • Add the ability to use creation patterns for other post types besides page. (41791)

Block Library

  • Columns: Change the title of one third/two thirds column variation to 66/33. (41734)
  • Navigation:
    • Adjust mobile close button position when adminadmin (and super admin) bar is visible. (41664)
    • Make additional top margin specific to open modal. (41949)
    • Move block CSSCSS Cascading Style Sheets. to JSON. (41898)
  • Post Comments Form: Add button that enables commenting to warning. (41603)
  • Cover:
    • Strip whitespaces in render_block_core_cover. (40859)
    • Implement axial top bottom margin. (41963)
  • Image: Set Default state to media library for library button in image block. (41678)
  • Classic: Remove CSS properties with vendor prefixes. (41995)
  • Embed: Add Pocket Casts embed block variation. (41006)

Site and Template Editor

  • Turn Template settings panel into a Template popover. (41925)
  • Expand the template types that can be added – single custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. and specific posts templates. (41189)
  • Add clear customizations to the template card. (41743)

Accessibility

  • Make the site editor 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. toolbar use the ARIA toolbar pattern. (41902)
  • Allow defining an aria-label in group blocks. (41744)
  • Add keyboard shortcut for Strikethrough (41910) and inline code (41816) in the format library.
  • Navigation submenus: Allow Escape key to close the submenu and focus trigger. (41774)
  • Show the link completer shortcut on the help modals. (41872)

Bug Fixes

  • Fix incorrect ‘_n’ usage in the block Editor. (41886)
  • BlockPreview: Fix ‘Infinity’ is invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. ‘minHeight’ value warning. (41766)
  • Compare against default categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. in the settings instead of hardcoded slug. (41956)
  • Fix PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 8.1 deprecation in the gallery block. (41193)
  • Add ‘application/zip’ accept header. (41602)
  • [Block Editor]: Fix content loss from replaceInnerBlocks with controlled blocks. (41948)
  • Fix action button spacing on the widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. editor. (41915)
  • Render duotone presets in pattern preview. (41249)

Block Library

  • List v2:
    • Fix impossible to outdent multiple list items. (41713)
    • Set selection to created block after split with Enter. (41899)
    • Transforms don’t take into account nested blocks. (41741)
  • Comments: Fix issue with custom font sizes and links color. (41627)
  • Navigation: Fix permissions warning. (41862)
  • Post Template: Ensure layout classnames are not attached to inner li elements. (41827)
  • Image block: Preserve alt text from media library. (41839)
  • Search block: Remove double spaces. (41746)
  • Fix issue of background min-height. (41693)
  • Only use the post-title if the featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. is a link. (41775)
  • Always load block CSS from __experimentalStyle on global styles output. (42005)

Components

  • Border Controls/Color Palette: Ensure popovers remain within small viewports. (41930)
  • ColorPicker: Remove horizontal scrollbar when using HSL or RGB color input types. (41646)
  • DatePicker: Respect site’s ‘Week Starts On’ setting. (41648)
  • BlockSettingsMenuControls: Fix ‘showLockButton’ check. (41788)
  • Color Controls: Allow popovers to remain within smaller viewports. (41929)

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

  • Fix retrieving autosaves when using a custom rest_namespace. (41542)
  • Remove hardcoded references to rest namespace. (41950), (41951).

Performance

  • Continued the work refactor away from lodash usages in order to reduce the build size.
  • Remove Unrequired regex search on duotone supports. (42020)
  • Ensure only the main query is modified when resolving template for new posts. (40799)
  • Avoid calculating HTML block styles in useSelect. (42026)
  • Fix performance regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. pasting due to removeWindowsFragments. (41907)

Documentation

  • Add an explanation of how to set up the environment to run the performance test. (41883)
  • Add local dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. to aid when doing work on schemas. (41968)
  • Fix Minor documentation inconsistencies on block attributes. (41468)
  • Add an example for the end-to-end tests snapshot update. (41999)
  • Fix documentation of Flex component to no longer be experimental. (41926)
  • Fix link to “Good First Review” issues in README. (41754)
  • Fix link to Flex component in FlexItem Readme. (41928)
  • Fix some small inconsistencies in the block editor documentation. (41861)
  • Update terminology and documentation of Style engine. (41964)
  • Update skip serialization documentation to reflect ability to target specific properties. (41277)
  • Add supports to basic sample code documentation. (41589)
  • Update nested-blocks-inner-blocks.md. (41962)
  • Document fontFace and it’s values in theme.json schema for the Webfonts API. (41844)

Code Quality

  • Fix: Double condition on or on block editor reducer. (42019)
  • Remove WP 6.0 WP_REST_Block_Patterns_Controller class. (41914)
  • Remove leftovers of legacy query-loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. block. (41891)
  • Remove startBlankComponent from __experimentalBlockPatternSetup. (41721)
  • Move setting registration into WP 6.0 compat. (41985)
  • Add __experimentalUseResourcePermissions to make code simpler. (38785)
    ))
  • Remove Unnecessary ‘&& check’ as ‘optional chaining (authorDetails?.avatar_urls) check’ is already used in the AvatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. Block. (41779)
  • Refactor NavigationItem component to pass exhaustive-deps. (41639)
  • Move generation of layout util classes to existing method to avoid adding global public method WP. (41885)

Tooling

Static analysis

  • ESLint: Enable ignoreRestSiblings option for no-unused-vars rule. (41897)
  • Fix a prettier error. (41916)
  • SerializeBlock fix ESLint warning. (41763)

Testing

  • Test migrations toPlaywright:
  • InputControl: Add tests and update to use @testing-library/user-event. (41421)
  • Skip flaky navigation end-to-end test. (41829)
  • Fix the image rotating flaky test. (41808)

Storybook

  • Add 40px size variant to NumberControl. (41997)
  • Convert knobs to controls in NumberControl. (41849)
  • Convert knobs to controls in the spacer. (41851)

IDEIDE Integrated Development Environment. A software package that provides a full suite of functionality to software developers/programmers. Normally an IDE includes a source code editor, code-build tools and debugging functionality.’s integrations

  • Autocompletion support for useSelect (via jsDoc annotations). (41596)

Migrations to typescript

Performance Benchmark

The following benchmark compares performance for a particularly sizeable post (~36,000 words, ~1,000 blocks) over the last releases. Such a large post isn’t representative of the average editing experience but is adequate for spotting variations in performance.

Post Editor

VersionTime to the first blockKeyPress Event (typing)
Gutenberg 13.64.51s41.02ms
Gutenberg 13.54.34s38.81ms
WordPress 6.04.66s37.70ms

Site Editor

VersionTime to the first blockKeyPress Event (typing)
Gutenberg 13.65.22s32.30 ms
Gutenberg 13.55.05s32.59 ms
WordPress 6.04.82s31.07 ms

Contributor Props

The following PRs were merged by first-time contributors – thank you and congrats!

  • @adambasa-dp#30930 – Make it easier to select “Edit visually” when in “Edit as HTML. (41516)
  • @arturgrabo: Change case. (41792)
  • @hz-tyfoon: Block Library (Avatar Block): Remove Unnecessary ‘&& check’ as ‘optional chaining (authorDetails?.avatar_urls) check’ is already used. (41779)
  • @inc2734: Add supports to basic sample code. (41589)
  • @kbrown9: [RN Mobile] RichText: Return early when content has changed in onSelectionChangeFromAztec. (41682)
  • @mcliwanow: Fix link to “Good First Review” issues in README. (41754)
  • @navigatrum: Strip whitespaces in render_block_core_cover. (40859)
  • @pavanpatil1: Migrate rtl test case to it’s playwright version. (41495)
  • @petitphp#40675: Ensure only the main query is modified when resolving template for new posts. (40799)
  • @phcp: Add Pocket Casts embed block variation. (41006)
  • @vasartam: Block attributes docs: Minor documentation inconsistencies. (41468)
  • @xylocone: Update nested-blocks-inner-blocks.md. (41962)
  • @zaerl: Fix: Add ‘application/zip’ accept header. (41602)

The following contributors merged PRs in this release:

@aaronrobertshaw @adambasa-dp @adamziel @afercia @ajlende @alexstine @andrewserong @aristath @arturgrabo @chad1008 @ciampo @dcalhoun @derekblank @fabiankaegy @fluiddot @georgeh @getdave @glendaviesnz @grappler @hz-tyfoon @inc2734 @jorgefilipecosta @kbrown9 @kevin940726 @MaggieCabrera @Mamaduka @matiasbenedetto @mcliwanow @mcsf @mikachan @miminari @mirka @mtias @navigatrum @noisysocks @ntsekouras @ockham @opr @pavanpatil1 @petitphp @phcp @pooja-muchandikar @ramonjd @scruffian @SiobhyB @spacedmonkey @stokesman @sunil25393 @t-hamano @talldan @tellthemachines @tomjn @tyxla @vasartam @walbo @xylocone @zaerl

Thank you to all who helped make this release happen.

#gutenberg, #gutenberg-new

Rollback Feature: Testing Call to Action

While it is a rare occurrence, updating plugins and themes can fail in such a way that leaves the old 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/theme non-functional, and may leave users with a broken site.  #51857 intends to add the ability for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to “rollback” to the previously installed version of a plugin/theme when such a failure occurs.

Over 19 months of development and testing has gone into this feature, primarily by @costdev, @pbiron, and myself (@afragen). Several different solutions and they have led us to the current PR2225.

It was determined that copying the current plugin to an alternate location and in the event of an update failure, copying it back into wp-content/plugins, would be the least resource intensive method. This does require one additional plugin copying operation and two if there is a update failure.

rename() was essential to the rollback feature as many reported issues were timeout issues on some resource starved hosts, #54166 as an example. Using rename() allows us to vastly improve the performance of the current method, rather than using copy_dir() as a recursive file copy. It was thought that this recursive file copy, on some systems, resulted in timeout issues for large plugins.

Do you use a VirtualBox-based environment?

Please follow these steps before continuing.

Call to Action

Big Need:

Broad testing and feedback is needed on many different web hosting platforms, including inexpensive shared hosting, managed hosting, and more.

How do I test Rollback?

Do not test on a production siteProduction Site A production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing..

But do test on a local environment, hosted staging or test environment, or cloud staging or test environment.

  1. Here are some large plugins used for testing: akismet, jetpack, mailpoet, woocommerce, wpforms-lite, wordpress-seo
    • WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/: wp plugin install akismet jetpack mailpoet woocommerce wpforms-lite wordpress-seo
  2. Do this from the plugin’s page on https://wordpress.org/plugins by navigating to the “Development” tab, clicking “Advanced” to the right, and downloading an older version from the dropdown at the bottom of the page. You can also install the current version then modify the version in the plugin’s main file to decrement the version number.
  3. Install the WordPress Beta Tester plugin, set to Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. and Nightlies. Go to Dashboard > Updates and click the Update to latest 6.2 nightly button or use WP-CLI, wp core update --version=trunk --force
  4. Install the Rollback feature plugin or test using the PR2225 in WordPress/wordpress-develop.
  5. Please make a note of the time required to perform plugin updates. Your phone’s stopwatch function may be the easiest method to do this.

Testing a single plugin update:

  1. Navigate to Plugins > Installed Plugins.
  2. Click “Update Now” located within the plugin row.

Testing bulk plugin updates via “Plugins”:

  1. Navigate to Plugins > Installed Plugins.
  2. Select another two plugins, select “Update” from the Bulk Actions dropdown, and click “Apply”.

Testing bulk plugin updates via “Dashboard”:

  1. Navigate to Dashboard > Updates
  2. Tick all plugins with an available update.
  3. Select “Update” from the Bulk Actions dropdown, and click “Apply”.

Testing updates via WP-CLI (if already familiar).

Validation of successful updates

This requires activating all the testing plugins on your testing site. Unsuccessful updates should show PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher Errors or PHP Fatal Errors.

  1. Activate each of the plugins that were updated.
  2. In WP Adminadmin (and super admin), navigate to each plugin’s menu pages.
  3. Navigate the frontend of your test site.
  4. Navigate to your wp-content/temp-backup/plugins folder. It should be empty.

Forcing an update failure

Use the following 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. to force an update failure. This will reinstall the previously active plugin/theme.

add_filter( 'upgrader_install_package_result', function() {
  return new WP_Error( 'simulated_error', 'Simulated Error' );
});

Testing update failures

When testing for failures on the bulk update in update-core.php you must use the PR. There is a modification in the PR that stops WP_Upgrader::unpack_package() from deleting the items in the temp-backup directory.

Needed Feedback?


How long did the update(s) take?

  • Your phone’s stopwatch may be the easiest option for logging the time to update.
  • Please test without the Rollback plugin or PR active for a baseline.
  • Reinstall the earlier versions as before.
  • Test the updates again with the Rollback plugin or the PR active.
  • Please provide the list of updated plugins/themes, the timings, and your environment details.
    • web host
    • PHP version
    • nginxNGINX NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. It started out as a web server designed for maximum performance and stability. In addition to its HTTP server capabilities, NGINX can also function as a proxy server for email (IMAP, POP3, and SMTP) and a reverse proxy and load balancer for HTTP, TCP, and UDP servers. https://www.nginx.com/., apacheApache Apache is the most widely used web server software. Developed and maintained by Apache Software Foundation. Apache is an Open Source software available for free., etc
    • WordPress version
  • Continue

Did you receive any “Failed to update” errors?

  • Yes:
    • Please provide environment details.
    • Please provide the name of the plugin(s) that failed.
    • Was this a single plugin update or a bulk plugin update?
      • Bulk plugin update:
        • Where was the failed plugin in the list of plugins to be updated?
        • Were you on the Dashboard > Updates page, the Plugins > Installed plugins page, or using WP-CLI?
  • No: Continue

Did you receive any Fatal Errors when browsing your site after the update?

  • Yes:
    • Please provide your environment details.
    • Please provide the name of the plugin(s) that resulted in Fatal Errors.
    • Please provide the Fatal Errors that were displayed.
    • Was this a single plugin update or a bulk plugin update?
      • Bulk plugin update:
        • Where was the failed plugin in the list of plugins to be updated?
        • Were you on the Dashboard > Updates page, the Plugins > Installed plugins page, or WP-CLI?
  • No: Continue

Was the wp-content/temp-backup/plugins folder empty?

  • Yes: Thank you! Please report your results, and environment details, in the comments below.
  • No:
    • Please provide your environment details.
    • Please provide the name of the plugin(s) that remain in wp-content/temp-backup-plugins.
    • Was this a single plugin update or a bulk plugin update?
      • Bulk plugin update:
        • Where was the failed plugin in the list of plugins to be updated?
        • Were you on the Dashboard > Updates page, the Plugins > Installed plugins page, or WP-CLI?

Where do I report issues?

Please report test results or issues as comments on this post. Please list your environment in your results.

Editing assistance from birds and squirrels, also @ironprogrammer, @davidbaumwald, @hellofromtonya

#rollback

An Update on Preferred Languages

5 years after announcing the Preferred Languages feature project and implementing the first prototype, it’s time for a long overdue update on where things currently stand.

More than half of all WordPress sites in the world use a language other than US English. For these sites and users, the options to change the site and user language are great. But when there’s no translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. for a given 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 or theme, WordPress falls back to US English. That’s a poor user experience for many non-English speakers.

The Preferred Languages plugin solves this issue by doing the same thing operating systems, browsers, and other types of software have been doing for years. It lets you select multiple preferred languages in your settings. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list.

The Preferred Languages UIUI User interface

Recent New Features

After stabilizing the initial prototype, the feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. has lived a mostly dormant life, with only irregular updates here and there. Adding support for JavaScript i18n introduced in WordPress 5.0 was the biggest enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. With the plugin being stable and used on thousands of sites without issues, there was simply no need for any other change. Yet, the plugin was far from feature complete.

Over the past year, I blew the dust off and made significant improvements to the plugin:

  • Bringing UI and code up-to-date with latest WordPress version
  • Improved 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 support, bringing Preferred Languages to Networknetwork (versus site, blog) settings
  • Site Health integration
  • Increased test coverage
  • Improved compatibility with other plugins, especially those accessing the locale user metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
  • Added an option to merge incomplete translations to avoid fallbacks to US English

The latter is actually a pretty cool enhancement and can be enabled using 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.. Here’s what it does:

Let’s say your preferred languages are es_CR, es_MX, es_ES, en_US (in this order). With this feature, if some of the translations are incomplete, your site will be displayed in es_CR, with missing strings taken from es_MX, es_ES etc. Without this feature, missing strings would simply be displayed in US English straight away. Merging translations this way makes for a much better user experience.

What’s Still Missing / Open Questions

Textdomain Registry

Since the Preferred Languages feature plugin also needs to work well when switching locales, #39210 has been a missing feature for a long time. While the plugin has its own implementation of a textdomain registry originally created (but then reverted) in that ticketticket Created for both bug reports and feature development on the bug tracker., it is required for this change to finally land in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

My hope is that this can be implemented in WordPress 6.1+.

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/. Code Base

The initial version of the Preferred Languages plugin was built in a pre-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/ era, using jQuery and jQuery UI Sortable. It doesn’t make much sense to potentially merge such a new UI component into core that is built with those technologies.

Rather, some time should be spent to rebuild the client-side code. There are two possible options here:

  1. Rewrite in vanilla JavaScript, replacing jQuery with modern Web APIs. This is most feasible when removing the capability to sort languages using drag & drop, for which jQuery UI Sortable is currently used.

    If we’re okay with dropping drag & drop functionality, then this would be a straightforward change.
  2. Rewrite everything in ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.. A prototype of this actually exists, so it’s mostly a matter of finishing it up & perhaps submitting some upstream PRs to Gutenberg for any missing features.
    Using React would be more in line with current best practices and expansion of Gutenberg throughout WordPress adminadmin (and super admin). Such a rewrite would also facilitate potential use of the component directly within a Gutenberg context.
    On the other hand, it would significantly increase overall code size and thus maintenance burden, for little immediate benefit.

While I am currently heavily leaning towards the first option, inputs are always welcome!

Of course, if we are okay with keeping jQuery & jQuery UI Sortable, then no change is needed at all.

The Next Steps

The Preferred Languages feature plugin can always use help with development and testing. Right now resolving the two open questions is the main priority before proposing merging this functionality into core.

Active development is taking place on GitHub. If you want to get involved, check out open issues and join the #core-i18n channel on Slack.

#feature-plugins, #feature-projects, #i18n, #polyglots, #preferred-languages

Version 1.0.0 of the Performance Lab plugin published

The first stable version 1.0.0 of the Performance Lab 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 has been released. You can download it from the WordPress plugin repository or via GitHub.

The stable release means that the Performance Lab plugin’s infrastructure is now out of betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. testing stage. The plugin’s primary purpose remains to facilitate beta testing for future WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance features and enhancements, as outlined in the original plugin announcement post. The initial beta phase for the plugin was primarily to allow the performance team to discover early infrastructure bugs and fix them before the stable launch.

Included modules

The following modules are included in the 1.0.0 release:

  • WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
  • WebP Support: Adds a WebP support check in Site Health status. View related GitHub issues
  • Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
  • Audit Autoloaded Options (experimental): Adds a check for autoloaded options in Site Health status. View related GitHub issues
  • Audit Enqueued Assets (experimental): Adds a CSSCSS Cascading Style Sheets. and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. resource check in Site Health status. View related GitHub issues

Next steps

The performance team is going to continue enhancing the existing modules and evaluating additional modules to add in the future. The cadence and versioning strategy for upcoming releases is currently up for discussion. Please provide your feedback on plugin versioning in this issue if you are interested. There is an ongoing vote in that issue which is open until 2022-05-02 17:00 UTC.


Kudos to all the people that have contributed to and tested the Performance Lab plugin so far and made this first stable release possible! Let’s keep testing and iterating on the individual features to bring each of them closer to an eventual WordPress core merge.

Props to @mxbclang @adamsilverstein @jeffpaul for review and proofreading.

#feature-plugins, #feature-projects, #performance, #performance-lab

Bug Scrub for Two-Factor plugin

The Two-Factor plugin is nearing a 0.8.0 release and as part of that @georgestephanis and myself have scheduled 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. scrub for Wednesday, March 23rd at 13:00 UTC in the #core-passwords 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/. channel.

The primary focus of the scrub will be reviewing PRs in the milestone to see which are ready (or close enough) to be wrapped up and merged versus punted to a future release. We will also review issues in the milestone that don’t have a linked PR to see if they’re urgent enough to work on a PR versus punted to a future release. The most pressing issue is two-factor#423 given its already impacting, so particular focus on that and its associated PR#427 will likely be where we begin the conversation.

The most helpful thing would for folks present during the scrub, or also helping asynchronously, will be testing those PRs in the milestone to ensure that they (1) resolve the root issue and (2) have no merge conflicts. Leaving a comment with your results on PRs will help dramatically.

There’s no immediate timeline for the 0.8.0 release though once we get through the bug scrub George and I will have a better sense of what work remains in getting 0.8.0 released. The sooner we can get a release out that includes a resolution for two-factor#423 the better, so thanks to all for helping!

#2fa, #two-factor

The Performance Lab plugin has been released

Introducing the Performance Lab 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: After the WordPress performance team began work on it in November 2021, the first version of the plugin is finally here and ready for testing. You can download it or install it directly from your WordPress dashboard. Your testing and feedback will allow iterating towards adding future performance optimizations in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

What is the Performance Lab plugin?

The Performance Lab plugin is a set of modules that aim to improve performance in WordPress. While this may sound similar to the numerous other performance plugins in the WordPress ecosystem, the Performance Lab plugin exists for an entirely different purpose: It is a collection of performance-related “feature projects” for WordPress core.

Feature projects are intended to gather a group of people to explore potential ideas for WordPress core.

Feature Projects Overview

Historically, feature projects have usually been implemented as separate feature plugins. The Performance Lab plugin provides a centralized location for performance-related features which are intended to eventually be merged into WordPress core. Therefore, it should be considered a 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.-testing plugin. The plugin’s performance modules can be individually enabled in the plugin’s settings screen, so that they can be tested in isolation or in combination. Being able to activate/deactivate modules is similar to activating individual plugins, but the Performance Lab approach comes with benefits: For both developers and end users, it removes the burden of keeping track of several plugins. For developers, it additionally reduces maintenance and encourages collaboration between developers.

Settings > Performance screen of the plugin with a list of modules that can be individually toggled on and off
The Performance Lab plugin’s settings screen

Another benefit of the single plugin approach taken with the Performance Lab plugin is that it provides room for experimentation. Some modules included in the plugin are explicitly marked as experimental, and while the entire plugin is for testing WordPress performance features, those modules are at a particularly early stage of exploration and therefore could lead to unexpected results This also leads to the clarification that all performance modules bundled in the Performance Lab plugin are at different stages of development. For example, some may already be official WordPress core feature projects, others may be proposed as feature projects in the near future. Some experimental modules may remain in exploration for a few months to come.

Because the Performance Lab plugin is a collection of potential WordPress core feature modules, the list of modules included may drastically change over time. New modules may be added regularly, while other modules may be removed in a future plugin version once they have landed in a WordPress core release. Also keep in mind that the Performance Lab plugin is not a full replacement for other WordPress performance plugins you may be using already.

Who develops the Performance Lab plugin?

The Performance Lab plugin is being actively worked on by the WordPress performance team, which was formed in late October 2021. The plugin is the primary project of the team where new performance features are being explored and implemented. It complements the direct contributions to WordPress core, which happen for smaller fixes or for features that already have seen significant testing in the plugin.

The modules included in the plugin are based on the priorities of the performance team contributors who meet weekly in the #performance Slack channel to discuss the ongoing efforts and priorities. The performance team takes into account the impact of different features while prioritizing work, and the modules included are also influenced by contributor interest. So far, over 250 people have joined the performance 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/. channel, with many of them participating in the weekly chats and reporting issues on GitHub. While code contributions to the plugin so far have been limited to just slightly more than 10 contributors, the performance team is confident that the volume of code contributions will increase over time, especially as the plugin starts seeing increased usage.

Which features come with this initial Performance Lab plugin version?

This initial release of the Performance Lab plugin (1.0.0-beta.1) comes with the following modules:

  • WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server. View related GitHub issues
  • WebP Support: Adds a WebP support check in Site Health status. View related GitHub issues
  • Persistent Object Cache Health Check: Adds a persistent object cache check for sites with non-trivial amounts of data in Site Health status. View related GitHub issues
  • Audit Enqueued Assets (experimental): Adds a CSSCSS Cascading Style Sheets. and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. resource check in Site Health status. View related GitHub issues

To test the WebP Uploads module, upload some JPEG images to the Media Library, and the module should ensure that the sub-sized versions are also generated in WebP and then used in the front-end when embedding such uploaded images in a post.

To test the other three modules, visit the Site Health status tab, where each module adds a corresponding new check:

  • The Audit Enqueued Assets module monitors the amount of scripts and stylesheets enqueued on your homepage.
  • The WebP support module checks whether your server environment supports creating WebP images.
  • The Persistent Object Cache Health Check promotes usage of an external object cache depending on the amount of data on your site.

Remember that each module you would like to test has to be activated via the plugin’s settings screen at Settings > Performance. Non-experimental modules are enabled by default. If you want to test the modules individually in isolation, you can toggle them one by one.

To learn more about the modules, you can use the 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/ labels to follow along their development via the links from the list above. You can also review the full release changelog.

How can I support the Performance Lab plugin?

Since the Performance Lab plugin is a beta testing plugin, the most straightforward way of contributing is to use it! Test the individual modules, try to break them, explore edge-cases etc. Any feedback or 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. reports are welcome as GitHub issues or alternatively as wordpress.org support forum requests. If you have found a bug and already discovered a fix for it, you can submit a  pull request. You’re also invited to share your feedback in a review. Last but not least, share the news! Only with a solid number of regular testers can the features in this plugin mature over time.

If you would like to participate in developing or shaping the direction of the plugin, the performance team would be pleased to have you join the weekly chats in the #performance Slack channel! The next one will take place at March 8, 2022, at 16:00 UTC.

Another area to contribute to the plugin is localization. If you speak a language other than English, help make the Performance Lab plugin available in your localeLocale A locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English. by contributing translations.


Many thanks to all the community volunteers that have contributed to the Performance Lab plugin and the overall efforts of the performance team so far! This beta release is a major milestone and just the beginning – let’s continue from here.

Props to @addyosmani @jonoaldersonwp @tweetythierry @mxbclang @adamsilverstein @clarkeemily @mitogh @dainemawer @justinahinon for review and proofreading.

#feature-plugins, #feature-projects, #performance, #performance-lab

Feature Project: Plugin Dependencies

Problem

This feature project began as part of Outcome 4 of Updating the Updaters.

Any 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 that requires another plugin (i.e., a dependency) is on its own to make sure admins install the dependency. After all, the plugin will not work without it. But with more than 55,000 plugins in the repository, that means there are potentially 55,000 plugins capable of resolving the dependency.

It would be a lot simpler for users and admins, and plugin developers, if there were a consistent way to handle dependencies in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Among other things, that approach would entail a clear method of determining when a plugin needs a dependency and what that dependency is.

Improving the plugin experience.

There’s a whole categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. of plugins that are designed from the ground up to add new abilities to other plugins. Think of shipping and other add-ons for commerce plugins, and one-click checkout for event plugins that sell tickets.

The situation there is a lot like the relationship between parent and child themes. Without their relationships to the bigger plugin, those dependent plugins can do very little. As noted above, every plugin developer is on their own to code a solution to resolve the issue. And, as noted above, the single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins. 

What’s more, this is not a new problem. Across the WordPress ecosystem, people have been looking at it for at least nine years—starting with #22316.

The original scope listed in #22316 was the following.

  • Plugins list WP.org slugs of their dependencies in their readme.txt, or perhaps better their plugin’s 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..
  • When you go to install a plugin via the plugin directory UIUI User interface in the adminadmin (and super admin) area, the WP.org 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. returns a list of dependencies along with the data about the plugin being installed. WP would say like “these following dependencies will also be installed”. This means it’s seamless to the user — they install a plugin and the other plugin(s) that are needed get installed too.
  • No versioning support. It’s too complicated and what if one plugin wants an older version of a dependency than another plugin does? If your plugin is listing another as a dependency, then it’s your job to make sure it stays compatible with the latest version of the dependency. On the flip side, hopefully plugins that get listed as dependencies are made to be forwards and backwards compatible.
  • Probably not allowing the disabling of plugins that are dependencies while their dependents are active. This seems better than disabling the dependents when the dependency is disabled (“why did Foo get disabled? I only disabled Bar!”).
  • On plugin re-activation or on activation of a plugin uploaded via FTPFTP FTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients., make sure it’s dependencies are already installed. If not, offer to install them. If installed but disabled, just enable them for the user.

The last bullet point implies automatic installation and/or activation, after previous discussions, it was thought this should be discouraged in the name of preventing a very jarring user experience.

Fundamentally there should be a simple, clear method for identifying and installing plugin dependencies. Any plugin that requires a dependency should degrade gracefully if that dependency is not present. This is the responsibility of the plugin developer.

Design/Discovery

There are hundreds of comments, ideas, and decisions that have been discussed on #22316 and on some of the PRs below. I will attempt to summarize.

  • This is not an attempt to create a plugin package manager.
  • This is not an attempt to integrate Composer into WordPress or use Composer.
  • The agreed upon interface is via a plugin header, Requires Plugins, containing a comma-separated list of plugin slugs.
  • The most agreed upon UI for notifying users of a missing dependency requirement is via an admin notice.
  • There is no attempt at version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories.. The current plugin version in the dot org repository will be used.
  • There is no automatic installation or activation of the dependent plugin.
  • If the dependency requirements are not met, the requiring plugin cannot be activated.
  • Dependencies outside of the dot org repository are not directly supported, but may be added by correct use of the plugins_api_result 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 is only for plugin dependencies that are required not recommended.
  • Plugin dependencies for themes is out of scope at this time.

Current Suggested Solutions

There are currently two approaches to handling plugin dependencies.

Similarities

  • Both use a plugin header, Requires Plugins, that contains the plugin dependencies within a comma-separated list of dot org plugin slugs.
  • Both show the user an admin notice if there are plugin dependencies should be installed.
  • Users must actively install and activate the dependencies.
  • Users will find they cannot delete or deactivate installed and activated plugin dependencies without deleting or deactivating the plugin that requires the dependency.
  • Relevant messaging in the dependency plugin row of the plugins page. (Formatting differs between approaches)
  • Neither approach makes any attempt at dependency version control. Most recent version of dependency from dot org is used.

Differences

The differences in the two approaches are subtle, but they do exist.

Current PRs

Approach 1

https://github.com/WordPress/wordpress-develop/pull/1547

  • Shows an admin notice for each plugin dependency to both inform the user of the dependency and lets the user install/activate with a click.
  • Plugins with unmet dependencies do not get activated; they go into an activation queue. Once dependencies are met the plugin is activated. 
  • Users can cancel activation requests for plugins with dependencies. Messaging added as an additional element to the plugin row.

Screenshots from PR

I hope the screenshots are representative of the PR. If not, it is entirely my fault (@afragen)

Approach 2

https://github.com/WordPress/wordpress-develop/pull/1724

  • A single admin notice alerts the user to unmet dependencies in any plugin. If multiple plugins have dependency problems, the notice compiles all the notices in one place. This notice persists until all dependencies have been installed. 
  • Adds dependencies using a new view/tab/filter on the plugins-install.php page.
  • On the plugin card, shows which plugins require which dependencies.
  • Once a particular dependency is installed, shows a list of plugins that require it at the end of the plugin’s description in the plugin row.
  • Adds relevant messaging to the plugin’s description.
  • Automatically deactivates any plugin that has unmet dependencies and informs the user in an admin notice. 
  • Lets the user deactivate or delete a dependency if the requiring plugin is not active.
  • Install the Plugin Dependencies Tab plugin as a possible feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins..

Some of the screenshots below may be slightly outdated.

Screenshots from PR

When attempting to activate a plugin with unmet dependencies.
Dependencies tab info

Further Discussion

Pertinent discussions about the best way to implement this are still needed. It doesn’t have to be one of the above approaches, but they are certainly starting points.

Thanks to @peterwilsoncc, @aristath, @audrasjb, @karmatosed, @costdev for assistance along the way. Thanks @marybaum, @bph for editing assistance.

Special thanks to @francina for the initial nudge.

#core, #feature-plugins, #feature-projects

[Feature project] Updates on updating the updaters

Sorry, I couldn’t help myself…

In November 2020, I posted about an initiative to update the updaters. It took a bit longer than expected to research the issue and an efficient way to manage the project, but here we are.

Context

The WordPress updaters are a set of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher classes that assures that users can safely upgrade WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins, themes, and translations.

The ability to manually update WordPress from the adminadmin (and super admin) area, and to install and update plugins and themes, has existed since 2.3 in 2007. Auto-update features were added in WordPress 3.7 (for minor releases), extended in 5.5 (as opt-in for plugins and themes), and 5.6 (major releases). To make the user experience of auto-updates even better, and build trust with users and extenders, it’s important that this mechanism works well and provides all the failsafe checks needed.

The WordPress Core update has proven to be generally reliable, but it doesn’t actually have many tests nor is well documented. There are also some reliability concerns around adding new files and the overall number of changed files, which is the reason WordPress currently tries to keep the number of changed files in minor releases to a minimum.

Plugins and themes updaters are older: in general, all of them can be improved.

Goal

The project goal is to review the existing state of the updaters and propose ways to improve them.

Outcomes

The expected outcomes are:

  1. Make sure the zips upload and unpacking are safe.
  2. Create a mechanism to upgrade and rollback.
  3. Have managed updates (database migrations).
  4. Create a unified 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. convention for requirements and dependencies.

Outcome 1 – Make sure the zip uploads and unpacking are safe

With the introduction of auto-updates, these processes run more frequently.. So relatively small issues get triggered more often, and with that become a bigger problem. They also now more often run unattended: an auto-update that breaks could lead to quite problematic results.

The goal here is to address most of the known issues related to:

  • downloading and extracting update packages
  • copying files and directories
  • improving documentation for updates
  • adding some automated tests
  • making the update process more reliable in general

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

Edited 2021-05-06T19:38 MDT: added #36710 and #36373 to the list of tickets. @pbiron.

Outcome 2 – Create a mechanism to upgrade and rollback.

When a core auto-update fails, core has long had the ability to automatically attempt a “rollback” to the latest stable release (in the branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". that the site is running). Note: for core auto-updates, “rollback” is not attempted for certain failures (e.g. “disk full”, etc).

This capability should be extended to be available for plugin and theme updates. Work on some of these issues is already undergoing as part the rollback update feature.

Related Trac tickets

Outcome 3 – Have managed updates (database migrations)

Plugins should be able to easily run database migrations, so that update and rollback could be performed not only for files but also for data.

Yoast already does this by having a migrations library:

If we had a unified process for data migrations in core, WordPress would be able to run the latest available migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. after an update or rollback:

  • without the need to store anything about the previous state
  • without requiring anything from the plugin author, apart from adding a “migrations” folder

Relevant Trac tickets

Outcome 4 – Create a unified JSON convention for requirements and dependencies.

Different plugins have introduced compatibility tags (For example, Elementor and WooCommerce). In the long run, this could become harder to manage.

Relevant Trac tickets

@afragen has written a lightweight library, wp-dependency-installer, that takes a JSON config file and can install a suggested or required plugin dependency. He mentions this as a lighter-weight solution to something like the TGMPA library. This makes it possible to solve many of the issues above.

How to contribute

  1. Familiarize yourself with the existing classes, listed above.
  2. Update your local WordPress SVN (use svn up) or Git repo (use git pull) to the latest version of WordPress trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision..
  3. Pick a ticketticket Created for both bug reports and feature development on the bug tracker. from the above list, review its history, refresh it if needed or make a new patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing..
  4. Upload your patch to the Trac ticket you created, and add the keywords has-patch and needs-testing
  5. If during the exploration of the above goals you can think of other enhancements, please create a new ticket and assign it to the Update/Install component

Keeping Discussions Focused

Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what this feature project is about should take place during the weekly chat in the #core-auto-update 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/..

What’s next?

See you on May 4, 2021 at 17:00 UTC for the kickoff meeting, during the weekly #core-auto-update.

In the meantime, if you already know that you want to work on a specific goal or a specific ticket, please leave a comment.

Thank you!

Thanks @afragen, @audrasjb, and @hellofromtonya for the peer review. Thanks @sergeybiryukov for combing through Trac to look for the tickets!

#auto-updates, #updater

Feature Plugin: Rollback Update Failure

This feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. is an offshoot of Matt’s 9 Projects for 2019. Specifically it’s a follow-up to auto-updates for plugins and themes. Our goal is to provide a safety mechanism of sorts should an update, including auto-updates, fail potentially leaving the user’s site in an unstable state.

This is a feature plugin based on the PR for #51857. We are working towards inclusion in WordPress 5.8. The general overview is to provide a mechanism whereby a failed 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 or theme update does not leave the site in an unstable state. This part of the project is not about ensuring that a successful update does not cause any issues.

Some of the issues of failed updates include:

  • Having a plugin folder content be deleted and the plugin no longer active.
  • Having a plugin not completely update and result in a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher fatal message or WSOD

While these are not the only results of failed updates, they seem to consistute the majority of reported issues.

The assumption is that most of the errors in large plugins/themes occur during the copy_dir() part of WP_Upgrader::install_package(). TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #52342 brought more error reporting to copy_dir() and Trac ticket #52831 provides 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. hook in order to process the rollback in the event of a plugin/theme update failure. As of WordPress 5.7-beta1 both of these tickets are in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

It is during the WP_Upgrader::install_package() that the currently installed plugin/theme is deleted in anticipation of copying the new update into that location. Having an empty plugin/theme folder or an incompletely copied update seems to be the most common issue.

Rollback Update Failure Feature Plugin is available for feedback and testing. Contributions from the WordPress community are welcome on the plugin’s GitHub repository.

Testing

There was much discussion regarding the thought that adding additional IO processes for the zip and unzip process could result in server timeout issues on resource starved shared hosts. Activating the feature plugin will result in the creation of a ZIP file of the installed plugin/theme being updated every time an update is performed. The unzip only occurs during testing or if a WP_Error is returned from WP_Upgrader::install_package(). Any issues would only happen during a plugin or theme update.

For the sake of testing assume any server timeout occurring during the update process might be releated to the additional IO processes creating the zipfile. Please report these in GitHub Issues and report your server details. ( Host, RAM, OS, etc. )

There will be messaging in the event of an error and successful or unsuccessful rollback.

To simulate a failure, use the filter add_filter( 'rollback_update_testing', '__return_true' );

Alternatively you can install the Rollback Update Testing plugin, activating it as needed. If you have GitHub Updater installed, you can easily install this Gist from the Install Plugin tab. Select Gist as the Remote Repository Host.

Next Steps

The Rollback Update Failure feature plugin is an early step towards inclusion in WordPress Core. We need your help. Simply installing and activating the plugin will help test whether or not the additional server IO processes may cause issue with resource starved shared hosting.

Thanks @audrasjb for reviewing.

#rollback

Upgrade/Install Component meeting summary – February 9, 2021

These are the weekly notes for the Updates/Install component meeting that happened on Tuesday February 9, 2020. You can read the full transcript on the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates 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/. channel.

This meeting was focused on the Rollback Failure Update Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., which is a project led by @afragen.

Contribute to the Rollback Failure Update feature plugin

For now, this feature plugin is located on @afragen’s GitHub account: https://github.com/afragen/rollback-update-failure.

Everyone is welcome to contribute. Please feel free to get in touch with the #core-auto-updates team on Slack.

Quick recap of the feature plugin goals

This is a feature plugin based on the Pull Request proposed in the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #51857. The assumption is that most of the errors in large plugins/themes occur during the copy_dir() part of WP_Upgrader::install_package(). Trac ticket #52342 brought more error reporting to copy_dir() and Trac ticket #52831 provides 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. hook in order to do the actual rollback in the event of a 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/theme update failure. As of WordPress 5.7-beta1 both of these tickets are in core.

There was much discussion regarding the thought that adding additional IO processes for the zip and unzip process could result in server timeout issues on resource starved shared hosts.

Activating the feature plugin will result in the creation of a ZIP file of the installed plugin/theme being updated every time an update is performed. The unzip process only occurs during testing or a WP_Error resulting from WP_Upgrader::install_package().

Next steps

  • The Upgrade/Install team will publish a Feature Plugin proposal on Make/Core;
  • The feature plugin will be released 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/ plugins repository;
  • A MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. ticket will be opened on the Meta Trac in order to ask the meta team to create a new 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/ project in the WordPress.org GitHub account. @afragen will lead this projet on the WordPress GitHub account;
  • Provide visibility to the feature plugin;
  • Test, learn, iterate.

#auto-update, #auto-updates, #feature-plugins, #feature-autoupdates, #updates