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

Deprecated JavaScript globals

In WordPress 5.5 the global 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/. objects listed below were removed without being deprecated. WordPress 5.5.1 adds a backfill for these globals so they no longer cause JavaScript errors. The following objects were removed:

  • adminCommentsL10n
  • attachMediaBoxL10n
  • authcheckL10n
  • commentL10n
  • commonL10n
  • inlineEditL10n
  • navMenuL10n
  • postL10n
  • plugininstallL10n
  • privacyToolsL10n
  • setPostThumbnailL10n
  • tagsl10n
  • tagsSuggestL10n
  • userProfileL10n
  • wp.themePluginEditor.l10n
  • wp.updates.l10n
  • wpColorPickerL10n
  • wpPointerL10n
  • wpWidgets.l10n

This means that referencing these objects would result in a JavaScript error and would thus halt JavaScript execution. Some of these objects were being used in very popular plugins & themes. @omarreiss and I researched where these were used. This Google sheet shows the impact.

If we only count plugins or themes with more than 100k installs or more, some of these already have an incredible impact. Which is why we decided to 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. this as fast possible.

What will change?

WordPress now redeclares these globals, and they now fail silently: they return an empty string and throw a console error. This makes sure that JavaScript doesn’t break, and also makes clear to 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 developers that they need to adapt. Their code still needs to be updated to fix the translations, preferably using wp.i18n, but the problem no longer blocks JavaScript execution.

What if you already patched this?

If you’d already patched this, which we’ve seen in several plugins and themes, the new patch on coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will return your reinstated object. We will however still throw a deprecation warning in the console. Please switch to using wp.i18n.

Deprecation policy

The plan is to remove this fallback code in two major versions, so this will be deleted in WordPress 5.7. This gives plugin and theme developers ample time to remove the conflicting code and switch to using wp.i18n.

Props @sergeybiryukov for reviewing.

#5-5-1, #dev-notes

WordPress environment types

In WordPress 5.5 we introduced the new wp_get_environment_type function which allows retrieving the type of environment the current system is. We originally allowed changing the environment types, which we’ve decided is a mistake. It makes it so that plugins and themes can’t rely on any given environment being one of a limited and known list of types, and thus can’t rely on the feature.

For this reason, as of WordPress 5.5.1 it will no longer be possible to override the list of possible environment types.

Which environment types do we have?

The following environment types will be supported as of 5.5.1:

  • production – this is the default. A site that is running live, connected to the internet and reachable on the internet.
  • staging – this is what you would use for staging environments, probably both connected to and reachable on the internet.
  • development – this is what you would use for development environments that are reachable on the internet, we automatically enable WP_DEBUG on environments where this is the environment type.
  • local – added in 5.5.1, this (usually development) environment can reach the internet but is not be reachable from the internet.

By limiting the set of environment types in this way, WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins, and themes can change their behavior depending on this setting.

What happens if you changed the setting?

If you’d already set an environment variable to allow changing the environment types, this will no longer function. If you’d set the WP_ENVIRONMENT_TYPE constant to something else than one of the four allowed environment types, it will reset to production.

Props @johnbillion, @audrasjb, and @sergeybiryukov for reviewing.

#5-5-1, #dev-notes

Introduce wp_cache_get_multiple() in WordPress Core

Many object caching backends, such as Memcached and Redis support getting multiple values in a single request. Fetching multiple values in one request often results in much faster performance, as it means less requests on an external object cache. However WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. only supported getting one cache value at a time with the wp_cache_get() function. In WordPress 5.5 a new function was added called wp_cache_get_multiple() with the capability to get multiple cache keys in a single request. The function wp_cache_get_multiple() accepts an array of keys and fetches multiple cache values from the same group.

There are some existing plugins like Advanced Post Cache, Memcached Redux or Redis Object Cache that have already implemented a function called wp_cache_get_multi() that serves a similar purpose to wp_cache_get_multiple(). However this function had a different signature to wp_cache_get_multiple(), as it is allowed an array of keys and groups to be passed, allowing for any cache key to be fetched. To avoid conflicts with numerous plugins that implement the wp_cache_get_multi() function, it was decided to change the name of the function to wp_cache_get_multiple() to stop PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 errors and developer confusion.

To start using wp_cache_get_multiple(), creators and maintainers of object caching plugins ( drop-ins ), will need to implement this new function. For plugins that are yet to implement this new function, core will detect that the wp_cache_get_multiple() function does not exist. If it does not exist, then adds a compatibility shim to add the wp_cache_get_multiple() function that simply calls wp_cache_get() internally.

Along with adding this new function, WordPress core has implemented it in the following places.

  • update_object_term_cache()
  • update_meta_cache()
  • _get_non_cached_ids()

See implementation Core 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.: #50352

See full details of the eight year journey to getting this ticket into core can be found in Core Trac #20875.

Props to justinahinon and sergeybiryukov for proofreading.

#5-5, #cache, #dev-notes

Accessibility improvements to Media component in WordPress 5.5

WordPress 5.5 introduced several improvements in the 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) of the Media component.

Improvements in the accessibility of the status and error messages in the Image Editor

On previous WordPress versions on the Edit Media page, when activating the “Restore Image” button, a message was shown above the image while the Restore button itself disappears.

Since the button would have been focused at the time when activated by keyboard, this causes the keyboard focus position to be lost and reset to the top of the page.

The message itself is also not announced by screen readers, and may not be visible to screen magnification users if it appears outside their current view.

WordPress 5.5 improved the behavior of notices inside the Edit Media page with the followings:

  • Improves the focus management by moving focus to the notices, if any, or to the first “tabbable” element: this avoids a focus loss and helps Braille-only and screen magnification users to be aware of the messages.
  • Adds an ARIA role alert to all the notices.
  • Uses wp.a11y.speak() to announce messages to assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology: this leads to all visual users seeing the messages while assistive technology users will get an audible message.
  • Uses wp.i18n for translatable strings in wp-admin/js/image-edit.js

Related 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.: #47147.

Fix the Image Editor mismatching keyboard focus order and visual reading order

On the Edit Media page, the keyboard focus order and the visual reading
order were presented in a zig-zag pattern.

This was causing some accessibility issues for users who have a cognitive disability as they may be confused by an unexpected or illogical focus order.

WordPress 5.5 fixed that by swaping the DOM order of the two main columns within the adminadmin (and super admin) Image Editor.

See more details in the Trac ticket #47136 and the attached changeset.

Improve the appearance of image editor on small and medium screens

WordPress 5.5 added new CSS rules to improve the appearance of image editor on small and medium screens. The new rules prevent the main area of Edit Media screen from being pushed down too far.

See the related ticket on Trac: #47136.

Props to @afercia for proofreading.

#5-5, #accessibility, #dev-notes, #media

Allow post boxes and metaboxes to be reordered by using the keyboard

Before WordPress 5.5, it was possible to rearrange widgets on the Dashboard and metaboxes on post editing pages (with 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/ disabled) using only a pointing device, such as the mouse. This was causing 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) issues, since it was not possible to perform the same actions with the keyboard. It was also challenging to perform these actions on touch screens.

WordPress 5.5 solves this by adding new controls and functionalities to allow reordering the boxes with the keyboard. There are also improvements to facilitate reordering of boxes on touch screens.

Before WordPress 5.5: There were no controls to move and reorder Dashboard widgets
Before WordPress 5.5: There were no controls to move and reorder boxes
WordPress 5.5 adds "up" and "down" controls to reorder boxes easily with mouse, touch screens and keyboard
WordPress 5.5 added “up” and “down” controls to reorder boxes easily with mouse, touch screens and keyboard
Reordering boxes with keyboard in WordPress 5.5

In addition to this, sound messages are sent to the live region of the administration ARIA to inform screen reader users of the result of the rearrangement action.

For pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developers

If you develop plugins that modify the “headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.” of the post boxes, you will need to make sure you adjust your code accordingly.

Here is an example:

In WooCommerce “Edit order” pages, some WooCommerce CSSCSS Cascading Style Sheets. hide the header and the handlediv button of some metaboxes using display: none. No feature is broken and the metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. is sortable as expected because it lives in an element with the CSS class meta-box-sortables.

Plugins can customize the basic metaboxes in this way, but they should also be prepared to adjust their customizations if necessary.

Related ticketticket Created for both bug reports and feature development on the bug tracker. on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.: #39074.

Props to @afercia for technical review and @audrasjb for proofread.

#5-5, #accessibility, #dev-notes

More support for JavaScript i18n in WordPress 5.5

In WordPress 5.5, several legacy 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/. localization variables have been removed in wp-admin in favor of using the modern form wp.i18n.__().

The i18n package was introduced with WordPress 5.0 to facilitate JavaScript and dynamic UIs translationtranslation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization.. It was therefore possible to use it instead of other functions used for localization as wp_localize_script().

Several interfaces in wp-adminadmin (and super admin) already use the functions and utilities provided by i18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. for translatable strings. With WordPress 5.5, many others are now adopting this new approach.

Here are the related tickets for these changes on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.: #50235, #50525, #50526, #50527, #50535, #50553, #50576, #50577, #50578, #50579, #50596, #50597, #50599, #50601, #50602, #50603, #50604, #50605.

For developers

If you develop WordPress themes or extensions some previously globally accessible localization variables could stop working and cause breaks in your code.

You can see how to use the functions and utilities of i18n package in this p2 post.

Props to @loicblascos for raising this note topic and @francina and @johnbillion for review.

#5-5, #dev-notes, #i18n

New editor preview options

You can now preview editor content in different screen sizes. Replacing the old preview button there is now a dropdown with “Desktop”, “Tablet” and “Mobile” sizes, as well as the previous front end preview option.

The new preview options currently only work on medium to large screens (>= 600px). In the future, there may be a way to preview large screens on a phone.

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

If you’re a block developer and would like to have responsive styles for your blocks in the editor, use the #start-resizable-editor-section and#end-resizable-editor-section markers to define responsive styles. Styles between these markers will be picked up by the editor and render correctly when it is resized. As an example, this is what your styles would look like:

#start-resizable-editor-section {
    display: none;
}

/* add all responsive styles here */

#end-resizable-editor-section {
    display: none;
}

Currently, we aren’t able to manipulate theme editor styles because they are loaded inline in a <style> 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.), instead of a separate stylesheet.

Related pull request on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ for this feature: https://github.com/WordPress/gutenberg/pull/19082.

#5-5, #dev-notes, #editor, #gutenberg

Registering default values for meta data

With WordPress 5.5, the register_meta() functions ( including register_post_meta() ) now support registering default values. Previously it was only possible to register default values for 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/. schema like this:

register_meta(
     'post',
     'greeting',
     array(
         'single'       => true,
         'type'         => 'string',
         'show_in_rest' => array(
             'schema' => array(
                 'type'  => 'string',
                 'default' => 'hello',
             ),
         ),
     )
 );

However, this would only be applied to calls made from within the REST API – calls to get_post_meta() would not use this default value. Now it is possible to pass in a default value that will be applied to all calls to any of the 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. functions, like this:

register_meta(
     'post',
     'greeting',
     array(
         'single'       => true,
         'type'         => 'string',
         'default'      => 'hello',
         'show_in_rest' => array(
             'schema' => array(
                 'type'  => 'string',
             ),
         ),
     )
 );

This brings register_meta() inline with register_setting() where it has been possible to register default values for options since WordPress 4.7.

Default values can also be paired with object sub types (introduced in WordPress 4.9.8) to limit the scope of a default value. An example of this might be if 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 registers a 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. of product. A developer could register a default value that would only apply to the post of type product.

register_post_meta(
     'product',
     'price',
     array(
         'single'       => true,
         'type'         => 'string',
         'default'      => '0.00',
     )
 );

It is worth noting that registering a default value to a custom post type like this may have some performance overhead. To determine which post type the current post ID is, it has to load that object. See get_object_subtype for more detail. In most cases, the meta and main objects are loaded at the same time (like when using WP_Query) but if your code is doing something other than just loading meta data, it may now load the main object type too.

Non-Single Metadata

It is also possible to register not-single default values like this:

register_post_meta(
     'product',
     'price',
     array(
         'single'       => false,
         'type'         => 'string',
         'default'      => '0.00',
     )
 );

When requesting multiple values, like this:

$result = get_post_meta( 123, 'price', false );

The above code will return a numeric array with 0.00, as the first value.

Validation

When registering a default meta value the data must match the type provided. The following example will trigger a _doing_it_wrong notice as hello is not an integer.

register_meta(
     'post',
     'greeting',
     array(
         'single'       => true,
         'type'         => 'integer',
         'default'      => 'hello',
     )
 );

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

If you desire to do some really custom with default meta values, there is now a filter:

$value = apply_filters( "default_{$meta_type}_metadata", $value, $object_id, $meta_key, $single, $meta_type );

This is a dynamic filter, requiring you to add the meta type. This is an example of it’s use:

function add_my_meta_value( $value, $object_id, $meta_key, $single ){
	if( 'price' === $meta_key ) {
		if ( ! $single ) {
	   		$value = array( '0.99' );
		} else {
			$value = '0.99';
		}
	}
}
add_filter( 'default_post_metadata', 'add_my_meta_value', 10, 4 );

New functions

To make this functionality possible there are two new functions added to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.:

  • get_metadata_raw()
  • get_metadata_default()

Now the get_metadata() function calls get_metadata_raw() and if the value is null, calls get_metadata_default(). So calling get_metadata() no longer gets the raw value, that is what get_metadata_raw() is now intended for.

More detail of the history of this change can be found in the original 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. #43941.

Props @timothyblynjacobs, @jjj and @justinahinon for reviewing prior to publish.

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

Recommended usage of the Updates API to support the auto-updates UI for Plugins and Themes in WordPress 5.5

This is an addendum to Controlling Plugin and Theme auto-updates UI in WordPress 5.5.

Edit 8/05/2020: An error in the example of populating no_updates for plugins has been corrected: in site_transient_update_plugins the value of response and no_update are arrays of objects; whereas in site_transient_update_themes, they are arrays of arrays. props @afragen. @pbiron

By default, the enable and disable auto-updates action links for plugins (detailed in the previous developer note) will only appear when the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Updates 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. (available since version 3.7.0) is supported.

All plugins that are hosted in the WordPress Plugin Directory and themes that are hosted in the WordPress Theme Directory already fully support the Updates API and require no changes.

Plugins and themes that are hosted elsewhere (such as premium or “private” plugins) can also support the Updates API with a little bit of code.

Though there is currently no one “official” way for such plugins to support the Updates API, this note offers recommendations for how developers can provide enough support for the auto-updates UIUI User interface to work for their plugins.

Filtering 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 update transient

The responses received from querying the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Updates API are stored in the update_plugins site transient. There are several existing filters that developers can use to add information about the availability or lack of available updates for a specific plugin that is not hosted in the WordPress Plugin Directory to that transient. The most common are:

Using pre_set_site_transient_update_plugins, for example, developers can do:

<?php
function myplugin_pre_set_site_transient_update_plugins( $transient ) {
	// Query premium/private repo for updates.
	$update = myplugin_check_for_updates( 'my-plugin' );
	if ( $update ) {
		// Update is available.
		// $update should be an array containing all of the fields in $item below.
		$transient->response['my-plugin/my-plugin.php'] = $update;
	} else {
		// No update is available.
		$item = (object) array(
			'id'            => 'my-plugin/my-plugin.php',
			'slug'          => 'my-plugin',
			'plugin'        => 'my-plugin/my-plugin.php',
			'new_version'   => $myplugin_current_version,
			'url'           => '',
			'package'       => '',
			'icons'         => array(),
			'banners'       => array(),
			'banners_rtl'   => array(),
			'tested'        => '',
			'requires_php'  => '',
			'compatibility' => new stdClass(),
		);
		// Adding the "mock" item to the `no_update` property is required
		// for the enable/disable auto-updates links to correctly appear in UI.
		$transient->no_update['my-plugin/my-plugin.php'] = $item;
	}

	return $transient;
}

add_filter( 'pre_set_site_transient_update_plugins', 'myplugin_pre_set_site_transient_update_plugins' );

Developers that have already been using the Updates API to offer updates for their plugins that are not hosted in the WordPress Plugins Directory have already been populating the response property for their plugin.

The no_update property is a requirement for the auto-update UI to work correctly for externally hosted plugins.

Some are already populating the no_update for their plugin. Any that are not should update their code accordingly for the best user experience.

Filtering the theme update transient

For themes, the responses received from querying the WordPress.org Updates API are stored in the update_themes site transient. The filters used to modify the values of these transients are similar to the ones used for plugins but slightly different:

Using pre_set_site_transient_update_themes, for example, developers of a theme hosted in a different location can do:

<?php
function mytheme_pre_set_site_transient_update_themes( $transient ) {
	// Query premium/private repo for updates.
	$update = mytheme_check_for_updates( 'my-theme' );
	if ( $update ) {
		// Update is available.
		// $update should be an array containing all of the fields in $item below.
		$transient->response['my-theme'] = $update;
	} else {
		// No update is available.
		$item = array(
			'theme'        => 'my-theme',
			'new_version'  => $mytheme_current_version,
			'url'          => '',
			'package'      => '',
			'requires'     => '',
			'requires_php' => '',
		);
		// Adding the "mock" item to the `no_update` property is required
		// for the enable/disable auto-updates links to correctly appear in UI.
		$transient->no_update['my-theme'] = $item;
	}

	return $transient;
}

add_filter( 'pre_set_site_transient_update_themes', 'mytheme_pre_set_site_transient_update_themes' );

The no_update property was only recently added to API responses for theme update queries, and like plugins, the no_update property is a requirement for the auto-update UI to work correctly for externally hosted themes.

Props @desrosj and @audrasjb for review prior to publishing.

#5-5, #auto-update, #auto-updates, #dev-notes, #feature-autoupdates