Title: 2021 – Page 28 – Make WordPress Core --- # Yearly Archives: 2021 [ ](https://profiles.wordpress.org/ellatrix/) [Ella Van Durpe](https://profiles.wordpress.org/ellatrix/) 5:35 pm _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/), [gutenberg ( 546 )](https://make.wordpress.org/core/tag/gutenberg/) # 󠀁[Blocks in an iframed (template) editor](https://make.wordpress.org/core/2021/06/29/blocks-in-an-iframed-template-editor/)󠁿 The new template editor is loaded in an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. to isolate it from the rest of the adminadmin (and super admin) screen. This has the following benefits: * Admin styles no longer affect the editor content, so there’s no need to reset any of these rules. * Content styles no longer affect the admin screen, so 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. and theme CSSCSS Cascading Style Sheets. rules no longer need to be prefixed. * Viewport relative CSS units will work correctly. The dimensions of the editor content is usually not the same as the dimensions of the admin page, so without an iframe units like `vw` will be relative to the admin page. * Media queries will also work natively, without needing to fake them, as we did before, which is fragile. * In general, it makes the lives of block and theme authors easier because styles from the front-end can be dropped in with very little, if nothing, to adjust. This also applies to lighter blocks, where the editor DOM structure matches the front-end, which we highly recommend when possible. * With a separate window for the editor content, it’s possible for the selection in the editor to remain visible while also having a (collapsed) selection in the editor UIUI User interface, for example an input field for a URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org. We currently only iframe _new_ editors. While the new template editor has been iframed, the post editor remains unchanged. We do this to gradually test how existing blocks from plugins work within an iframed editor, since there are cases where a block could look broken or (less likely) error. We hereby urge 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. authors to test their blocks with the new template editor and contact us if they need help to adjust blocks to work in the iframe. ## Document and window The iframe will have a different `document` and `window` than the admin page, which is now the parent window. Editor scripts are loaded in the admin page, so accessing the `document` or `window` to do something with the content will no longer work. Most blocks written in ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. [https://reactjs.org](https://reactjs.org/) should continue to work properly, except if you rely on `document` or `window`. To fix, you need to create ref to access the relative document (`[ownerDocument](https://developer.mozilla.org/en-US/docs/Web/API/Node/ownerDocument)`) or window (`[defaultView](https://developer.mozilla.org/en-US/docs/Web/API/Document/defaultView)`). Regardless of the iframe, it is good practice to do this and avoid the use of globals. ```notranslate const ref = useRef(); useEffect( () => { const { ownerDocument } = ref.current; const { defaultView } = ownerDocument; // Set ownerDocument.title for example. }, [] ); const props = useBlockProps( { ref } ); ``` If you attach event handlers, remember that the `useEffect` callback will not be called if the ref changes, so it is good practice to use the new `useRefEffect` 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., which _will_ call the given callback if the ref change in addition to any dependencies passed. ```notranslate const ref = useRefEffect( ( element ) => { const { ownerDocument } = element; const { defaultView } = ownerDocument; defaultView.addEventListener( ... ); return () => { defaultView.removeEventListener( ... ); }; }, [] ); const props = useBlockProps( { ref } ); ``` ## Other frameworks and libraries For the editor, scripts such as jQuery are loaded in the parent window (admin page), which is fine. When using these to interact with a block in the iframe, you should pass the element reference. ```notranslate const ref = useRefEffect( ( element ) => { jQuery( element ).masonry( … ); return () => { defaultView.jQuery( element ).masonry( 'destroy' ); } }, [] ); const props = useBlockProps( { ref } ) ``` ### But what if the library is using the global window or document and it’s out of your control? Submit an issue or PR for the library to use `ownerDocument` and `defaultView` instead of the globals. Ideally, any library should allow initialisation with an element in an iframe as the target. It’s never impossible. Feel free to contact us to mention the issue. In the meantime, you can use the script that is loaded inside the iframe. We’ve loaded all front-end scripts in the iframe to fix these cases, but note that ideally you shouldn’t use scripts loaded in the iframe at all. You can use `defaultView` to access the script. ```notranslate const ref = useRefEffect( ( element ) => { const { ownerDocument } = element; const { defaultView } = ownerDocument; // Use the script loaded in the iframe. // Script are loaded asynchronously, so check is the script is loaded. // After the dependencies have loaded, the block will re-render. if ( ! defaultView.jQuery ) { return; } defaultView.jQuery( element ).masonry( … ); return () => { defaultView.jQuery( element ).masonry( 'destroy' ); } } ); const props = useBlockProps( { ref } ); ``` --- And that’s it! In summary, any problem that a block might have in the iframe is caused by using the `document` or `window` global at the root of it, either in the block’s code or a third party library. Ideally, all code uses the `ownerDocument` and `defaultView` relative properties. [#5-8](https://make.wordpress.org/core/tag/5-8/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#gutenberg](https://make.wordpress.org/core/tag/gutenberg/) [ ](https://profiles.wordpress.org/youknowriad/) [Riad Benguella](https://profiles.wordpress.org/youknowriad/) 5:29 pm _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/), [gutenberg ( 546 )](https://make.wordpress.org/core/tag/gutenberg/) # 󠀁[On layout and content width in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/on-layout-and-content-width-in-wordpress-5-8/)󠁿 WordPress 5.8 introduces Global Settings and Global Styles. They allow theme authors to control and style the available features in the editor and the different blocks using a **theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.**. By using [a theme.json file](https://make.wordpress.org/core/2021/06/25/introducing-theme-json-in-wordpress-5-8/), in addition to the Global styles and settings capabilitiescapability A **capability** is permission to perform one or more types of task. Checking if a user has a capability is performed by the `current_user_can` function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)., theme authors opt-in into the **layout** feature for 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. containers. ## Layout config Historically, themes had the responsibility to provide CSSCSS Cascading Style Sheets. styles in order to support aligning content (left, right). With the introduction of the block editor in WordPress 5.0, new alignments has been added to the mix ( wide, full). In addition to that, the block editor allowed users to use container blocks (group, columns blocks) which potentially can change how their inner blocks are positioned and aligned. Taking all these variations into consideration has become a very difficult task for theme authors. To address these issues, WordPress 5.8 introduces the layout feature and config. ## How do I migrate my theme Themes that have a centered content area, need to define a layout setting in their` theme.json` file: ```wp-block-code { "settings": { "layout": { "contentSize": "800px", "wideSize": "1000px" } } } ``` The block-editor will automatically read this config and provide the corresponding styles in the editor. It will allow all alignments to work properly without requiring the `add_theme_support( ‘align-wide’ )` call. Themes are still required to provide the corresponding styles in the frontend of their sites, something like: ```notranslate .entry-content > * { max-width: 800px; margin-left: auto !important; margin-right: auto !important; } .entry-content > .alignwide { max-width: 1000px; } .entry-content > .alignfull { max-width: none; } .entry-content > .alignleft { float: left; margin-right: 2em; } .entry-content > .alignright { float: right; margin-right: 2em; } ``` **Note**: It’s not possible for WordPress to generate these styles automatically for all themes because the **entry-content** className in the example above is not mandatory and may not exist. In the future, with the introduction of the upcoming block themes, these styles won’t be needed anymore. ## Nested Blocks For themes with the layout config enabled, container blocks (like group blocks) do not automatically inherit the layout config. Meaning the blocks added inside the containers will by default take all the available space and not have any wide/ full alignments options unless the user defines the wide and content sizes for that particular container block or “inherits” the config from the default layout. [[ This also means that themers can drop any alignment specific CSS that was added specifically to support nested blocks. [#5-8](https://make.wordpress.org/core/tag/5-8/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#gutenberg](https://make.wordpress.org/core/tag/gutenberg/) [ ](https://profiles.wordpress.org/jeffpaul/) [Jeffrey Paul](https://profiles.wordpress.org/jeffpaul/) 4:54 pm _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [agenda ( 1,141 )](https://make.wordpress.org/core/tag/agenda/), [dev chat ( 920 )](https://make.wordpress.org/core/tag/dev-chat/) # 󠀁[Dev Chat Agenda for June 30, 2021](https://make.wordpress.org/core/2021/06/29/dev-chat-agenda-for-june-30-2021/)󠁿 Here is the agenda for this week’s developer meetings to occur at the following times: [June 30, 2021 at 5:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210630T0500) and [June 30, 2021 at 20:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210630T2000). ## Blogblog (versus network, site) Post Highlights * [WordPress 5.8 Beta 4](https://wordpress.org/news/2021/06/wordpress-5-8-beta-4/) * 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.: [Introducing theme.json in WordPress 5.8](https://make.wordpress.org/core/2021/06/25/introducing-theme-json-in-wordpress-5-8/), [Block supports API updates for WordPress 5.8](https://make.wordpress.org/core/2021/06/25/block-supports-api-updates-for-wordpress-5-8/), [Miscellaneous developer focused changes in WordPress 5.8](https://make.wordpress.org/core/2021/06/28/miscellaneous-developer-focused-changes-in-wordpress-5-8/), [Block-based Widgets Editor in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/block-based-widgets-editor-in-wordpress-5-8/), [REST API Changes in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/rest-api-changes-in-wordpress-5-8/), [Various Block Editor API removals in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/block-editor-api-removals-58/), [Introducing “Update URI” plugin header in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/introducing-update-uri-plugin-header-in-wordpress-5-8/) * [What’s new in Gutenberg 10.9? (23 June)](https://make.wordpress.org/core/2021/06/24/whats-new-in-gutenberg-10-9-23-june/) * [A Week in Core – June 28, 2021](https://make.wordpress.org/core/2021/06/29/a-week-in-core-june-28-2021/) * [Editor](https://make.wordpress.org/core/2021/06/24/editor-chat-summary-23rd-june-2021/), [CSS](https://make.wordpress.org/core/2021/06/28/css-chat-summary-24-june-2021/) chat summaries * [Help produce social media materials for 5.8 release](https://make.wordpress.org/marketing/2021/06/30/help-produce-social-media-materials-for-5-8-release/) * [FSE Program Testing Call #8: Thrive with Theme.json](https://make.wordpress.org/test/2021/06/24/call-for-testing-thrive-with-theme-json/) * [Call for Testing: WordPress for iOS 17.7](https://make.wordpress.org/mobile/2021/06/29/call-for-testing-wordpress-for-ios-17-7/) * [Call for Testing: WordPress for Android 17.7](https://make.wordpress.org/mobile/2021/06/30/call-for-testing-wordpress-for-android-17-7/) ## 󠀁[5.8 Schedule Review](https://make.wordpress.org/core/5-8/)󠁿 * **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. 4 released last week and RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see [alpha (beta)](https://make.wordpress.org/core/2021/page/28/?output_format=md#alpha-beta). 1 yesterday and now under [hard string freeze](https://make.wordpress.org/polyglots/handbook/glossary/#hard-freeze)** * **Focus now shifts fully to RC phase with RC 2 release in 6 days on Tuesday, July 6th** * _Also working to publish Dev Notes, Field GuideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the [WordPress release cycle](https://make.wordpress.org/core/handbook/about/release-cycle/). The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. and email 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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party./theme authors_ * Next [RC Scrub](https://make.wordpress.org/core/2021/05/05/bug-scrub-schedule-for-5-8/) before RC 2 is [Monday, July 5th 20:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210705T2000)_( this needs a scrub host/coordinator)_ * RC 2 in 6 days on Tuesday, July 6th * RC 3 in 13 days on Tuesday, July 13th * 5.8 release in 20 days on Tuesday, July 20th ## Components check-in and status updates * 5.8 plans and help needed * Check-in with each component for status updates. * Poll for components that need assistance. ## Open Floor Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items above? Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you accordingly. This meeting happens in the [#core](https://wordpress.slack.com/messages/C02RQBWTW) channel. To join the meeting, you’ll need an account on the [Making WordPress Slack](https://make.wordpress.org/chat/). [#5-8](https://make.wordpress.org/core/tag/5-8/), [#agenda](https://make.wordpress.org/core/tag/agenda/), [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/) [ ](https://profiles.wordpress.org/audrasjb/) [Jb Audras](https://profiles.wordpress.org/audrasjb/) 4:34 pm _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/)    # 󠀁[Introducing “Update URI” plugin header in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/introducing-update-uri-plugin-header-in-wordpress-5-8/)󠁿 WordPress 5.8 introduces a new 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. available 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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. authors. This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from 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/](https://wordpress.org/) Plugin Directory. Previously, any custom plugin which used the same slug than a plugin hosted on WordPress. org was taking a significant risk of being overwritten by an update of the latter. WordPress 5.8 introduces a new `Update URI` [plugin header field](https://developer.wordpress.org/plugins/plugin-basics/header-requirements/). If the value of this new field matches any URI other than `https://wordpress.org/ plugins/{$slug}/` or `w.org/plugin/{$slug}`, WordPress will not attempt to update it. If set, the `Update URI` header field should be a valid URI and have a unique hostname. **Please note that authors of plugins hosted by WordPress.org don’t need to use this new header.** Some examples include: * `Update URI: https://wordpress.org/plugins/example-plugin/` * `Update URI: https://example.com/my-plugin/` * `Update URI: my-custom-plugin-name` `Update URI: false` also works, and unless there is some code handling the `false` hostname (see the hook introduced below), the plugin will not be updated. If the header is used on a w.org hosted plugin, the WordPress.org APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. will only return updates for the plugin if it matches the following format: * `https://wordpress.org/plugins/{$slug}/` * `w.org/plugin/{$slug}` If the header has any other value, the API will not return any result. It will ignore the plugin for update purposes. Additionally, WordPress 5.8 introduce the `update_plugins_{$hostname}` 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., which third-party plugins can use to offer updates for a given hostname. This new hook filters the update response for a given plugin hostname. The dynamic portion of the hook name, `$hostname`, refers to the hostname of the URI specified in the `Update URI` header field. The hook has four arguments: * `$update`: The plugin update data with the latest details. Default `false`. * `$plugin_data`: The list of headers provided by the plugin. * `$plugin_file`: The plugin filename. * `$locales`: Installed locales to look translations for. They can be used to filter the update response in multiple use cases. For reference, see tickets [#32101](https://core.trac.wordpress.org/ticket/32101), [#23318](https://core.trac.wordpress.org/ticket/23318), and changelog [[50921]](https://core.trac.wordpress.org/changeset/50921). _Thanks [@milana\_cap](https://profiles.wordpress.org/milana_cap/) for proofreading._ [#5-8](https://make.wordpress.org/core/tag/5-8/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/) [ ](https://profiles.wordpress.org/paaljoachim/) [Paal Joachim Romdahl](https://profiles.wordpress.org/paaljoachim/) 1:52 pm _on_ June 29, 2021 Tags: [agenda ( 1,141 )](https://make.wordpress.org/core/tag/agenda/), [core-editor ( 756 )](https://make.wordpress.org/core/tag/core-editor/), [core-editor-agenda ( 189 )](https://make.wordpress.org/core/tag/core-editor-agenda/), [meetings ( 14 )](https://make.wordpress.org/core/tag/meetings/)    # 󠀁[Editor Chat Agenda: 30 June 2021](https://make.wordpress.org/core/2021/06/29/editor-chat-agenda-30-june-2021/)󠁿 Facilitator and notetaker: [@itsjusteileen](https://profiles.wordpress.org/itsjusteileen/) This is the agenda for the weekly _editor chat_ scheduled for [Wednesday, June 30, 2021, 04:00 PM GMT+1](https://www.timeanddate.com/worldclock/fixedtime.html?msg=Core+Editor+Meeting&iso=20210630T16&p1=187&ah=1). _This meeting is held in the [#core-editor](https://wordpress.slack.com/messages/C02QB2JS7) channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/). The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/)._ * [Gutenberg 10.9.](https://github.com/WordPress/gutenberg/releases/tag/v10.9.0-rc.1) * [WordPress 5.8](https://github.com/WordPress/gutenberg/projects/55) (Project board) * [Monthly Plan for June 2021](https://make.wordpress.org/core/2021/06/04/whats-next-in-gutenberg-june-2021/) and key project updates: - Global Styles. * - 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. based WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Editor. - Navigation Block & Navigation Editor. - Full Site Editing. - Mobile Team. * Task Coordination. * Open Floor. If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion: * If you have anything to share for the Task Coordination section, please leave it as a comment on this post. * If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below. [#agenda](https://make.wordpress.org/core/tag/agenda/), [#core-editor](https://make.wordpress.org/core/tag/core-editor/), [#core-editor-agenda](https://make.wordpress.org/core/tag/core-editor-agenda/), [#meetings](https://make.wordpress.org/core/tag/meetings/) [ ](https://profiles.wordpress.org/youknowriad/) [Riad Benguella](https://profiles.wordpress.org/youknowriad/) 8:28 am _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [block-editor ( 139 )](https://make.wordpress.org/core/tag/block-editor/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/) # 󠀁[Various Block Editor API removals in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/block-editor-api-removals-58/)󠁿 ## Removed APIs Keeping deprecated 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](https://www.javascript.com/) APIs around has a cost on performance and bundle size. This means at some point we need to consider removing some of the very old deprecated APIs, especially the ones with very low usage. WordPress 5.8 does remove two APIs that were deprecated on WordPress 5.2. * `EditorGlobalKeyboardShortcuts` component, this was a component used to define some keyboard shortcuts of the 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. editor, it was not really meant to be used by third-party developers. We verified that it’s not used by 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. in the repository but if you rely on this component, it should be safe to just replace with `VisualEditorGlobalKeyboardShortcuts`. * The `hasUploadPermissions` selector from the `core` store. We contacted all the three plugins in the repository that were still using this 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.. If you’re still relying on this selector on a private site/plugin, it can be safely replaced with `select( 'core' ).canUser( 'create', 'media' )` ## Removed blocks Before WordPress 5.0 and in the very early days of the 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/](https://wordpress.org/gutenberg/) plugin, we used to have a block called Subheading, this block has never been included in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. as stable, it was hidden and deprecated very early. We expect its usage to be very small. WordPress 5.8 removes the code of this block meaning that if you open content relying on that block in the editor, it will ask you to fallback to the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. block instead. We don’t expect this to have a noticeable impact on the frontend of your site. [#5-8](https://make.wordpress.org/core/tag/5-8/), [#block-editor](https://make.wordpress.org/core/tag/block-editor/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/) [ ](https://profiles.wordpress.org/timothyblynjacobs/) [Timothy Jacobs](https://profiles.wordpress.org/timothyblynjacobs/) 4:59 am _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/), [rest-api ( 111 )](https://make.wordpress.org/core/tag/rest-api/) # 󠀁[REST API Changes in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/rest-api-changes-in-wordpress-5-8/)󠁿 The following is a snapshot of some of the changes 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/](https://developer.wordpress.org/rest-api/) in WordPress 5.8. For more details, see the full list of [closed tickets](https://core.trac.wordpress.org/query?component=REST+API&milestone=5.8&or&focuses=~rest-api&milestone=5.8&or&component=Application+Passwords&milestone=5.8&col=id&col=summary&col=owner&col=type&col=status&col=priority&col=version&order=priority). ## Widgets WordPress 5.8 sees the introduction of 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.-based widgets editor and with it the creation of several REST API endpoints dedicated to widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. management. Before diving in to how the new endpoints operate, I’d like to provide some background about how widgets work that should make the following sections more clear. #### Instance Widgets The predominant way to create widgets is to subclass the `WP_Widget` base class and register the widget with `register_widget`. These are referred to as “multi” widgets. These widgets have multiple instances that are identified by their `number`, an incrementing integer for each widget type. Each instance has its own setting values. These are stored and fetched by `WP_Widget` which allows for the REST API to include these values. However, since a widget’s instance can contain arbitrary data, for example a `DateTime` object, the REST API cannot always serialize a widget to 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.. As such, a widget’s data is always serialized using the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher ` serialize` function and then base64 encoded. This data is also exposed with a `hash` value which is a `wp_hash` signature of this value to prevent clients from sending arbitrary data to be deserialized with `unserialize`. For widgets that can be safely accept and expose their instance data as JSON, pass the `show_instance_in_rest` flag in the `$widget_options` parameter. ```notranslate class ExampleWidget extends WP_Widget { ... /** * Sets up the widget */ public function __construct() { $widget_ops = array( // ...other options here 'show_instance_in_rest' => true, // ...other options here ); parent::__construct( 'example_widget', 'ExampleWidget', $widget_ops ); } ... } ``` #### Reference Widgets Far less common, but still supported, are widgets that are registered using `wp_register_sidebar_widget` and `wp_register_widget_control` directly. These are referred to as “reference”,“ function-based”, or “non-multi” widgets. These widgets can store their data in an arbitrary location. As such, their instance values are never included in the REST API. ### Widget Types Accessible via `/wp/v2/widget-types`, the widget types endpoint describes the different widget types that are registered on the server. The endpoint is accessible to users who have permission to `edit_theme_options`. By default, this is limited to Administrator users. #### Response Format ```notranslate { "id": "pages", "name": "Pages", "description": "A list of your site’s Pages.", "is_multi": true, "classname": "widget_pages", "_links": { "collection": [ { "href": "https://trunk.test/wp-json/wp/v2/widget-types" } ], "self": [ { "href": "https://trunk.test/wp-json/wp/v2/widget-types/pages" } ] } } ``` ### Encode Endpoint Multi widgets have access to the `/wp/v2/widget-types//encode` endpoint. This endpoint is used to convert htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. form data for the widget to the next `instance` for the widget, render the widget form, and render the widget preview. For example, let’s say we want to interact with 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. widget. First, we’ll want to request the widget form from the server. ```wp-block-code POST /wp/v2/widget-types/meta/encode ``` ```notranslate { "instance": {}, "number": 1 } ``` For now, let’s assume we’re working with a new widget. The `instance` is empty because this is a new widget, so we’ll be rendering an empty form. The `number` argument can be omitted, but including one is recommended to provide stable input ids. You’ll receive a response similar to this. _The widget preview has been snipped for brevity._ ```notranslate { "form": "

", "preview": "
...
", "instance": { "encoded": "YToxOntzOjU6InRpdGxlIjtzOjA6IiI7fQ==", "hash": "77e9f20acb54fa4f77de5a865333c0e6", "raw": { "title": "" } } } ``` The provided form can then be rendered and edited by the user. When you want to render a new preview or are ready to begin saving, call the `encode` endpoint again with the url encoded form data and the `instance` value returned from the first response. ```wp-block-code POST /wp/v2/widget-types/meta/encode ``` ```notranslate { "instance": { "encoded": "YToxOntzOjU6InRpdGxlIjtzOjA6IiI7fQ==", "hash": "77e9f20acb54fa4f77de5a865333c0e6", "raw": { "title": "" } }, "number": 1, "form_data": "widget-meta%5B1%5D%5Btitle%5D=Site+Info" } ``` The REST API will call the widget’s update function to calculate the new instance based on the provided form data. The `instance` object can then be used to save a widget via the widgets endpoint. ```notranslate { "form": "

", "preview": "
...
", "instance": { "encoded": "YToxOntzOjU6InRpdGxlIjtzOjk6IlNpdGUgSW5mbyI7fQ==", "hash": "0e9a5bff2d28cba322c8cd27cd4e77af", "raw": { "title": "Site Info" } } } ``` ### Widgets Endpoint The widgets endpoint is used for performing CRUDCRUD Create, read, update and delete, the four basic functions of storing data. (More on [Wikipedia](http://en.wikipedia.org/wiki/Create,_read,_update_and_delete).) operations on the saved widgets. Like the widget types endpoint, the widgets endpoints required the `edit_theme_options` capabilitycapability A **capability** is permission to perform one or more types of task. Checking if a user has a capability is performed by the `current_user_can` function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). to access. To retrieve widgets, make a `GET` request to the `/wp/v2/widgets` endpoint. The` sidebar` parameter can be used to limit the response to widgets belonging to the requested sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. To create a widget, for instance the widget from our previous example, make a `POST` request to the `/wp/v2/widgets` endpoint. The `instance` is the same value returned from the `encode` endpoint. The `id_base` is the unique identifier for the widget type and `sidebar` is the id of the sidebar to assign the widget to. Both are required. ```wp-block-code POST /wp/v2/widgets ``` ```notranslate { "instance": { "encoded": "YToxOntzOjU6InRpdGxlIjtzOjk6IlNpdGUgSW5mbyI7fQ==", "hash": "0e9a5bff2d28cba322c8cd27cd4e77af", "raw": { "title": "Site Info" } }, "sidebar": "sidebar-1", "id_base": "meta" } ``` The endpoint will return information about the newly created widget. ```notranslate { "id": "meta-1", "id_base": "meta", "sidebar": "sidebar-1", "rendered": "
...
", "rendered_form": "

", "instance": { "encoded": "YToxOntzOjU6InRpdGxlIjtzOjk6IlNpdGUgTWV0YSI7fQ==", "hash": "dac44c3ebfa0428fed61829fa151e4e8", "raw": { "title": "Site Info" } }, "_links": { "self": [ { "href": "https://trunk.test/wp-json/wp/v2/widgets/meta-1" } ], "collection": [ { "href": "https://trunk.test/wp-json/wp/v2/widgets" } ], "about": [ { "embeddable": true, "href": "https://trunk.test/wp-json/wp/v2/widget-types/meta" } ], "wp:sidebar": [ { "href": "https://trunk.test/wp-json/wp/v2/sidebars/sidebar-1/" } ], "curies": [ { "name": "wp", "href": "https://api.w.org/{rel}", "templated": true } ] } } ``` Since the meta widget (and all other built-in widgets) is registered with `show_instance_in_rest` enabled you could bypass the `encode` endpoint and use `instance.raw` instead. For example, if we wanted to update the widget to have a new title, we could make the following `PUT` request to `/wp/v2/widgets/meta-1`. ```wp-block-code PUT /wp/v2/widgets/meta-1 ``` ```notranslate { "instance": { "raw": { "title": "Site Meta" } } } ``` A `PUT` request can also be made to update the sidebar assigned to a widget by passing a new `sidebar` id in the request. To delete a widget, send a `DELETE` request to the individual widget route. By default, deleting a widget will move a widget to the Inactive Widgets area. To permanently delete a widget, use the `force` parameter. For example: `DELETE /wp/v2/widgets/ meta-1?force=true`. ### Sidebars Endpoints Found under `/wp/v2/sidebars`, the sidebars endpoint is used to manage a site’s registered sidebars (widget areas) and their assigned widgets. For example, the following is the response for the first footer area in the Twenty Twenty theme. ```notranslate { "id": "sidebar-1", "name": "Footer #1", "description": "Widgets in this area will be displayed in the first column in the footer.", "class": "", "before_widget": "
", "after_widget": "
", "before_title": "

", "after_title": "

", "status": "active", "widgets": [ "recent-posts-2", "recent-comments-2", "meta-1" ], "_links": { "collection": [ { "href": "https://trunk.test/wp-json/wp/v2/sidebars" } ], "self": [ { "href": "https://trunk.test/wp-json/wp/v2/sidebars/sidebar-1" } ], "wp:widget": [ { "embeddable": true, "href": "https://trunk.test/wp-json/wp/v2/widgets?sidebar=sidebar-1" } ], "curies": [ { "name": "wp", "href": "https://api.w.org/{rel}", "templated": true } ] } } ``` The `widgets` property contains an ordered list of widget ids. While all other properties are readonly, the `widgets` property can be used to reorder a sidebar’s assigned widgets. Any widget ids omitted when updating the sidebar will be assigned to the Inactive Widgets sidebar area. For example, making a `PUT` request to `/wp/v2/sidebars/sidebar-1` with the following body will remove the Recent Comments widget, and move the Meta widget to the top of the sidebar. ```wp-block-code PUT /wp/v2/sidebars/sidebar-1 ``` ```notranslate { "widgets": [ "meta-1", "recent-posts-2" ] } ``` For more information about the changes to widgets in 5.8, check out the Block-based Widgets Editor 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.. > [Block-based Widgets Editor in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/block-based-widgets-editor-in-wordpress-5-8/) ## Additional Changes ### Posts Collection Tax Query Accepts `operator` By default, a post must contain at least one of the requested terms to be included in the response. As of [[51026]](https://core.trac.wordpress.org/changeset/51026), the REST API accepts a new `operator` property that can be set to `AND` to require a post to contain all of the requested terms. For example, `/wp/v2/posts?tags[terms]=1,2,3&tags[operator]=AND` will return posts that have tags with the ids of 1, 2, and 3. See [#41287](https://core.trac.wordpress.org/ticket/41287) for more details. _Props to [@noisysocks](https://profiles.wordpress.org/noisysocks/) for reviewing._ [#5-8](https://make.wordpress.org/core/tag/5-8/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#rest-api](https://make.wordpress.org/core/tag/rest-api/) [ ](https://profiles.wordpress.org/noisysocks/) [Robert Anderson](https://profiles.wordpress.org/noisysocks/) 3:01 am _on_ June 29, 2021 Tags: [5.8 ( 99 )](https://make.wordpress.org/core/tag/5-8/), [block-editor ( 139 )](https://make.wordpress.org/core/tag/block-editor/), [dev-notes ( 647 )](https://make.wordpress.org/core/tag/dev-notes/), [feature-widgets-block-editor ( 8 )](https://make.wordpress.org/core/tag/feature-widgets-block-editor/), [widgets ( 26 )](https://make.wordpress.org/core/tag/widgets/)    # 󠀁[Block-based Widgets Editor in WordPress 5.8](https://make.wordpress.org/core/2021/06/29/block-based-widgets-editor-in-wordpress-5-8/)󠁿 WordPress 5.8 introduces 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.-based widgets editor to the Widgets screen (Appearance → Widgets) and CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. (Appearance → Customize → Widgets). The new editor allows users to add blocks to their widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas using the familiar block editor interface introduced in WordPress 5.0. This gives users powerful new ways to customise their sites using the rich library of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and third party blocks. Existing widgets and third party widgets will continue to work and can be used alongside blocks. ## Opting out of the block-based widgets editor The block-based widgets editor is enabled in WordPress 5.8 by default. There are several ways to restore the classic editor: * A theme author may include `remove_theme_support( 'widgets-block-editor' )`. [Learn more.](https://developer.wordpress.org/block-editor/how-to-guides/widgets/opting-out/#using-remove_theme_support) * A site administrator may use the new `use_widgets_block_editor` 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.. [Learn more.](https://developer.wordpress.org/block-editor/how-to-guides/widgets/opting-out/#using-a-filter) * A user may install and activate [the Classic Widgets plugin](https://wordpress.org/plugins/classic-widgets/). ## New Widgets screen The `widgets.php` adminadmin (and super admin) screen (Appearance → Widgets) now loads a block-based widgets editor which exists in the [`@wordpress/edit-widgets` package](https://github.com/WordPress/gutenberg/tree/trunk/packages/edit-widgets). The editor is built using ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. [https://reactjs.org](https://reactjs.org/) and is similar to the editor used for posts and pages (`@wordpress/edit-post`) and uses many of the same subsystems: `@ wordpress/interface` and `@wordpress/components` for UIUI User interface, `@wordpress/ block-editor` for block editing, `@wordpress/data` and `@wordpress/core-data` for persisting changes, and so on. A new filterable function, `wp_use_widgets_block_editor()`, is used by `widgets. php` to determine whether to load the new block-based editor or the classic editor. The Widgets screen is extendable via block editor APIs such as `registerPlugin`,` registerBlockType`, `registerBlockVariation`, and so on. The Widgets screen uses new 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/](https://developer.wordpress.org/rest-api/) endpoints [which are detailed in a seperate dev note](https://make.wordpress.org/core/2021/06/29/rest-api-changes-in-wordpress-5-8/). ## New Customizer control The Widgets section in the Customizer (Appearance → Customize → Widgets) now loads a new control (`WP_Sidebar_Block_Editor_Control`) which contains an embedded block- based widgets editor that exists in the [`@wordpress/customize-widgets` package](https://github.com/WordPress/gutenberg/tree/trunk/packages/customize-widgets). The editor is built using React and uses `@wordpress/block-editor` and `@wordpress/ components` to implement its block editing interface. It does not use `@wordpress/ data` or `@wordpress/core-data` to persist changes. Instead, the existing [Customizer JavaScript API](https://developer.wordpress.org/themes/customize-api/the-customizer-javascript-api/) is used. A new filterable function, `wp_use_widgets_block_editor()`, is used by `WP_Customize_Manager` to determine whether or not to log the new block-based editor control or the classic editor control. The block-based widgets editor in the Customizer is extendable via block editor APIs such as `registerBlockType`, `registerBlockVariation`, and so on. ## New block: Legacy Widget Existing widgets and third party widgets can be edited in the block-based widgets editor via the new Legacy Widget block. This block has an identifier of `core/legacy- widget` and exists in the [`@wordpress/widgets` package](https://github.com/WordPress/gutenberg/tree/trunk/packages/widgets/src/blocks/legacy-widget). The Legacy Widget block is compatible with most third party widgets. Broadly speaking, the Legacy Widget block has three states: 1. _Select. _When first inserted, the block displays a list of widgets available to choose from. The list can be customised using the `widget_types_to_hide_from_legacy_widget_block` filter. 2. _Edit._ When selected, the block displays the widget’s control form fields. This is determined by the widget’s `WP_Widget::form()` implementation. 3. _Preview._ When not selected, the block displays a preview of how the widget will look once saved. This is determined by the widget’s `WP_Widget::widget()` implementation. A “No preview available.” message is automatically shown when `widget()` does not output any meaningful HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.. [Learn more.](https://developer.wordpress.org/block-editor/how-to-guides/widgets/legacy-widget-block/#displaying-no-preview-available) The Legacy Widget block is not available in other block editors including the post editor, though [this can be enabled](https://developer.wordpress.org/block-editor/how-to-guides/widgets/legacy-widget-block/#using-the-legacy-widget-block-in-other-block-editors-advanced) for advanced use cases. ## New widget: Block Blocks added to widget areas are persisted using the same widget storage mechanism added in WordPress 2.8. Under the hood, each block is serialised into HTML and stored in a _block widget_. This is represented by a new `WP_Widget_Block` subclass that extends `WP_Widget`. A block widget is a specialised case of the HTML widget and works very similarly. If blocks are added to a widget area, and then the block-based widgets editor is disabled, the blocks will remain visible on the frontend and in the classic widgets screen. ## Tips to prepare for the new block-based widgets editor ### Use the `widget-added` event to bind event handlers The Legacy Widget block will display a widget’s control form in a way that is very similar to the Customizer and is therefore compatible with most third party widgets. Care must be taken, however, to [always initialise event handlers when the `widget-added` jQuery event is triggered on `document`](https://developer.wordpress.org/block-editor/how-to-guides/widgets/legacy-widget-block/#compatibility-with-the-legacy-widget-block). ```notranslate ( function ( $ ) { $( document ).on( 'widget-added', function ( $event, $control ) { $control.find( '.change-password' ).on( 'change', function () { var isChecked = $( this ).prop( 'checked' ); $control.find( '.password' ).toggleClass( 'hidden', ! isChecked ); } ); } ); } )( jQuery ); ``` ### Use `block_categories_all` instead of `block_categories` The `block_categories` filter has been deprecated and will only be called in the post and page block editor. 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. developers that wish to support the widgets block editor should use the new `block_categories_all` filter which is called in all editors. See [#52920](https://core.trac.wordpress.org/ticket/52920) for more details. ### Allow migrating from widgets to blocks Many core and third party widgets have a functionally equivalent block. For example, core’s Recent Posts widget is analogous to core’s Latest Posts block. In order to avoid duplicate functionality, is is recommended that plugin authors provide a way for users to convert their existing widgets to any equivalent block. WordPress 5.8 provides a mechanism for doing this using [block transforms](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-transforms/): 1. Configure your widget to display its instance in the REST API by setting `show_instance_in_rest` to `true` in `$widget_options`. 2. Add a [block transform](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-transforms/) to your block from the `core/legacy-widget` block. 3. Hide your widget from the Legacy Widget block using the `widget_types_to_hide_from_legacy_widget_block` filter. There is a [guide containing more detailed instructions](https://developer.wordpress.org/block-editor/how-to-guides/widgets/legacy-widget-block/#allowing-migration-to-a-block) in the Block Editor Handbook. ### Don’t use `@wordpress/editor` Many legacy widgets call the `wp.editor.initialize()` 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](https://www.javascript.com/) function to instantiate a TinyMCE editor. If a plugin or block uses the `@wordpress/editor` package and enqueues `wp-editor` as a script dependency, this will re-define the` wp.editor` global, often resulting in a `wp.editor.initialize is undefined` error. ### Don’t use functions like `is_admin()` that won’t work in a REST API request Because the Legacy Widget block makes REST API requests in order to render widgets, admin-only functions like `is_admin()` and `is_plugin_available()` are not available. --- _Written by [@andraganescu](https://profiles.wordpress.org/andraganescu/) and [@noisysocks](https://profiles.wordpress.org/noisysocks/)._ _Thanks to [@talldanwp](https://profiles.wordpress.org/talldanwp/), [@isabel\_brison](https://profiles.wordpress.org/isabel_brison/), [@kevin940726](https://profiles.wordpress.org/kevin940726/), and [@get\_dave](https://profiles.wordpress.org/get_dave/) for reviewing._ [#5-8](https://make.wordpress.org/core/tag/5-8/) [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/) [#feature-widgets-block-editor](https://make.wordpress.org/core/tag/feature-widgets-block-editor/) [#widgets](https://make.wordpress.org/core/tag/widgets/) [#block-editor](https://make.wordpress.org/core/tag/block-editor/) [ ](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