Update on July 1, 2021: Added new filter 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. info in Revisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. section. – @milana_cap
WordPress 5.8 brings a lot of smaller changes that developers should know about. Here’s a breakdown.
Build/Test Tools: Remove IE11 from the list of supported browsers
In WordPress 5.8, phase one of the dropping support for IE11 plan will take place. When considering three different data points, IE11 usage has fallen below a 1% average. After a discussion and debate, the decision was made to remove support for IE 11. In addition to opening the door for using more modern APIs, this will result in smaller script files, lower maintenance burden, and decreased build times.
The wp-polyfill script is responsible for ensuring all newer features function in the older browsers supported by WordPress. In past releases, this script was a copy of the file distributed in the @babel/polyfill package, which among other things, included regenerator-runtime.
This package was deprecated and has been replaced with the core-js package in the build process. core-js allows the polyfill file to be built dynamically, but no longer includes the regenerator-runtime script.
The regenerator-runtime script handle has been added to WordPress Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and has been added as a dependency to wp-polyfill in order to be backwards compatible with any plugin 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 registering wp-polyfill as a script dependency expecting regenerator-runtime to be present.
It is recommended that developers add the regenerator-runtime script as a dependency to any script that requires it. In future releases, removing regenerator-runtime as a dependency of wp-polyfill will be considered.
There are several other polyfill scripts included in WordPress for the sole purpose of IE11 support. They will continue to be included, but will no longer be loaded by default. They are:
wp-polyfill-dom-rectwp-polyfill-element-closestwp-polyfill-fetchwp-polyfill-formdatawp-polyfill-node-containswp-polyfill-object-fitwp-polyfill-url
For more information, see #52941, #53077, and #53078.
Formatting: More consistency and control over wp_get_document_title()
In wp_get_document_title(), the returned value is currently passed directly through wptexturize(), convert_chars(), and capital_P_dangit(), and is done so after the document_title_parts filter is run.
This makes it impossible to fully control the output of wp_get_document_title() and is inconsistent with how other similar text is processed with these functions.
The new document_title filter, which is run immediately before returning the results of the wp_get_document_title() function, moves the three formatting functions mentioned above to the new filter hook. This allows developers to further modify the title after being prepared by WordPress, or to modify the functions hooked to this filter as they wish.
For more information, see #51643.
General: Consistent type for integer properties of WP_Post, WP_Term, WP_User and a bookmark object
Some properties of the WP_Post, WP_Term, and WP_User classes are documented as integers, so it should be a safe assumption to always treat them as such. However, that is not the case when get_post() or get_term() is called with an edit, attribute, or js context, because all values are run through esc_attr() or esc_js() in that case, and these properties are unexpectedly converted to strings.
This applies to the following functions:
sanitize_post_field()sanitize_term_field()sanitize_user_field()sanitize_bookmark_field()
and the following properties:
WP_Post::IDWP_Post::post_parentWP_Post::menu_orderWP_Term::term_idWP_Term::term_taxonomy_idWP_Term::parentWP_Term::countWP_Term::term_groupWP_User::ID$bookmark::link_id$bookmark::link_rating
As WordPress moves towards strict type comparisons (see #52627 or #52482) it is important to make the type of these properties consistent in all contexts, so that using strict comparison does not cause unexpected issues.
In WordPress 5.8, these functions and properties will now reliably return an be set to integer values.
For more information, see #53235.
Posts/Post Types: Use _prime_post_caches() for speeding up cached get_pages() call
The get_pages() function uses a cache containing the ID of pages matching parameters of a previous call.
The IDs are, on a subsequent call with the same parameters, inflated using the get_post() function call. This works well in terms of the same request, as all the pages were previously added to the in-memory cache.
However, on a subsequent request, when the cache is hit, there are likely no pages already in the in-memory cache, and those need to be fetched from the backend cache server, one by one.
By taking advantage of wp_cache_get_multiple() instead of fetching each individual page from the backend cache server one by one, sites with persistent cache backend will have improved speed, but also sites without a persistent cache backend will benefit from the bulk SQL query constructed by the _prime_post_caches() function.
The performance gains should be most noticeable in case a site has a lot of pages which are being requested via get_pages() function.
For more information, see #51469.
Users: Pass $userdata to the actions and filters in wp_insert_user()
There are several action and filter hooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. within wp_insert_user() that would benefit from being able to access the raw $userdata array passed into the function. One use case where this would be useful is extending the wp user import-csv command in WP-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/. This command is a wrapper for wp_insert_user() but it’s not possible to provide custom user meta 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. fields.
Here are the hooks gaining a new parameter:
wp_pre_insert_user_data (filter)insert_user_meta (filter)profile_update (action)user_register (action)
This will allow hooked functions to perform more contextual adjustments to new users, and makes supplying custom user meta fields possible.
For more information, see #53110.
Media: Introduce image_editor_output_format filter
As detailed in a previously published dev note, WordPress 5.8 now supports the WebP image format.
WebP is a modern image format that provides improved lossless and lossy compression for images on the web. WebP images are around 30% smaller on average than their JPEG or PNG equivalents, resulting in sites that are faster and use less bandwidth. WebP is supported in all modern browsers according to caniuse.
WordPress 5.8 adds WebP support by @adamsilverstein
When images are uploaded, WordPress generates smaller sub sizes as defined using add_image_size(). By default, WordPress will generate these sub sizes in the same format as the original. Because of the performance benefits of the WebP format, it may be desirable for sub sizes to be generated in WebP instead of the original format.
In WordPress 5.8, the new image_editor_output_format filter hook can be used to change the file format used for image sub sizes. This can be used to switch all sub sizes to WebP, or any other desired format (JPEG, etc.).
The following example shows how to generate all sub sizes for JPG images using WebP:
<?php
function mysite_wp_image_editor_output_format( $formats ) {
$formats['image/jpg'] = 'image/webp';
return $formats;
}
add_filter( 'image_editor_output_format', 'mysite_wp_image_editor_output_format' );
Note: both the GD and ImageMagick libraries support the WebP format in both lossy and lossless. However, only ImageMagick supports animated images.
Setting the output format to WebP will verify if the web server supports it, and if not it will not change the format, i.e. won’t work.
For more information, see #52867.
General: Pass the scheme to all the *_url filters
A new parameter representing the URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org $scheme has been added to admin_url, includes_url, network_admin_url and user_admin_url filters. This parameter is used for giving context to the URL (such as http, https, login, login_post, admin, relative or null) and was already present in other URL related filters (home_url, rest_url, site_url, to name a few).
For more information, see #52813.
Posts/Post Types: Improve post_exists() query
In previous releases, the post_exists() function did not make use of the database indexes available and was generating a poorly performing query. A new $status parameter has been added to allow developers to specify post_type, post_date and post_status to ensure that the wp_posts table’s type_status_date index is used when determining if a post exists.
For more information, see #34012.
Themes: Introduce the delete_theme and deleted_theme action hooks
These new theme action hooks bring parity to the plugin deletion process and fire immediately before and after an attempt to delete a theme, respectively.
For more information see #16401.
Posts/Post Types: Revisions are now enabled for Reusable Blocks post type
As per ticket Created for both bug reports and feature development on the bug tracker. #53072, the wp_block post type –which is used for Reusable blocks– now supports revisions. It allows users and developers to rely on revision history for their Reusable blocks.
Changes in the_password_form filter
As per ticket #29008, the the_password_form filter now passes the post object so it can be used by developers to directly get the current post data when they override the password form rendering. This closes a long awaited ticket.
Revisions: Add a post type-specific filter to wp_revisions_to_keep()
A new wp_{$post_type}_revisions_to_keep filter has been added that makes it convenient to filter the number of revisions created for a specific post type.
This new filter will override both the value of WP_POST_REVISIONS and the wp_revisions_to_keep filter.
For more information, see #51550.
Last modified on Thursday July 1, 2021 at 10:43 UTC.
Props @desrosj, @azaozz and @audrasjb for review and additional content.
#5-8, #dev-notes
You must be logged in to post a comment.