Block Supports In WordPress 5.6

Several coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and third party blocks share different customization tools. Things like color, background, font size, alignment and others are customizations options 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. authors are likely to add to their own block. To increase the consistency and also make it easier to introduce these options into their blocks, block authors can use the Block supports 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.. WordPress 5.6 will see the introduction of a number of new block supports and allows dynamic blocks to use them as well.

Blocks can declare support for style properties

To enable the new block supports, add the desired keys to the “supports” property of the block.json file or directly into the registerBlockType function. The block editor will automatically show a UIUI User interface control for the user to set those values.

supports: {
    color: {
        background: true, // Enable background color UI control.
        gradient: true, // Enable gradient color UI control.
        text: true // Enable text color UI control.
    },
    fontSize: true, // Enable font size UI control.
    lineHeight: true // Enable line height UI control.
}

For some of these properties, the active theme may need to opt-in for them to be enabled. That’s the case of lineHeight, for example.

How it works

When the user interacts with the controls, they will automatically attach the style value to the wrapper element of the block. This works as it did before:

  • If the control offers some preset values and the user selects one of them, a class will be attached with the name .has-<value>-<preset-category> (i.e.: has-normal-font-size).
  • If the user selects a custom value, it’ll be attached as part of the style attribute of the wrapper.

Note that these are attached to the wrapper element of the block, so it works best with blocks that follow the newest apiVersion (see related dev note).

The UI controls that present users with a set of preset values, take them from the corresponding theme supports:

Dynamic blocks support

You can also use the block supports in dynamic blocks by making sure the config is added to the register_block_type server side (or the block.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.) and by rendering the block wrapper attributes in your block’s render callback function:

function my_block_render_callback_function( $attributes ) {
    $wrapper_attributes = get_block_wrapper_attributes();
    $content_markup = "something";
    return sprintf(
        '<div %1$s>%2$s</div>',
        $wrapper_attributes,
        $content_markup
    );
}

In depth

When blocks declare support for a style property, they also gain additional block attributes. These can also be used to set default values:

attributes: {
    backgroundColor: {
        type: 'string',
        default: 'value',
    },
    gradient: {
        type: 'string',
        default: 'value',
    },
    textColor: {
        type: 'string',
        default: 'value',
    },
    fontSize: {
        type: 'string',
        default: 'value'
    },
    style: {
        type: 'Object',
        default: {
            color: {
                background: 'value',
                gradient: 'value',
                link: 'value',
                text: 'value'
            },
            typography: {
                fontSize: 'value',
                lineHeight: 'value',
            }
        }
    }
}

The attributes backgroundColor, gradient, textColor, and fontSize hold any preset values the user has selected. When the user sets a custom value instead, these are stored in the corresponding key within the style attribute. Check out the documentation for more details.

#5-6, #block-editor, #dev-notes

Block API version 2

WordPress 5.6 will come with a new 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. 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. version, enabling blocks to render their own block wrapper element. This is part of a larger effort to lighten the editor content’s DOM tree so that it matches the saved content (and therefore the front-end of the site). The biggest benefit of this is that themes and plugins can more easily style the block content if the markup is the same in the editor.

Enabling API version 2

To use the new API, you must opt-in to to API version 2. If you opt-in to API version 2, you must also render your own block wrapper element with the new API. To opt-in, set the apiVersion property to 2 on the block configuration object.

registerBlockType( name, { apiVersion: 2 } );

useBlockProps

When using API version 2, you must use the new useBlockProps hook in the block’s edit function to mark the block’s wrapper element. The hook will insert attributes and event handlers needed to enable block behaviour. Any attributes you wish to pass to the block element must be passed through useBlockProps and the returned value be spread onto the element.

import { useBlockProps } from '@wordpress/block-editor';

function Edit( { attributes } ) {
    const blockProps = useBlockProps( {
        className: someClassName,
        style: { color: 'blue' },
    } );
    return <p { ...blockProps }>{ attributes.content }</p>;
}

If you wish to use the element ref, you can pass one to useBlockProps.

import { useBlockProps } from '@wordpress/block-editor';

function Edit( { attributes } ) {
    const ref = useRef();
    const blockProps = useBlockProps( { ref } );
    return <p { ...blockProps }>{ attributes.content }</p>;
}

The save function must also use the save equivalent of the hook, useBlockProps.save.

import { useBlockProps } from '@wordpress/block-editor';

function Save( { attributes } ) {
    const blockProps = useBlockProps.save( {
        className: someClassName,
        style: { color: 'blue' },
    } );
    return <p { ...blockProps }>{ attributes.content }</p>;
}

Supporting both versions

If you use API version 2, it is recommended to set the Requires at least  header field to 5.6 so 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 only updates after WordPress updates to 5.6. If users use an older version of WordPress, they would sensibly also use an older version of your plugin, hopefully encouraging them to update WordPress. It’s possible to do security fixes by releasing 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. versions for the older plugin versions, in case that is a concern.

If you really wish to support both API versions, you will need to register a different edit and save function for the previous version, either by loading a different block registration file entirely, or by passing the WordPress version number to 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/. on the front-end and conditionally setting the edit and save function at the time of block registration.

API version 1

The block wrapper element is added by the framework with the contents of Edit inside of it.

function Edit( { attributes } ) {
    return (
        <p className={ someClassName } style={ { color: 'blue' } }>
            { attributes.content }
        </p>
    );
}

API version 2

The block wrapper element must be marked by the Edit component with the useBlockProps hook.

import { useBlockProps } from '@wordpress/block-editor';

function Edit( { attributes } ) {
    const blockProps = useBlockProps( {
        className: someClassName,
        style: { color: 'blue' },
    } );
    return <p { ...blockProps }>{ attributes.content }</p>;
}

#5-6, #block-editor, #dev-notes

Site Health Check changes in 5.6

With the release of WordPress 5.6, enhancements have been made to the way the Site Health component handles, and validates, health checks.

Site Health check data validation

First up is #50145. It adds validation rules to the response form for an asynchronous site-health check.

Prior to this 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., any 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. asynchronous response would cause a fatal 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/. error, halting further processing of checks, and preventing the top of the page indicator from ever reaching a finished state.

An invalid response will now just be discarded with the introduction of this data format validator. It will not count towards the Site Health indicator or be listed among the checks.

(Oh, and you’re no longer required to add a badge to your checks. It’s useful, but not a hard requirement).

Asynchronous health checks via REST endpoints

With ticketticket Created for both bug reports and feature development on the bug tracker. #48105, we see Site Health moving away from admin-ajax.php for its asynchronous tests towards a dedicated 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/. endpoint.

Starting in WordPress 5.6, asynchronous tests can be found under the /wp-json/wp-site-health/v1 namespace.

This also opens it up for plugins and themes to utilize REST endpoints, and not just ajax actions, for their tests. To maintain backwards compatibility, each test can now declare has_rest (defaults to false). If this is of a true value, then the test argument is treated as an absolute URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org (this means that it should be a fully qualified address, and not a relative one), for example, by using the rest_url() function provided by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

The reason for using an absolute URL, over a relative one, is to give developers flexibility so they may have an external service where it makes sense to do a remote request.

Scheduled Site Health checks

Since asynchronous calls were less than ideal to query from a scheduled event when run locally, #48105 and #51547 introduce the async_direct_test argument to a test array. This argument should be a callable instance of your test, that can be run directly, without an asynchronous call.

Asynchronous calls were implemented to prevent slow tests from preventing page loads and timeouts. Such concerns do not exist in the context of a scheduled event.

You still register your tests (or remove ones that are not needed in your scenario) using the site_status_tests 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. in a way similar to this:

class My_Custom_Feature {

	/**
	 * Set up class.
	 */
	public function __construct() {
		add_filter( 'site_status_tests', array( $this, 'site_tests' ) );
		
		add_action( 'rest_api_init', array( $this, 'register_rest_route' ) );
	}
	
	/**
	 * Register rest routes.
	 */
	public function register_rest_route() {
		register_rest_route(
			'my-custom-feature/v1',
			'/test/is-working',
			array(
				array(
					'methods'             => 'GET',
					'callback'            => array( $this, 'run_test' ),
					'permission_callback' => function() {
						// Perform any capability checks or similar here.
						return current_user_can( 'view_site_health_checks' );
					},
				),
			)
		);
	}
	
	/**
	 * Filter Site health tests to add our custom test.
	 * 
	 * @param array $tests An associated array of existing tests.
	 * @return array An array of available tests.
	 */
	public function site_tests( $tests ) {
		$tests['async']['my-custom-feature'] = array(
			'label'             => __( 'My feature label', 'my-feature' ),
			'test'              => rest_url( 'my-custom-feature/v1/test/is-working' ),
			'has_rest'          => true,
			'async_direct_test' => array( $this, 'run_test' ),
		);
	
		return $tests;
	}
	
	/**
	 * Run our test to check if the test is reachable.
	 *
	 * @return array An associated array of test result details.
	 */
	public function run_test() {
		$result = array(
			'label'       => __( 'My custom function test', 'my-feature' ),
			'status'      => 'good',
			'description' => __( 'The callback to this test worked', 'my-feature' ),
			'test'        => 'my-custom-feature',
		);
		
		return $result;
	}
}

// Initiate custom function.
new My_Custom_Feature;

The above example registers a custom rest route with a direct test callback. Additionally, it adds to the array of asynchronous tests available to the Site Health component.

When a check is performed, the result will be a passing test saying the test is reachable. If the check is run during a scheduled event, the test will not use the REST API endpoint. Instead, it will call the test directly.

The REST API handling also added improved checks for HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. failure states (previously it looked for an instance of WP_Error, which is not returned in the case of a REST API error), and better listing of asynchronous tests that fail for the site user. It now informs the site user of any failures that have an error state.

Props @planningwrite for copy-edits and proofreading.

#5-6, #dev-notes

Application Passwords: Integration Guide

WordPress 5.6 will finally see the introduction of a new system for making authenticated requests to various WordPress APIs — Application Passwords.

The existing cookie-based authentication system is not being removed, and any custom authentication solutions provided by plugins should continue to operate normally.

For any sites using the Application Passwords feature plugin, it is recommended to deactivate the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party after upgrading to WordPress 5.6. However, sites won’t experience any errors if the plugin remains active. The current plan is to use the plugin for future prototyping.

Application Password Format

Application Passwords are 24-characters long, generated by wp_generate_password() without the use of special characters — so they consist exclusively of upper-case, lower-case, and numeric characters. For the cryptographically curious, that comes to over 142 bits of entropy.

When presented to the user for entering into an application, they are displayed chunked for ease of use, like so:

abcd EFGH 1234 ijkl MNOP 6789

Application passwords can be used with or without the spaces — if included, spaces will just be stripped out before the password is hashed and verified.

Data Store

WordPress will be storing a user’s application passwords as an array in 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., similar to how interactive login sessions (via WP_Session_Tokens) are stored already.

The WP_Application_Passwords class has all the methods for storing and retrieving records. Records include a number of attributes about them — including assigned name for the application, a timestamp for when it was created, and data on their last usage such as, date and IP address. Each application password is also assigned a uuid for reference, in case you’d like to build infrastructure for additional properties and store them in an alternate location.

Getting Credentials

Generating Manually

From the Edit User page, you can generate new, and view or revoke existing application passwords. The form and the list table are both fully extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. to allow for overloading to store additional data (more on this later, in “Authentication Scoping”).

The Application Passwords section of Edit User screen, after a new application password has been created.
The Edit User screen, after a new application password has been created.

Once a given password has been used, it will keep track of where and when it has been used – the “Last Used” column is accurate to within 24 hours (so that WordPress isn’t writing to the database on every usage — only if it’s a new day). This can be incredibly useful for identifying passwords that are no longer in use, so that they can be safely revoked.

Authorization Flow

To ensure that application password functionality is available, fire off a request 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/. root URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, and look at the authentication key in the response data. If this key is empty, then application passwords are not available (perhaps because the request is not over https:// or it has been intentionally disabled).

If, however, response.authentication is an object with a key of application-passwords it will offer a URL to send a user to complete the authentication flow. (You could just guess at the URL, but this gives us more of the relevant information in one go, as well as confirming that application passwords are available and enabled.)

The response.authentication['application-passwords'].endpoints.authorization url will likely look something like this:

https://example.com/wp-admin/authorize-application.php

Instead of just sending the user there to generate an application password, it would then be up to the user to reliably re-enter it into your application. So instead, some additional GET parameters are accepted along with the request:

  • app_name (required) – The human readable identifier for your app. This will be the name of the generated application password, so structure it like … “WordPress Mobile App on iPhone 12” for uniqueness between multiple versions.
    Whatever name you suggest can be edited by the user if they choose before the application is created. While you can choose to not pre-populate it for the user, it is required to create a password, so they will then be forced to create their own, and could select a non-intuitive option.
  • app_id (recommended) – a UUID formatted identifier. The app_id allows for identifying instances of your application, it has no special meaning in and of itself. As a developer, you can use the app_id to locate all Application Passwords created for your application.
    In the event of a data breach, your app_id could be distributed to void credentials generated with it, or if a site wants to allow only a given app_id or set of app_ids to register, this would enable that. However, it is strictly on the honor system — there is nothing to stop applications from generating new uuids with every authorization.
  • success_url (recommended) – The URL that you’d like the user to be sent to if they approve the connection. Three GET variables will be appended when they are passed back (site_url, user_login, and password); these credentials can then be used for 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. calls.
    If the success_url variable is omitted, a password will be generated and displayed to the user instead, to manually enter into their application.
  • reject_url (optional) – If included, the user will get sent there if they reject the connection. If omitted, the user will be sent to the success_url, with ?success=false appended to the end.
    If the success_url is omitted, the user just will be sent to their WordPress dashboard.
A screenshot of the new Authorize Application screen in the WP-Admin. A button is displayed to approve the connection, and one to reject the connection.
A screenshot of what the authorization flow will look like to a user.

As the parameters are all passed in via GET variables, if the user needs to log in first, they will all be preserved through the redirect parameter, so the user can then continue with authorization.

It is also worth noting that the success_url and redirect_url parameters will generate an error if they use a http:// rather than https:// protocol — however other application protocols are acceptable! So if you have a myapp:// link that opens your Android, iOS / MacOS, or Windowsthose will work!

Here is an example of a simple javascript application (under 100 lines of code) that uses this to authenticate to a WordPress site. Though not the tidiest code, it was created in under two hours one evening, but it goes through the proper flows and can make authenticated requests.

Programmatically through the REST API

If you have previously been using a different system to access the REST API and would prefer to switch over to using application passwords, it’s easy! You can generate yourself a new application password via a POST request to the new /wp/v2/users/me/application-passwords endpoint. Once you’ve got the new application password in the response data, you can delete any old credentials and just use the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. implementation instead — but please consider using something like libsodium (which has a library bundled with WordPress alreadyhere’s an implementation example) or Vault to store the credentials encrypted, rather than in plaintext.

Using Credentials

REST API

The credentials can be passed along to REST API requests served over https:// using Basic Auth / RFC 7617, which is nearly ubiquitous in its availability — here’s the documentation for how to use it with cURL.

For a simple command-line script example, just swap out USERNAME, PASSWORD, and HOSTNAME in this with their respective values:

curl --user "USERNAME:PASSWORD" https://HOSTNAME/wp-json/wp/v2/users?context=edit

XML-RPC API

To use a generated application password with the legacy XML-RPC API, you can just use it directly in lieu of the account’s real password.

For a simple command-line script example, again just swap out USERNAME, PASSWORD, and HOSTNAME in this with their respective values:

curl -H 'Content-Type: text/xml' -d '<methodCall><methodName>wp.getUsers</methodName><params><param><value>1</value></param><param><value>USERNAME</value></param><param><value>PASSWORD</value></param></params></methodCall>' https://HOSTNAME/xmlrpc.php

Future 🔮 APIs

The application passwords authentication scheme can also be applied to future APIs for WordPress as they become available. For example, if GraphQL or other systems are enabled in WordPress, application passwords will provide them with a solid, established authentication infrastructure to build off of out of the box.

As an example of this, with a trivial code addition identifying whether the current load is an api request, WPGraphQL will now be able to accept authenticated requests without the need of an ancillary plugin, using just the application passwords functionality that has merged into core.

Using an Application Password on wp-login.php

You can’t. 😅 The point of application passwords are that they are to be used programmatically for applications, and not by humans for interactive sessions.

Feature Availability

By default, Application Passwords is available to all users on sites served over SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions./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.. This can be customized using the wp_is_application_passwords_available and wp_is_application_passwords_available_for_user filters.

For example, to completely disable Application Passwords add the following code snippet to your site.

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Without SSL, it is possible for the Application Password to be seen by an attacker on your networknetwork (versus site, blog) or the network between your site and the authorized application. If you are ok with this risk, you can force availability with the following code snippet.

add_filter( 'wp_is_application_passwords_available', '__return_true' );

If desired, it is possible to restrict what users on your site can use the Application Passwords feature. For example, to restrict usage to administrator users, use the following code snippet.

function my_prefix_customize_app_password_availability(
	$available,
	$user
) {
	if ( ! user_can( $user, 'manage_options' ) ) {
		$available = false;
	}

	return $available;
}

add_filter(
	'wp_is_application_passwords_available_for_user',
	'my_prefix_customize_app_password_availability',
	10,
	2
);

Future Development

Authentication Scoping

In future versions, the expectation is to include the ability to scope a given application password to limit its access. The intention is to work on building this in plugin-land until it’s ready for a core proposal.

What might password scoping look like? Here’s some methods being considered:

  • In a 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 environment, either restrict the credentials to a subset of the user’s blogs, or restrict it to only operate in a normal “blogblog (versus network, site) adminadmin (and super admin)” context, and not a “network admin” context.
  • Restrict functionality to only manage content — posts, pages, comments, custom post types — and disallow infrastructure management functionality like managing plugins, themes, and users.
  • Restrict the role that credentials can allow an application to operate as. For example, an Editor may restrict a set of credentials to only operate as though they had Author or Contributor permissions.

However this is done, implementing additional functionality to enforce the principle of least privilege on an application-by-application basis is a worthwhile expansion on the included functionality.

Fine-grained Capabilities

Right now, a user’s application passwords can be managed by any user who has permission to edit_user them. The ability to customize this behavior using a new set of more fine-grained capabilities is currently planned for 5.7.

Eventually Two-Factor Authentication?

Another useful bit of application passwords is that it will removes an obstacle for the inclusion of multi-factor authentication on interactive logins.

Previously, if you enabled an interactive step — whether captcha or second factor validation — on login pages, you would be in a bind with other non-interactive authentications, for example the legacy XML-RPC system. After all, if a bad actor can just brute force or use social engineering to discern the user’s password, it would be trivially usable via XML-RPC, where there is no ability to include an interactive prompt, and that functionality would need to be disabled entirely.

With that use case now being provided for via application passwords, there is additional flexibility for the normal browser-based wp-login.php system to evolve.

Further Resources

For 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 or enhancements, open a Trac ticket in the new App Passwords component with the rest-api focus.

Props @timothyblynjacobs, @m_butcher, @desrosj, @jeffmatson, for helping to write, review, and proofread.

#5-6, #application-passwords, #authentication, #core-passwords, #dev-notes, #rest-api, #two-factor

Updating core jQuery to version 3 – part 2

A 3-step plan was outlined for upgrading the version of jQuery bundled with core in June 2020.

The first step was included with WordPress 5.5, which stopped enabling jQuery Migrate version 1.x by default.

As part of #50564, part two of this process was committed, which updated the bundled jQuery version to 3.5.1. Alongside this, jQuery Migrate was also updated to version 3.3.2.

For the duration of WordPress 5.6, the migrate script will remain enabled by default, to capture any unexpected uses of deprecated features.

Do note that the Migrate script for version 3 is not compatible with features that the previous migrate script provided a polyfill for. The features that previously were marked as deprecated are no longer available. The purpose of jQuery Migrate version 3.3.2 in WordPress 5.6 is to help with updating (migrating) all jQuery based 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/. from jQuery version 1.12.4 to 3.5.1.

When testing the changes, it is recommended to enable SCRIPT_DEBUG. This will load jQuery Migrate in debug mode, and output stack traces in your JavaScript developer console.

As this is a major upgrade to the jQuery library, please make sure you test your plugins and themes as thoroughly as possible before the release of WordPress 5.6 to avoid any preventable breakage.

The jQuery Core Upgrade Guide provides details on what features are deprecated, and removed, and how to upgrade your code accordingly.

#5-6, #dev-notes, #jquery

Introducing auto-updates interface for Core major versions in WordPress 5.6

Update: this dev notedev 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. is no longer relevant as the scope of the feature changed during WordPress 5.6 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. cycle. Please read the new dev note published for this feature:

WordPress 5.6 introduces a new UIUI User interface to allow website administrators to opt-in to major versions automatic updates.

This feature follows plugins and themes auto-updates user interface which was shipped in WordPress 5.5. Both are part of the 9 WordPress Core projects for 2019-2020.

For reference, see ticketticket Created for both bug reports and feature development on the bug tracker. #50907.

How does it look?

The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. auto-updates feature already exists for years in WordPress. WP 5.6 only introduces a new user interface to make it easier to opt-in to automatic updates for major versions.

By default, WordPress auto-updates itself, but only for minor releases. Developers can already opt-in to major releases auto-updates by setting up the existing WP_AUTO_UPDATE_CORE constant to true or by using the allow_major_auto_core_updates existing 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..

With WordPress 5.6, it’s possible for website administrators to opt-in/out to automatic updates for major versions, using a specific interface located on the Updates screen:

Core Major Versions auto-updates user interface in WordPress 5.6

How does it work?

This settings section basically adds a checkbox to allow administrators to opt-in to major core auto-updates. But it also checks for any existing constant or filter to see if the checkbox should be checked or not by default, using the following order:

  1. By default, the checkbox is unchecked.
  2. If get_site_option( 'auto_update_core_major' ) returns true, the checkbox is checked. Otherwise it’s unchecked. This option is the one stored in the database when the checkbox value is changed.
  3. If WP_AUTO_UPDATE_CORE constant returns true, beta or rc, the checkbox is checked. If the constant returns false, minor or is not defined, the checkbox is unchecked. If this constant is set, it overrides the above parameters.
  4. If allow_major_auto_core_updates filter returns true, the checkbox is checked. If the filter returns false or is not used, the checkbox is unchecked. If this filter is used, it overrides the above parameters.

To disable the checkbox by default, developers can set the WP_AUTO_UPDATE_CORE to false (to disable all auto-updates) or minor (to enable only minor core auto-updates, which is the default behavior). It has to be done using the wp-config.php file.

Developers can alternatively use the allow_major_auto_core_updates filter to set up core major versions auto-updates to true or false by default. Example:

add_filter( 'allow_major_auto_core_updates', '_return_false' );

How to extend core major versions auto-updates feature?

The feature also checks for dev (development versions of WordPress) and for minor updates. There is an action hook running right before the submit button of that settings section to add some options if needed. Using the after_core_auto_updates_settings_fields action hook, developers can add other settings or texts.

For example, the following snippet adds an option to opt-in/out for minor releases auto-updates:

function my_plugin_after_core_auto_updates_settings_fields( $auto_update_settings ) {
	if ( isset( $_POST['core-auto-updates-settings'] ) && wp_verify_nonce( $_POST['set_core_auto_updates_settings'], 'core-auto-updates-nonce' ) ) {
		if ( isset( $_POST['my-plugin-core-auto-updates-minor'] ) && 1 === (int) $_POST['my-plugin-core-auto-updates-minor'] ) {
			update_site_option( 'my_plugin_auto_update_core_minor', 1 );
		} else {
			update_site_option( 'my_plugin_auto_update_core_minor', 0 );
		}
	}
	$minor_auto_updates_settings = get_site_option( 'my_plugin_auto_update_core_minor' );
	?>
	<p>
		<input type="checkbox" name="my-plugin-core-auto-updates-minor" id="my-plugin-core-auto-updates-minor" value="1" <?php checked( $minor_auto_updates_settings, 1 ); ?> />
		<label for="my-plugin-core-auto-updates-minor">
			<?php _e( 'Automatically keep this site up-to-date with minor updates.', 'my-plugin' ); ?>
		</label>
	</p>
	<?php
}
add_action( 'after_core_auto_updates_settings_fields', 'my_plugin_after_core_auto_updates_settings_fields', 10, 1 );

This snippet adds a new option right after the major releases option:

Props @sarahricker and @jeffmatson for proofreading this dev note.

#5-6, #auto-updates, #core-auto-updates, #dev-notes

Dev Note Scrub for WordPress 5.6

With 5.6 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. 1 approaching fast, there will be a Dev Notedev 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. 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 on 10/19/2020 19:00 UTC in the #core channel on 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/..

The objectives are:

  • Recruit potential dev-note writers
  • Review tickets that need 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.

This scrub will focus on 5.6 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets that have the needs-dev-note keyword. Here’s the report: https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=closed&status=new&status=reopened&status=reviewing&keywords=~needs-dev-note&milestone=5.6&col=id&col=summary&col=status&col=milestone&col=keywords&col=owner&col=type&col=priority&col=component&col=changetime&order=changetime

What is a dev note?

A Developer note (or “dev note” for short) is a blogblog (versus network, site) post on the Making WordPress Core blog that details a technical change in an upcoming release and what developers need to know about that change.

Writing developer notes CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Handbook

Come join us.

This post was proofread by @hellofromtonya and reviewed by @davidbaumwald

#5-6, #bug-scrub, #dev-notes