Title: June 28, 2021 – Make WordPress Core --- # Daily Archives: June 28, 2021 [ ](https://profiles.wordpress.org/milana_cap/) [Milana Cap](https://profiles.wordpress.org/milana_cap/) 4:58 pm _on_ June 28, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/)    # 󠀁[Miscellaneous developer focused changes in WordPress 5.8](https://make.wordpress.org/core/2021/06/28/miscellaneous-developer-focused-changes-in-wordpress-5-8/)󠁿 --- _**Update on July 1, 2021:** Added new filterFilter Filters are one of the two types of Hooks [https://codex.wordpress.org/Plugin\_API/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 RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. section. – [@milana\_cap](https://profiles.wordpress.org/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](https://make.wordpress.org/core/2021/04/22/ie-11-support-phase-out-plan/) will take place. When considering three different data points, IE11 usage has fallen below a 1% average. After [a discussion and debate](https://make.wordpress.org/core/2021/03/04/discussion-dropping-support-for-ie11/), 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 CoreCore 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 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/](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-rect` * `wp-polyfill-element-closest` * `wp-polyfill-fetch` * `wp-polyfill-formdata` * `wp-polyfill-node-contains` * `wp-polyfill-object-fit` * `wp-polyfill-url` For more information, see [#52941](https://core.trac.wordpress.org/ticket/52941), [#53077](https://core.trac.wordpress.org/ticket/53077), and [#53078](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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::ID` * `WP_Post::post_parent` * `WP_Post::menu_order` * `WP_Term::term_id` * `WP_Term::term_taxonomy_id` * `WP_Term::parent` * `WP_Term::count` * `WP_Term::term_group` * `WP_User::ID` * `$bookmark::link_id` * `$bookmark::link_rating` As WordPress moves towards strict type comparisons (see [#52627](https://core.trac.wordpress.org/ticket/52627) or [#52482](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/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](https://core.trac.wordpress.org/ticket/51469). ## **Users: Pass `$userdata` to the actions and filters in `wp_insert_user()`** There are several action and filter hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. 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-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/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/). This command is a wrapper for `wp_insert_user()` but it’s not possible to provide custom 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. 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](https://core.trac.wordpress.org/ticket/53110). ## **Media: Introduce `image_editor_output_format` filter** As [detailed in a previously published dev note](https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/), WordPress 5.8 now supports the WebP image format. > [WebP](https://developers.google.com/speed/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](https://caniuse.com/webp). > [WordPress 5.8 adds WebP support](https://make.wordpress.org/core/2021/06/07/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: ```notranslate