Title: dev-notes-6.3 – Make WordPress Core --- # Tag Archives: dev-notes-6.3 [ ](https://profiles.wordpress.org/get_dave/) [David Smith](https://profiles.wordpress.org/get_dave/) 2:21 pm _on_ August 23, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3, [navigation ( 4 )](https://make.wordpress.org/core/tag/navigation/), [navigation-block ( 3 )](https://make.wordpress.org/core/tag/navigation-block/) # 󠀁[What’s new for Navigation in WordPress 6.2 and 6.3](https://make.wordpress.org/core/2023/08/23/whats-new-for-navigation-in-wordpress-6-2-and-6-3/)󠁿 _This post was co-authored by [@scruffian](https://profiles.wordpress.org/scruffian/)._ Since the [last update](https://make.wordpress.org/core/2022/01/07/the-new-navigation-block/), contributors have added many new features to the Navigation 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 _also_ the wider navigation management system within WordPress. These improvements are designed to help users manage their navigation menus and provide a more consistent and reliable experience. Let’s take a look at what’s changed… # Navigation List View One aspect of the navigation block is that parts of it are often hidden – for example submenus aren’t always open. This can make managing the items within a navigation block in the editor canvas challenging.  For this reason, [WordPress 6**.**2** **added an editable “List View” component to the navigation block inspector](https://github.com/WordPress/gutenberg/issues/42257) controls which lays out the navigation structure with every item visible: ![](https://lh4.googleusercontent.com/NiDdfJVXtK1blYln53dVpXHm8BL96rla1GFaJsbM3lM_Ox6RWpC1bvT75p- SDAWlQQmEW7xJRX63_Xt33_FnH21D-wMsIyAhmdQzVvcGRwlRzK-gDdDbFLJhd1SylDmoXcdLnal_kx69L9V- fQxu_xM) In addition to the standard block tools, the list view allows all the usual ways of managing navigation items. You can: * Add and remove navigation items. * Reorder navigation items. * Create new submenus. Adding this feature to the block also prepared the groundwork to allow contributors to unlock several exciting new features in WordPress 6.3. # Navigation in Site View With WordPress 6.3, it is now possible to manage your navigation from _outside_ of the context of a Navigation block and without needing to edit a template.  When in the Site Editor a new “Navigation” section is available within the Site View 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. which [lists all of your navigation menus](https://github.com/WordPress/gutenberg/issues/50578) and [allows you to manage them](https://github.com/WordPress/gutenberg/issues/50579) without having to find the templates (and blocks) they are used within: ![](https://lh3.googleusercontent.com/8Y6rdJ0N2Pm5qJPbOY-uj7QLMyKvr2T9EJzrZ1dSTRJ7vWtrL40Rw1RDOsQV0htBB4U- FnZs5cG52fUKV8zJTV9QjgPTk9IQyghoRvljjGIa6LZZENXKE5HwxkwEMqt4qmcN0GesX796YfhB34r6v0c) ![](https://lh6.googleusercontent.com/iU5BnGVyIrDtJYOZN7HkFICdP0Uzwcr-eiTw90SwhgSwpUxC3mFUc8NfNjUCCIGJRkjV8HDi8fm3r3GIlpum3mptwnnUUphjAnYWxA6u9ILzAxxvVj0k2sS2_adDY6YPHhcuXxl8FvPmq8stOY7Y488) One you click through to a Navigation you can: * Rename, duplicate and delete navigation. * Reorder items within a navigation. **Known limitation**: currently you cannot add new items, but [contributors are considering avenues to enable this for a future release](https://github.com/WordPress/gutenberg/issues/50580). One benefit of this view is that when multiple blocks all share the _same_ navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site., the user now has a single place to manage the menu items. # Focus Mode for Navigation Surfacing navigation as a list within the Site View is excellent for simple use cases, but sometimes it’s useful to see the navigation within the editor canvas to better visualize the changes being made. For this reason WordPress 6.3 sees the addition of [“Focus Mode” for Navigation](https://github.com/WordPress/gutenberg/issues/37950) whereby the navigation menu is displayed within an editor canvas completely isolated from any surrounding site context. You can access this new mode by clicking on the “Edit” button within the Navigation block’s toolbar, or by browsing to an individual navigation from the “Navigation” section of the Site View sidebar. ![](https://lh4.googleusercontent.com/sFjzoSUx8xFzdYSa-SMa77UNdF-BKh-0HsTdBNeeapkcGq6evKQmONmFCtL_Om- hWcQNC1kZJ2F7s3C1a5sXh85MALW7XUFyXKUqDJWsi_PevvX0MQgXlc7oLee8JWWYLkoK8nNpBIFc0uxaZ7jrxrs) Focus mode provides full scope to modify the blocks that are _inside_ the navigation block (the “menu items”), allowing you to add new items and even make use of the editable list view in the block’s  sidebar: ![](https://lh6.googleusercontent.com/hX417TN8JpCvSJWhgMvsKVdvMbF0tOxO8IBCsHkKx1OiI5XvIf4wvLOIcKLzEqcNHxpPHAw1h3leFOMsjVjjKihq- 14DeaL_7kmMwDoEQTcP3e_K8ObbuOXa33aKCvMENR1jvTXzdQ_pJW26nKRPfEM) It is important to note that as a given navigation menu may be used across _multiple_ block’s on a site – each of which will have their own place within the overall design of your site – the ability to change the visual representation of the Navigation block _itself_ has been intentionally disabled.  This allows you to focus soley on the contents of the navigation menu. Another benefit of this feature is that it is now possible to access and edit the inner blocks of a navigation simply by switching the editor to “code view” mode: ![](https://lh3.googleusercontent.com/9Tggdvty9W5mvzTdGDr7j8gtz5uK7NgO_HgIWjahYTAjImmc0owTGoYwlug_lhjdgLm1b4o3_5aINZOYVtDxzzOnG545POvIKPWCiqEaNvufURWMKkOzQWeu3- YB-dUmgZ6QneubMOwZfFHiEdKm-mA) Managing your navigation in isolation can be extremely useful, but sometimes it’s handy to see your navigation menu within the context of which it is being displayed. This is precisely what the next feature seeks to address. # Navigation in Patterns and Template Parts Patterns and Template Parts often contain navigation block’s. The classic example of this is a “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.” template part containing a site logo block and a navigation block. In WordPress 6.3, when editing a template part or a pattern that contains a navigation _block_, you will see any associated [navigation _menu_ displayed in the sidebar in an editable list view](https://github.com/WordPress/gutenberg/issues/50704). ![](https://lh4.googleusercontent.com/rXsI_n2hfVfFkeICeHXNAbbQt8pnMV0tUizAd4a3RMgxiT7_5sIe6Nz1ZWSYa8xOLf210iVvomePmiTVPsC3Tz1- W52E9AIJlbYF8ag_Lzuo1BbFFqsaUjy7Os5Ly_ppKki6jiRpSzGmiktaO536vBU) This gives you quick access to manage the navigation that is used in the canvas without needing to switch to editing the block directly within the canvas itself. Moreover, by displaying the _name_ of the navigation in the sidebar, it is immediately apparent which navigation menu is being used by the block. In the future it may be possible to complement this in a reciprocal way when [viewing a single Navigation Menu by listing the templates where the navigation is used](https://github.com/WordPress/gutenberg/issues/53170). # Automatic creation of Navigation fallbacks Previous versions of WordPress had the concept of a “fallback” Navigation which was utilized in scenarios where a Navigation block has no navigation menu associated with it.  Depending on whether the site had existing Navigation Menus, the mechanism would either fetch an _existing_ navigation or _create a new_ _one_ from scratch. However the implementation provided a suboptimal user experience, with a noticeable loading delay upon block _modification_ caused by fetching/creating the (“fallback”) navigation menu to be associated with the block. With WordPress 6.3 however, this experience has been greatly improved with [each Navigation block now being _automatically_ assigned a navigation menu upon _insertion_](https://github.com/WordPress/gutenberg/pull/48698). This means that once a block is ready, edits will not trigger further “loading” delays as changes are simply synchronized to the navigation menu already associated with the block. ### Technical Implementation This has been achieved by moving the majority of the fallback logic to the WordPress 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/). A new dedicated “Navigation Fallback” endpoint now immediately returns the most “ suitable” fallback navigation menu for your site. What does “suitable” mean? This is much the same as for WordPress 6.2, namely when called the endpoint… * Returns the _most recently created_ existing Navigation Menu. * (if not available then…) Returns a Navigation Menu created from the _most recently created Classic Men_u (note: this is a one time import, and changes to the original Classic Menu are not synced to the block-based Navigation Menu). * (if not available then…) _Creates and returns a new Navigation Menu_, typically comprising a list of the current site’s Pages. This heuristic may evolve in _future_ releases to allow the fallback to be sensitive to the context in which it is being displayed. For now however, the improvement to the block’s user experience and reliability is a welcome improvement over previous versions. ### Opting out of automatic fallback creation If you’d like to opt out of automatic creation of Navigation fallbacks you can use the `wp_navigation_should_create_fallback` hook as follows: ```wp-block-code add_filter( 'wp_navigation_should_create_fallback', '__return_false' ); ``` See the [original PR for full details](https://github.com/WordPress/wordpress-develop/pull/4813). # Other improvements ## Performance On top of the improvements to perceived performance delivered by improving the fallback navigation system, WordPress 6.3 also provides an additional enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. to the performance of the navigation system. In [#48683](https://github.com/WordPress/gutenberg/pull/48683) contributors [added the navigation endpoints to the list of endpoints that are _preloaded_ in the editor](https://github.com/WordPress/gutenberg/pull/48683). This means that when the editor loads the list of navigation menus will _already be available_ to display and use within the block and/or Site View sidebar.  This simple change makes it possible to access and manage your navigation, which is a key facet of most websites and makes for a greatly improved user experience. ## Login/Logout It is common for websites to provide a login and logout link for their users. In [#49160](https://github.com/WordPress/gutenberg/pull/49160)  we added this block to the list of blocks that are allowed within the navigation block so that users can add this functionality to their navigation. # What do you think? This concludes our brief overview of the key changes to the navigation system in WordPress.  As always we are open to your feedback. What do you think? Are these improvements impactful for you? What is missing and what you would like to see? Your thoughts are appreciated in the comments below. **Bugs** – we appreciate it if any bugs are [reported on Github](https://github.com/WordPress/gutenberg/issues/new/choose). ## What’s next? Of course, whilst there has been much progress contributors recognise that there is still _much_ to do. Our focus for future releases will be  [updated on the relevant Tracking Issue](https://github.com/WordPress/gutenberg/issues/38275#issuecomment-1619747714) and we encourage you all to take a look and let us know any feedback you might have on the proposals outlined there. You can also join us on WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds 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/)( sign up required) in the [#feature-website-navigation channel](https://wordpress.slack.com/archives/C01KDAZJMQ9). Props to [@scruffian](https://profiles.wordpress.org/scruffian/) who co-authored this post and to @draganescu and [@annezazu](https://profiles.wordpress.org/annezazu/) for review. [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/), [#navigation](https://make.wordpress.org/core/tag/navigation/), [#navigation-block](https://make.wordpress.org/core/tag/navigation-block/) [ ](https://profiles.wordpress.org/stevenlinx/) [Steven Lin](https://profiles.wordpress.org/stevenlinx/) 1:00 pm _on_ July 18, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Miscellaneous developer changes in WordPress 6.3](https://make.wordpress.org/core/2023/07/18/miscellaneous-developer-changes-in-wordpress-6-3/)󠁿 ## Administration Added the `no-store` and `private` directives to the `Cache-Control` 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. to prevent caching for logged in users. This prevents sensitive data on logged-in users from being cached and available to others, for example, via the browser history after the user logs out. ([#21938](https://core.trac.wordpress.org/ticket/21938)) ## External Libraries jQuery has been updated from v3.6.4 to v3.7.0. ([#58083](https://core.trac.wordpress.org/ticket/58083)) The latest version of jQuery includes 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. fixes, a new method called `.uniqueSort()`, Sizzle selector engine, and a performance improvement for some use cases when using manipulation methods like `.append()`. The `.uniqueSort()` method is used to sort an array or an array-like object of DOM elements and remove any duplicate nodes. [Sizzle](https://github.com/jquery/jquery/commit/6306ca499433c45b58a02f1cf3a76cbafbc4a391), its selector engine, has been included as [inlined code](https://github.com/jquery/jquery/commit/6306ca499433c45b58a02f1cf3a76cbafbc4a391) and removed as a project dependency, along with the removal of some workarounds for legacy browsers in the process. References: * [jQuery 3.7.0 release notes](https://blog.jquery.com/2023/05/11/jquery-3-7-0-released-staying-in-order/) * [Full list of changes in jQuery 3.7.0](https://github.com/jquery/jquery/compare/3.6.4...3.7.0) ## Login and Registration ### Adding `required` attributes to username and password input fields In WordPress 6.3, the WordPress login form includes the `required` attributes for username and password fields, resolving ticketticket Created for both bug reports and feature development on the bug tracker. [#32510](https://core.trac.wordpress.org/ticket/32510). This change, while minor, may have some ramifications 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. developers. The change adds semantic clarity to explicitly mark these fields as required, reinforcing the implied expectation that has always been in place for login fields. #### Impact for Developers Plugins that bypass login fields or login via alternative methods using the login page may need to adapt by removing the input fields or removing the `required` attribute. Props [@joedolson](https://profiles.wordpress.org/joedolson/) for the 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.. ## Media The fallback return value in `get_the_author()` is corrected to return an empty string if called before `$authordata` is set. This fixes PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.1 “null to non-nullable” deprecation notice in `ent2ncr()` function that is hooked via `the_author` 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.. ([#58157](https://core.trac.wordpress.org/ticket/58157)) ## Plugins A new `plugins_list` filter hook is introduced, which can be used to filter the list of plugins (including those that are “must-use / mu”) that are displayed on the WP Adminadmin (and super admin) Plugins screen. ([#57278](https://core.trac.wordpress.org/ticket/57278)) ```wp-block-code function wporg_filter_plugins_list( $plugins ) { unset( $plugins['all']['test-plugin/test.php'] ); return $plugins; } add_filter( 'plugins_list', 'wporg_filter_plugins_list' ); ``` ## Posts, Post Types A new post type label `item_trashed` is introduced, which allows 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 to announce the correct message when an entity is moved to the TrashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days.. ([#51387](https://core.trac.wordpress.org/ticket/51387)) ## Themes Non-block themes without `theme.json` can opt-in to block link color tools and block border tools via `add_theme_support()`. ([#58597](https://core.trac.wordpress.org/ticket/58597) and [#58598](https://core.trac.wordpress.org/ticket/58598)) In the callback function that is hooked to the `after_setup_theme` action in your` functions.php` of your theme, add the following inside the function: opt-in to block link color tools: ```wp-block-code add_theme_support( 'link-color' ); ``` ![](https://core.trac.wordpress.org/raw-attachment/ticket/58597/Capture%20d%E2%80% 99%C3%A9cran%202023-06-22%20%C3%A0%2013.43.34.png) opt-in to block border tools: ```wp-block-code add_theme_support( 'border' ); ``` ![](https://core.trac.wordpress.org/raw-attachment/ticket/58598/Capture%20d%E2%80% 99%C3%A9cran%202023-06-22%20%C3%A0%2013.49.25.png) Props to [@audrasjb](https://profiles.wordpress.org/audrasjb/) for the visual assets. ## Users A new `wp_update_user` action hook is introduced, which fires after the user has been updated and emails have been sent. ([#57843](https://core.trac.wordpress.org/ticket/57843)) ```wp-block-code add_action( 'wp_update_user', function ( $user_id, $userdata, $userdata_raw ) { echo $user_id; print_r( $userdata ); print_r( $userdata_raw ); exit; }, 10, 3 ); ``` Props to [@costdev](https://profiles.wordpress.org/costdev/) and [@mikeschroder](https://profiles.wordpress.org/mikeschroder/) for technical review, to [@milana_cap](https://profiles.wordpress.org/milana_cap/) for review. [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/sabernhardt/) [Stephen Bernhardt](https://profiles.wordpress.org/sabernhardt/) 10:00 am _on_ July 18, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [bundled-theme ( 83 )](https://make.wordpress.org/core/tag/bundled-theme/), [core-themes ( 26 )](https://make.wordpress.org/core/tag/core-themes/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Bundled themes dropping Internet Explorer scripts and styles](https://make.wordpress.org/core/2023/07/18/bundled-themes-dropping-internet-explorer-scripts-and-styles/)󠁿 Due to very low traffic from Internet Explorer users, and because [WordPress no longer supports this obsolete browser](https://make.wordpress.org/core/2021/04/22/ie-11-support-phase-out-plan/), default themes have removed some IE-specific scripts and styles to give everyone else a better experience. Most default themes had a skip-link focus fix script for navigating by keyboard in Internet Explorer and old versions of Chrome. As of WordPress 6.3, Twenty Thirteen and Twenty Fourteen no longer include it in their `functions.js` files, and the six themes from Twenty Fifteen to Twenty Twenty-One do not enqueue or print the script. In addition, special stylesheets and the HTML5 Shiv script are not enqueued or included in the `header.php` template for three themes: * Twenty Thirteen (its conditional code is also removed) * Twenty Fifteen * Twenty Seventeen Future versions of Twenty Eleven, Twenty Twelve, Twenty Fourteen and Twenty Sixteen may remove their special styles and conditional code too. ## What if I want to continue supporting Internet Explorer? ### Restoring the skip-link focus fix Twenty Thirteen users can add a minified version of the script found in later themes: ```notranslate function wpdocs_twentythirteen_add_skip_link_fix_inline() { wp_add_inline_script( 'twentythirteen-script', '/(trident|msie)/i.test(navigator.userAgent)&&document.getElementById&&window.addEventListener&&window.addEventListener("hashchange",function(){var t,e=location.hash.substring(1);/^[A-z0-9_-]+$/.test(e)&&(t=document.getElementById(e))&&(/^(?:a|select|input|button|textarea)$/i.test(t.tagName)||(t.tabIndex=-1),t.focus())},!1);' ); } add_action( 'wp_enqueue_scripts', 'wpdocs_twentythirteen_add_skip_link_fix_inline', 11 ); ``` Twenty Fourteen would need an adjustment for the fixed 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.: ```notranslate function wpdocs_twentyfourteen_add_skip_link_fix_inline() { wp_add_inline_script( 'twentyfourteen-script', '/(trident|msie)/i.test(navigator.userAgent)&&document.getElementById&&window.addEventListener&&window.addEventListener("hashchange",function(){var t,e=location.hash.substring(1);/^[A-z0-9_-]+$/.test(e)&&(t=document.getElementById(e))&&(/^(?:a|select|input|button|textarea)$/i.test(t.tagName)||(t.tabIndex=-1),t.focus(),window.scrollBy(0,-80))},!1);' ); } add_action( 'wp_enqueue_scripts', 'wpdocs_twentyfourteen_add_skip_link_fix_inline', 11 ); ``` Enqueue the theme’s script for Twenty Fifteen, Twenty Sixteen or Twenty Seventeen: ```notranslate function wpdocs_twentyseventeen_add_skip_link_fix() { wp_enqueue_script( 'twentyseventeen-skip-link-focus-fix' ); } add_action( 'wp_enqueue_scripts', 'wpdocs_twentyseventeen_add_skip_link_fix' ); ``` Add the theme’s function to the `wp_print_footer_scripts` action for Twenty Nineteen, Twenty Twenty or Twenty Twenty-One: ```notranslate add_action( 'wp_print_footer_scripts', 'twenty_twenty_one_skip_link_focus_fix' ); ``` ### Restoring conditional code, styles and scripts Sites may have been severely broken when using old versions of Internet Explorer, even with the HTML5 Shiv script and IE-specific styles, but you could add them again. If you have a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. [https://developer.wordpress.org/themes/advanced-topics/child-themes/](https://developer.wordpress.org/themes/advanced-topics/child-themes/) of Twenty Thirteen, you can ensure it has a `header.php` template that includes the [conditional code and HTML5 script](https://themes.trac.wordpress.org/browser/twentythirteen/3.7/header.php?marks=11-31#L11) from previous versions of the theme. Then you could enqueue the styles in the child theme functions (or 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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party.). ```notranslate function wpdocs_twentythirteen_ie_restore() { wp_enqueue_style( 'twentythirteen-ie' ); } add_action( 'wp_enqueue_scripts', 'wpdocs_twentythirteen_ie_restore' ); ``` For Twenty Fifteen, you could enqueue the two IE stylesheets. If a child theme does not already have the HTML5 script in a `header.php` template, the same function could enqueue that too. ```notranslate function wpdocs_twentyfifteen_ie_restore() { // Enqueue stylesheets. wp_enqueue_style( 'twentyfifteen-ie' ); wp_enqueue_style( 'twentyfifteen-ie7' ); // If the header template does not have the HTML5 script already, enqueue it. wp_enqueue_script( 'twentyfifteen-html5', get_template_directory_uri() . '/js/html5.js', array(), '3.7.0', false ); wp_script_add_data( 'twentyfifteen-html5', 'conditional', 'lt IE 9' ); } add_action( 'wp_enqueue_scripts', 'wpdocs_twentyfifteen_ie_restore' ); ``` With Twenty Seventeen, both the style and script can be enqueued. ```notranslate function wpdocs_twentyseventeen_ie_restore() { wp_enqueue_style( 'twentyseventeen-ie8' ); wp_enqueue_script( 'html5' ); } add_action( 'wp_enqueue_scripts', 'wpdocs_twentyseventeen_ie_restore' ); ``` For more details, see TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets [#54421](https://core.trac.wordpress.org/ticket/54421) and [#56699](https://core.trac.wordpress.org/ticket/56699). Props to [@westonruter](https://profiles.wordpress.org/westonruter/) and [@joedolson](https://profiles.wordpress.org/joedolson/) for technical review, to [@stevenlinx](https://profiles.wordpress.org/stevenlinx/) and [@audrasjb](https://profiles.wordpress.org/audrasjb/) for review. [#6-3](https://make.wordpress.org/core/tag/6-3/), [#bundled-theme](https://make.wordpress.org/core/tag/bundled-theme/), [#core-themes](https://make.wordpress.org/core/tag/core-themes/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/leonnugraha/) [Leonardus Nugraha](https://profiles.wordpress.org/leonnugraha/) 10:00 am _on_ July 18, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Miscellaneous Editor changes in WordPress 6.3](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/)󠁿 In this post, you will find 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. for smaller changes to the editor in WordPress 6.3. --- **Table of contents** 1. [Post editor iframed](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#post-editor-iframed) 2. [Publish types for plugins packages enabled](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#publish-types-for-plugins-package) 3. [Allow dragging-and-dropping images from the inserter to image blocks](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#allow-dragging-and-dropping-images-from-the-inserter-to-image-blocks) 4. [New slot in the site editor’s Template sidebar](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#new-slot-in-the-site-editor-s-template-sidebar) 5. [New `ungroup` transforms API](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#new-ungroup-transforms-api) 6. [Block variation transforms in block switcher](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#block-variation-transforms-in-block-switcher) 7. [Prioritizing Blocks in the Inserter](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#prioritizing-blocks-in-the-inserter) 8. [Renaming Reusable Blocks to Patterns](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#renaming-reusable-blocks-to-patterns) 9. [Patterns on the create a new template modal](https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#patterns-on-the-create-a-new-template-modal) --- ## Post editor iframed From WordPress 6.3 on, the post editor will be iframed if all registered blocks have a [Block API version 3 ](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/) or higher. Adding version 3 support means that 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. should work inside 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., though the block may still be rendered outside the iframe if not all blocks support version 3. It is worth noting that the Site Editor and Page Template Editor have always been iframed, alongside block and pattern previews, and will continue to be iframed regardless of the Block APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. version. To make adoption easier, all assets (styles and scripts) added through the `enqueue_block_assets` PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher action will now also be enqueued for the iframe. For more details, see [#48286](https://github.com/WordPress/gutenberg/pull/48286). It’s also worth noting that `enqueue_block_editor_assets` should not be used to add stylesheets for editor _content_. Please use `enqueue_block_assets` instead. If you don’t want styles to load on the front-end, you can use an `is_admin()` condition. For backward compatibility, we will clone stylesheets added via `enqueue_block_editor_assets` if the stylesheet contains a `.editor-styles-wrapper`, `.wp-block`, or `.wp-block-*` selector, but a warning message will be logged. You should use `enqueue_block_assets` instead, or `[block.json](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/)` if you’re adding block styles, `[theme.json](https://developer.wordpress.org/themes/advanced-topics/theme-json/)` for block-based themes, or `[add_editor_style()](https://developer.wordpress.org/reference/functions/add_editor_style/)` for classic themes. 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 are asked to make blocks compatible with the iframed methods and support version 3 and to report any problems with those changes. In a future version of WordPress, the editor content will load within an iframe regardless of the Block API version. For more information about why iframing the editor content is preferred, please revisit the post [Blocks in an iframed (template) editor](https://make.wordpress.org/core/2021/06/29/blocks-in-an-iframed-template-editor/). Edit: there’s a new page in the Block Editor Handbook on [enqueuing assets in the editor](https://developer.wordpress.org/block-editor/how-to-guides/enqueueing-assets-in-the-editor/), provided by [@ndiego](https://profiles.wordpress.org/ndiego/). _Props to_ [@ellatrix](https://profiles.wordpress.org/ellatrix/)_ for the 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._. ## Publish types for plugins packages enabled TypeScript developers appreciate having great in-editor type-hints and compiler warnings. With the changes for WordPress 6.3, contributors reduced the reliance on DefinitelyTyped, and increase code maintainability. Various wordpress packages were published to allow TypeScript to emit types by parsing the JSDoc comments. With some small tweaks to assist its inference 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)., TypeScript can generate extensive type definitions even for store objects without migrating much code to TypeScript. So far, the following packages are using this process now: * Publish rich text build types ([#49651](https://github.com/WordPress/gutenberg/pull/49651)) * Convert wp data controls to typescript ([#49647](https://github.com/WordPress/gutenberg/pull/49647)) * Publish build types for notices ([#49650](https://github.com/WordPress/gutenberg/pull/49650)) * Publish types for plugins package ([#49649](https://github.com/WordPress/gutenberg/pull/49649)) The work for some larger packages is still in progress, such as `blocks`, `editor`, and `block-editor`. See [#49649](https://github.com/WordPress/gutenberg/pull/49649) for more details. _Props to_ [@noahtallen](https://profiles.wordpress.org/noahtallen)_ for the dev note_ ## Allow dragging-and-dropping images from the inserter to image blocks The updates to the `onDragStart` prop of the `` component switched the synchronous callback function from an asynchronous one. Previously, it used to be called asynchronously with a slight delay set by [`setTimeout(onDragStart, 0)`](https://developer.mozilla.org/en-US/docs/Web/API/setTimeout#parameters). The previous behavior posed a limitation as users were unable to add additional data for the drag event due to [security measures implemented by web browsers](https://html.spec.whatwg.org/multipage/dnd.html#drag-data-store-mode). This change should have minimal impact on existing code. However, if it does affect your code, you can maintain the original behavior by wrapping your event callback inside a `setTimeout` function as shown below: ```notranslate -onDragStart={ () => { doSomething(); } } +onDragStart={ () => { setTimeout( doSomething, 0 ); } } ``` See [#49673](https://github.com/WordPress/gutenberg/pull/49673) for more details. _Props to [@kevin940726](https://profiles.wordpress.org/kevin940726/) for the dev note_ ## New slot in the site editor’s Template 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. Extenders can now add additional information in the site editor’s Template sidebar. With the new slot named `PluginTemplateSettingPanel` the information will appear below the main information, similar to below example of the Template Card. (See Code Example) ```notranslate import { MyTemplateSettingTest } from '@wordpress/edit-site'; const MyTemplateSettingTest = () => ( <PluginTemplateSettingPanel> <p>Hello, World!</p> </PluginTemplateSettingPanel> ); ``` For more details, see [#50257](https://github.com/WordPress/gutenberg/pull/50257). [⌊The site editor, showing settings panel with additional slot below the template card.⌉⌊The site editor, showing settings panel with additional slot below the template card.⌉[ _Props to _[@ntsekouras](https://profiles.wordpress.org/ntsekouras/)_ for the dev note_ ## New `ungroup` transforms API [Block Transforms](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-transforms/) is the API that allows a block to be transformed _from_ and _to_ other blocks, as well as _from_ other entities. From now on, via the optional `transforms` key of the block configuration, blocks can use the `ungroup` subkey to define the blocks that will replace the block being processed. These new blocks will usually be a subset of the existing inner blocks, but could also include new blocks. If a block has an `ungroup` transform, it is eligible for ungrouping without the requirement of being the default grouping block. The UIUI User interface used to ungroup a block with this API is the same as the one used for the default grouping block. For the Ungroup button to be displayed, you must have a single grouped block selected, which also contains some inner blocks. **ungroup** is a callback function that receives the attributes and inner blocks of the block being processed. It should return an array of block objects. Example: ```notranslate export const settings = { title: 'My grouping Block Title', description: 'My grouping block description', /* ... */ transforms: { ungroup: ( attributes, innerBlocks ) => innerBlocks.flatMap( ( innerBlock ) => innerBlock.innerBlocks ), }, }; ``` For more details, see [#50385](https://github.com/WordPress/gutenberg/pull/50385). _Props to _[@ntsekouras](https://profiles.wordpress.org/ntsekouras/)_ for the dev note_ ## Block variation transforms in block switcher [Block Variations](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/) is the API that allows a block to have similar versions of it, but all these versions share some common functionality. Each block variation is differentiated from the others by setting some initial attributes or inner blocks. Then, when a block is inserted, these attributes and/or inner blocks are applied. From now on, variations with a scope: `transform` will be prioritized in the block switcher menu so that they are easier surfaced in existing user interface (UI) patterns. Noting that the existing UI in the block’s inspector controls regarding the variation transformations is preserved as is. [[ For more details, see [#50139](https://github.com/WordPress/gutenberg/pull/50139). _Props to _[@ntsekouras](https://profiles.wordpress.org/ntsekouras/)_ for the dev note_ ## Prioritizing Blocks in the Inserter In [this PR](https://github.com/WordPress/gutenberg/pull/50510/files), we added a way to control what blocks are shown in the block inserter for a particular block. This allows a block to suggest particular blocks which are going to be most useful. For example, when inserting a block within the Navigation block, we specify `core/ navigation-link` and `core/navigation-link/page` as these are the most commonly used inner blocks. `prioritizedInserterBlocks` is a property of the `InnerBlocks` component. To use it, pass `prioritizedInserterBlocks` as a property of the options argument passed to `useInnerBlocksProps`. `prioritizedInserterBlocks` takes an array of the form {blockName}/{variationName}, where {variationName} is optional. As a result, the blocks you specify in `prioritizedInserterBlocks` should be the first ones in the block inserter: [[ _Props to_ [@scruffian](https://profiles.wordpress.org/scruffian/)_ for the dev note_ ## Renaming Reusable Blocks to Patterns Reusable blocks have been renamed to Patterns in WordPress 6.3. For backward compatibility, the default behavior of  `core/block` remains exactly the same as with Reusable blocks. The block content is still saved to the `wp_block` CPT and any changes to the block content are reflected across all instances of the block. This default behavior of the Pattern block is referred to in the UI as ‘synced’. The Pattern block also has a second option in 6.3 which is ‘unsynced’. When ‘unsynced’, the block will behave the same as the existing theme and plugin patterns, i.e. the patterns blocks will be inserted as standalone blocks, and any edits affect only that instance. In order to track the synced and unsynced status, a new postmeta field has been registered for the wp_block CPT called wp_pattern_sync_status. If this postmeta field is undefined, the pattern is considered synced, and if the pattern is unsynced, this will be set to unsynced. Because this is a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. field, it is exposed as a top-level field in 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/) instead of a 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. property, so it will appear on the `wp_block` as `entity.wp_sync_status`. Because the synced Patterns do not require the new postmeta field, we don’t anticipate any impact on plugins that may modify the existing reusable block behavior. The only impact we anticipate is on any plugins that manipulate the DOM based on selectors that depend on the text `Reusable block(s)` existing in the UI. These selectors would need to be adjusted to expect the text `Pattern` instead. _Props to_ [@glendaviesnz](https://profiles.wordpress.org/glendaviesnz/) _for the dev note_ ## Patterns on the create a new template modal In WordPress 6.2, we introduced a new modal for creating templates. This modal presents the option to start a new template from a “blank” state or use the current fallback of the template. In WordPress 6.3, we expanded this modal’s functionality to display patterns that are suitable for a given template. For a pattern to appear in the modal, it needs to specify a property called templateTypes, which is an array containing the templates where the patterns can be used as the full content. Here’s an example that demonstrates adding a pattern to the start of a 404 template: ```notranslate register_block_pattern( 'my-patterns/404-template', array( 'title' => __( 'New 404 pattern', 'gutenberg' ), 'templateTypes' => array( '404' ), 'content' => '<!-- wp:paragraph {"align":"center","fontSize":"x-large"} --> <p class="has-text-align-center has-x-large-font-size">404</p> <!-- /wp:paragraph -->', ) ); ``` _Props to_ [@jorgefilipecosta](https://profiles.wordpress.org/jorgefilipecosta/) _for the dev note_ --- _Props to _[@bph](https://profiles.wordpress.org/bph/) _and_ [@annezazu](https://profiles.wordpress.org/annezazu/) _for reviewing the post_ [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/youknowriad/) [Riad Benguella](https://profiles.wordpress.org/youknowriad/) 2:00 pm _on_ July 17, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Introducing the WordPress Command Palette API](https://make.wordpress.org/core/2023/07/17/introducing-the-wordpress-command-palette-api/)󠁿 WordPress 6.3 ships with a new command palette. Initially included in the post and site editors, users can open the command palette using the `ctrl + k` or `command + k` keyboard shortcuts. [⌊An overview on how the command palette appears in the editor. ⌉⌊An overview on how the command palette appears in the editor. ⌉[ ## Registering commands The command palette includes a number of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. commands that you can use by default including things like: * Navigating the site editor. * Creating new posts and pages. * Toggling UIUI User interface elements. * Toggling editor preferences. * and more. It also offers an 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. for third-party developers to register or unregister commands. There are two ways to register commands: static commands and dynamic commands. ### Static commands Static commands can be registered using the `wp.data.dispatch( wp.commands.store). registerCommand` action or using the `wp.commands`.`useCommand` 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/) hook. Both methods receive a command object as an argument, which provides a unique name, a label, an icon, a callback function that is called when the command is selected, and potentially a context. **Example:** ```javascript wp.commands.useCommand( { name: 'myplugin/my-command-name', label: __( 'Add new post' ), icon: plus, callback: ({ close }) => { document.location.href = 'post-new.php'; close(); }, } ); ``` ### Dynamic commands Dynamic commands, on the other hand, are registered using “command loaders.” These are needed when the command list depends on the search term entered by the user in the command palette input or when some commands are only available when some conditions are met. For example, when a user types “contact”, the command palette need to 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. the available pages using that input. ```javascript function usePageSearchCommandLoader( { search } ) { // Retreiving the pages for the "search" term const { records, isLoading } = useSelect( ( select ) => { const { getEntityRecords } = select( coreStore ); const query = { search: !! search ? search : undefined, per_page: 10, orderby: search ? 'relevance' : 'date', }; return { records: getEntityRecords( 'postType', 'page', query ), isLoading: ! select( coreStore ).hasFinishedResolution( 'getEntityRecords', [ 'postType', 'page', query ] ), }; }, [ search ] ); // Creating the commands const commands = useMemo( () => { return ( records ?? [] ).slice( 0, 10 ).map( ( record ) => { return { name: record.title?.rendered + ' ' + record.id, label: record.title?.rendered ? record.title?.rendered : __( '(no title)' ), icon: icons[ postType ], callback: ( { close } ) => { const args = { postType, postId: record.id, ...extraArgs, }; document.location = addQueryArgs( 'site-editor.php', args ); close(); }, }; } ); }, [ records, history ] ); return { commands, isLoading, }; } useCommandLoader( { name: 'myplugin/page-search', hook: usePageSearchCommandLoader, } ); ``` ### Contextual commands Commands can be contextual. This means that in a given context (for example, when navigating the site editor, or when editing a template), some specific commands are given more priority and are visible as soon as you open the command palette. And when typing the command palette, these contextual commands are shown above the rest of the commands. At the moment, two contexts have been implemented: * **site-editor **This is the context that is set when you are navigating in the site editor (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. visible). * **site-editor-edit** This is the context that is set when you are editing a document( template, template part or page) in the site editor. As the usage of the command palette expands, more contexts will be added.  To attach a command or a command loader to a given context, it is as simple as adding the `context` property (with the right context value from the available contexts above) to the `useCommand` or `useCommandLoader` calls. ## WordPress Data API The command palette also offers a number of selectors and actions to manipulate its state which includes: * Retrieving the registered commands and command loaders using the following selectors` getCommands` and `getCommandLoader` * Checking if the command palette is open using the `isOpen` selector. * Programmatically open or close the command palette using the `open` and `close` actions. _Props to _[@bph](https://profiles.wordpress.org/bph/)_, _[@annezazu](https://profiles.wordpress.org/annezazu/),_ and _[@leonnugraha](https://profiles.wordpress.org/leonnugraha/) for reviewing. [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/spacedmonkey/) [Jonny Harris](https://profiles.wordpress.org/spacedmonkey/) 1:00 pm _on_ July 17, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Improvements to the Cache API in WordPress 6.3](https://make.wordpress.org/core/2023/07/17/improvements-to-the-cache-api-in-wordpress-6-3/)󠁿 As part of the release of WordPress 6.3, the new Performance team has been working on several improvements to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. There are a few new additions to the WordPress Cache 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., improved validation, and new actions. ## Change cache groups for all query caches There are a number of places in WordPress where the results of queries are cached, for example, all the major query classes like `WP_Query`, `WP_Comment_Query`, and` WP_Term_Query`. As of WordPress 6.3, the class `WP_User_Query` also caches the result of queries. In previous versions, the query results were stored in the same cache group as the corresponding object. For instance, post query data would be stored in the “posts” group. However, starting from WordPress 6.3, this approach has been modified. The update introduces new cache groups specific to queries, offering developers greater control over the handling of objects within these groups. Core functionality now enables developers to specify the expiration time for a cache group, allowing them to set a duration of, for instance, one day. If desired, developers can also use the `wp_cache_flush_group()` function to clear a specific cache group (if their object cache implementation supports it). Additionally, this change allows developers to designate a cache group as non-persistent, if needed. The following are the newly added cache groups: * post-queries * term-queries * comment-queries * networknetwork (versus site, blog)-queries ( global cache group ) * site-queries  ( global cache group ) * user-queries ( global cache group ) For sites with persistent object caching enabled, ensure that it supports `wp_cache_add_global_groups` function (added in WP 2.6) to add global cache groups . If not, you will have to manually add the three new global cache groups.  See [#57625](https://core.trac.wordpress.org/ticket/57625) and [#40613](https://core.trac.wordpress.org/ticket/40613) for additional context. ## New utility function `wp_cache_set_last_changed()` A new utility function, `wp_cache_set_last_changed()`, has been introduced in WordPress 6.3. This function is utilized to update the last updated value in the cache. It complements the existing `wp_cache_get_last_changed()` function, which was added in WordPress 4.7. In the core codebase, all instances where the last changed value was updated have been replaced with calls to this new function. In addition to the new utility function, a corresponding action called `wp_cache_set_last_changed` has been introduced. This action provides valuable information such as the cache group, the newly updated value, and the old value. Developers can leverage this action to implement custom cache invalidation strategies. When combined with the new cache groups mentioned earlier and the `wp_cache_flush_group()` function, it becomes possible to clear an entire cache group programmatically. Here is some sample code of this action that can be used along with the `wp_cache_flush_group()` function.  ```notranslate function wpdocs_cache_clear_query_groups( $group ){   switch( $group ){      case 'comment':         $cache_group = 'comment-queries';         break;      case 'sites':         $cache_group = 'site-queries';         break;      case 'networks':         $cache_group = 'network-queries';         break;      case 'posts':         $cache_group = 'post-queries';         break;      case 'terms':         $cache_group = 'term-queries';         break;      case 'users':         $cache_group = 'user-queries';         break;      default:         $cache_group = false;   }   if( $cache_group ){      wp_cache_flush_group( $cache_group );   } } add_action( 'wp_cache_set_last_changed', 'wpdocs_cache_clear_query_groups' ); ``` ## Validation added to  `_get_non_cached_ids()` for  invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also _notabug_) that indicates the ticket is not a bug, is a support request, or is generally invalid. IDs The `_get_non_cached_ids()` function has been updated to perform validation, ensuring that only an array of unique integers are passed as input. In the previous version, no validation was conducted on the input, leading to potential validation errors and even PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher fatal errors. This function now only supports passing an array of integers. If incorrect values are passed, a `_doing_in_wrong` message is triggered to inform developers of the error. See [#57593](https://core.trac.wordpress.org/ticket/57593) ## Misc changes  The PHPUnit test suite now calls `wp_cache_flush_runtime()` instead of manually resetting class properties of the object cache. The `wp_cache_flush_runtime()` function was added into core back in WordPress 6.0. If you are running the WordPress core unit tests with an object cache drop-in enabled, please ensure that the `wp_cache_flush_runtime()` function is present. See [#31463](https://core.trac.wordpress.org/ticket/31463) The function `wp_cache_get_multiple` was introduced in WordPress 5.5., and in WordPress 6.3, it is now in a couple of new places. It is now used to prime network options in `wp_load_core_site_options` in a single cache call. The `wp_cache_get_multiple` was also implemented in `fill_descendants` in `WP_Comment_Query`. This method is used to fill in descendant comments. This increases the performance of sites that heavily use nested comments. See [#57803](https://core.trac.wordpress.org/ticket/57803) and [#56913](https://core.trac.wordpress.org/ticket/56913) _Props to _[@flixos90](https://profiles.wordpress.org/flixos90/) and [@joemcgill](https://profiles.wordpress.org/joemcgill/) _for peer review, to _[@stevenlinx](https://profiles.wordpress.org/stevenlinx/), [@leonnugraha](https://profiles.wordpress.org/leonnugraha/) and [@jyolsna](https://profiles.wordpress.org/jyolsna/) _for review._ [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/ndiego/) [Nick Diego](https://profiles.wordpress.org/ndiego/) 11:47 am _on_ July 17, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Social Icons block: Applied colors now dynamically update based on theme.json and Global Styles](https://make.wordpress.org/core/2023/07/17/social-icons-block-applied-colors-now-dynamically-update-based-on-theme-json-and-global-styles/)󠁿 The Social Icons 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. provides options to set both an “Icon color” and an “Icon background color”. In versions prior to WordPress 6.3, the selected colors were hardcoded as hex code values within the block, even if you chose a color from the theme palette defined in 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.. Let’s take the example of the Twenty Twenty-Three theme, where the icon color is set to “Base” and the background color to “Secondary.” The icons’ frontend markup would include inline styles like this: ```line-numbers
  • ... Facebook
    • ``` As you can see, the inline styles reflect the hardcoded hex code values for the ` base` and `secondary` colors defined in Twenty Twenty-Three’s theme.json file, which are `#ffffff` and `#345C00` respectively. This approach caused issues when modifying the color palette in Global Styles, manually changing the theme.json file, or selecting different theme style variations. The icon colors did not update whenever the values for `base` or `secondary` were changed. This problem is clearly demonstrated in the following video. Despite choosing different style variations, which have their own values for `base` or `secondary`, the icon colors remain fixed at `#ffffff` and `#345C00`. To address this, WordPress 6.3 introduces CSSCSS Cascading Style Sheets. classes to the Social Icons block that correspond to the selected color values. These classes are used all over WordPress and are automatically generated based on the color palette set in the theme.json file. They follow the format: * `has-[color_slug]-color` * `has-[color_slug]-background-color` It’s important to note that these classes will not be applied if a user selects a custom color. With the application of these CSS classes, any changes made to the `base` or `secondary` colors in Global Styles or theme.json will be automatically reflected in the Social Icons block. Here’s an updated example of the code (scroll to the right to view the classes): ```language-markup
  • ... Facebook
    • ``` Each CSS class corresponds to a specific color variable: ```language-css .has-base-color { color: var(--wp--preset--color--base) !important; } .has-secondary-background-color { background-color: var(--wp--preset--color--secondary) !important; } ``` While these CSS classes take precedence over the hardcoded hex values, it’s important to mention that the hardcoded values are still retained. This design ensures that if a user switches to a theme that doesn’t support the `base` or `secondary `colors, the icons will still display correctly using the original hardcoded hex values. The following video shows that the Social Icons block now updates as the user changes the theme style variation in Global Styles. Finally, it’s worth noting that this change won’t require any action from theme developers or users unless some custom functionality has been implemented. The rendering of the Social Icons block is handled through PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, meaning that if any updates are made to the color palette defined in theme.json and the icon or background color is set to one of the colors from that palette, the icons will automatically update to reflect the changes. For additional context and to review the technical implementation of this change, please see [#51020](https://github.com/WordPress/gutenberg/pull/51020). _Props to [**@leonugraha**](https://profiles.wordpress.org/leonnugraha/), [@juanmaguitar](https://profiles.wordpress.org/juanmaguitar/), and [@mburridge](https://profiles.wordpress.org/mburridge/) for review._ [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/aaronrobertshaw/) [Aaron Robertshaw](https://profiles.wordpress.org/aaronrobertshaw/) 10:23 am _on_ July 17, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Introducing the Block Selectors API](https://make.wordpress.org/core/2023/07/17/introducing-the-block-selectors-api/)󠁿 The 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. Selectors 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. allows more flexibility in how global styles are applied to blocks. As the available design tools grow in number and complexity, not all styles can be applied neatly to a block’s wrapping element. In WordPress 5.8, the `__experimentalSelector` property was introduced and later evolved to facilitate applying feature-level global styles, such as borders, colors, and typography, to arbitrary selectors. Similarly, the `__experimentalDuotone` property was also introduced in WordPress 5.8 to support the application of SVG filters. As advancements in design tools continue, the need for greater control over the application of global styles has grown more pressing. It is, for this reason, the selectors API has been extended and stabilized. ## New selectors API features Through the new API, a block can configure multiple CSSCSS Cascading Style Sheets. selectors for use in generating global styles. These can be set at three different levels; root, feature, and sub-feature. ### **Root selectors** A root selector is the block’s primary CSS selector. All blocks require a primary CSS selector for their global style declarations to be included under. If one hasn’t been supplied via the Block Selectors API, a default will be generated in the form of `.wp-block-`. **Example:** ```wp-block-code { ... "selectors": { "root": ".my-custom-block-selector" } } ``` ### Feature-level selectors This level of selector relates to styles for specific block support, such as border, color, typography, etc. They allow for a block to apply such styles to different elements within a block. For example, applying colors to the block’s wrapper but typographic styles to an inner text element. **Example:** ```language-json { ... "selectors": { "root": ".my-custom-block-selector", "color": ".my-custom-block-selector", "typography": ".my-custom-block-selector > h2" } } ``` ### Subfeature selectors These selectors relate to individual styles provided by block support e.g. `background- color` or `border-radius`. A subfeature can now have styles generated under its own unique selector. This is most useful when a single feature’s styles need to be applied to separate elements. For example, a block’s typography might require `font-family` on the wrapper but` text-decoration` and `font-size` on different inner elements. **Example:** ```wp-block-code { ... "selectors": { "root": ".my-custom-block-selector", "color": ".my-custom-block-selector", "typography": { "root": ".my-custom-block-selector > h2", "text-decoration": ".my-custom-block-selector > h2 span" } } } ``` ### Shorthand For convenience, instead of specifying the same selector for every subfeature, you can define a simple string at the feature level. ### Fallbacks If a selector has not been configured for a given feature, it will fall back to the block’s root selector. Similarly, if a subfeature has no custom selector set, it will fall back first to its parent feature’s selector before the block’s root selector. A detailed example configuration and explanation can be found in the [Block Selectors API reference guide](https://github.com/WordPress/gutenberg/blob/trunk/docs/reference-guides/block-api/block-selectors.md#fallbacks). ## Backwards compatibility Blocks currently using the `__experimentalSelector` and `__experimentalDuotone` support properties will continue to function as before.  However, if a block adds a selectors property in its block.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML., that selectors configuration will be honored in its entirety. In other words, a **block cannot use _both_ the Selectors API and the old experimental properties**. ## Links * [Block Selectors API Reference Guide](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-selectors/) * [Original issue proposing the API](https://github.com/WordPress/gutenberg/issues/45194) * [Gutenberg PR stabilizing and extending the API](https://github.com/WordPress/gutenberg/pull/46496) * [Trac ticket introducing selectors property to block types](https://core.trac.wordpress.org/ticket/57585) _Props to _[@bph](https://profiles.wordpress.org/bph/)_, _[@annezazu](https://profiles.wordpress.org/annezazu/),__ [@priethor](https://profiles.wordpress.org/priethor/)_ and _[@leonnugraha](https://profiles.wordpress.org/leonnugraha/) for reviewing. [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/flixos90/) [Felix Arntz](https://profiles.wordpress.org/flixos90/) 5:18 pm _on_ July 14, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Configuring development mode in 6.3](https://make.wordpress.org/core/2023/07/14/configuring-development-mode-in-6-3/)󠁿 WordPress 6.3 introduces a new concept called “development mode”, which affects certain nuances in how WordPress behaves. Going forward, sites will be able to configure their development mode using a new `WP_DEVELOPMENT_MODE` constant, which is recommended for any development sites. ## What is the development mode? The development mode configured on a site defines the kind of development work that the site is being used for.  Possible values for `WP_DEVELOPMENT_MODE` are: * “coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.” indicates that this site is used as a WordPress core development environment. For example, this may be relevant when you are contributing directly to WordPress core. * “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.” indicates that this site is used as a WordPress plugin development environment. For example, this may be relevant when you are working on a plugin for the plugin repository. * “theme” indicates that this site is used as a WordPress theme development environment. For example, this may be relevant when you are working on a theme for the theme repository. * “all” indicates that this site is used as a WordPress development environment where all three aspects may be modified. For example, this may be relevant when you are working on a specific site as a whole, e.g. for a client. * An empty string indicates that no particular development mode is enabled for this site. This is the default value and should be used on any site that is not used for development. Per this definition, setting a development mode is only relevant for sites where any kind of development is occurring. For example, it is not advised or relevant to use on a production siteProduction Site A production site is a live site online meant to be viewed by your visitors, as opposed to a site that is staged for development or testing.. ### What specifically does the development mode do? There are currently only a few use-cases in WordPress core which are determined by the development mode, but this will likely increase in the future. Most usage today relates to `theme.json` caching. It is also a great example for the kind of nuance that the development mode of a site affects: * On most sites, caching certain data from `theme.json` is reliable since that data would only be invalidated when the theme is updated. * However, if you are actively developing a theme on the site and modifying `theme. json` constantly, having to manually invalidate the cache all the time would be detrimental to the development workflow. Therefore, that specific caching functionality is bypassed if the development mode is set to “theme”. * On the flipside, if you are directly contributing to WordPress core (i.e. setting your development mode to “core”), your site should behave as close to the actual behavior as possible, so even though you are in a development environment as well, having the `theme.json` data cache bypassed would not represent the actual behavior intended for a regular WordPress site. * That is why that specific caching functionality is only bypassed during theme development, but not during core development. ### Difference between development mode, environment type, and debug mode WordPress already contains two seemingly related concepts, which are the environment type (`WP_ENVIRONMENT_TYPE` constant) and debug mode (`WP_DEBUG` constant). Here is how they differ: * `WP_DEBUG` (boolean) toggles general debugging mode, which results in additional notices being displayed or logged. * [`WP_ENVIRONMENT_TYPE`](https://make.wordpress.org/core/2020/08/27/wordpress-environment-types/)( string) defines whether the site is a local, development, staging, or production environment. This value can be used to set defaults for other configuration parameters or toggle certain features on the site. * `WP_DEVELOPMENT_MODE` (string) defines a specific scope of development that applies to the current site, which results in certain low-level WordPress behavior to change. This is different from `WP_DEBUG` which does not affect actual behavior. Additionally, `WP_DEBUG` typically applies to any development environment, while` WP_DEVELOPMENT_MODE` is more specific, as explained in the aforementioned example. It is likely that you will only use the `WP_DEVELOPMENT_MODE` constant on a site where `WP_DEBUG` is enabled and `WP_ENVIRONMENT_TYPE` is either “development” or“ local”, since it is not advised for development to occur directly against staging or production environments. That said, the constant is still decoupled, also because it defines the kind of development that is occurring more granularly than a simple on/off switch like `WP_DEBUG`. ## Setting the development mode for a site To set the development mode for a site, simply add a definition of the `WP_DEVELOPMENT_MODE` constant to your wp-config.php file. For example, if your site is a development environment for your plugin: ```notranslate define( 'WP_DEVELOPMENT_MODE', 'plugin' ); ``` Most likely, in this case you also want to make sure you have `WP_DEBUG` enabled and `WP_ENVIRONMENT_TYPE` set to “development” or “local”. ## Checking the development mode for a site A new function `wp_is_development_mode( $mode )` is the recommended way to check whether a given development mode is enabled for the WordPress site. The function expects you to pass a `$mode` parameter that you would like to check for (e.g. “ core”, “plugin”, or “theme”) and returns a boolean for whether said mode is enabled. Per the aforementioned list of possible values, if a site has `WP_DEVELOPMENT_MODE` set to “all”, the function will return true for any `$mode` passed. Here is an example: ```notranslate if ( wp_is_development_mode( 'theme' ) ) { /* * This could contain some logic that only applies when developing a theme * on the site. */ } ``` Additionally to `wp_is_development_mode( $mode )`, another lower-level function ` wp_get_development_mode()` has also been added in WordPress 6.3, which returns the value of the `WP_DEVELOPMENT_MODE` constant directly. However, accessing the constant value directly is discouraged. Due to special values such as “all” that can encompass multiple other development modes, it is advised to always use `wp_is_development_mode( $mode )` instead. If you are logged into the WP Adminadmin (and super admin) interface, you can access the current value of the `WP_DEVELOPMENT_MODE` constant under _Tools > Site Health > Info_, in the _WordPress Constants_ section. See [#57487](https://core.trac.wordpress.org/ticket/57487) for additional context on this change. _Props [@peterwilsoncc](https://profiles.wordpress.org/peterwilsoncc/) for technical review, [@stevenlinx](https://profiles.wordpress.org/stevenlinx/) for proofreading._ **Update July 17, 2023:** The function `wp_in_development_mode()` was renamed to` wp_is_development_mode()` after initial publication of this article (see [[56249]](https://core.trac.wordpress.org/changeset/56249)). All references have been updated. [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) [ ](https://profiles.wordpress.org/isabel_brison/) [Isabel Brison](https://profiles.wordpress.org/isabel_brison/) 2:38 pm _on_ July 14, 2023 Tags: [6-3 ( 70 )](https://make.wordpress.org/core/tag/6-3/), [dev-notes ( 620 )](https://make.wordpress.org/core/tag/dev-notes/), dev-notes-6.3 # 󠀁[Layout updates in the editor for WordPress 6.3](https://make.wordpress.org/core/2023/07/14/layout-updates-in-the-editor-for-wordpress-6-3/)󠁿 Here are the 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. for layout-related changes in the editor. ## Layout support stabilization and updates 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. support for layout has now graduated from experimental to stable. Everything works the same; the only difference is that when adding block support for layout in `block.json`, its name is now `layout` instead of `__experimentalLayout`. Support for the `__experimentalLayout` syntax will be maintained for a while, but it is recommended to upgrade any custom blocks using layout to the stable `layout` syntax. ([#51434](https://github.com/WordPress/gutenberg/pull/51434)) Code example (in `block.json`): ```notranslate "supports": { "layout": true } ``` ## Changes in CSSCSS Cascading Style Sheets. specificity for some layout types The CSS output for the `margin` styles of children of `constrained` and `flow` ( default) layout containers has changed. The generic rules used to have a specificity of `0,1,0` for all blocks; they have now changed to `0,0,0` for all blocks with an extra `0,2,0` rule applied only to the first and last blocks in the container. This fixes the issue of global margin styles for specific blocks being overridden by layout styles (see [#43404](https://github.com/WordPress/gutenberg/issues/43404)). ## Compound block and layout type classname applied to inner wrapper of layout blocks As of WP 6.2, [layout classnames are added to the block inner wrapper](https://github.com/WordPress/gutenberg/pull/44600). For most blocks, this is the same as the outer wrapper, but some blocks (e.g. coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Cover) have multiple inner containers. In 6.3, a new classname is added to the inner wrapper of all blocks with layout, comprised of block classname + layout classname, e.g.: `.wp-block-cover-is-layout-constrained`. This is the updated Cover block markup: ```notranslate <div class="wp-block-cover is-light"> <span aria-hidden="true" class="wp-block-cover__background has-tertiary-background-color has-background-dim-100 has-background-dim"></span> <div class="wp-block-cover__inner-container is-layout-constrained wp-block-cover-is-layout-constrained"> <p class="has-text-align-center has-large-font-size"></p> </div> </div> ``` This makes it possible for blocks with a complex markup structure to support custom spacing styles. ## Layout definitions removed from core `theme.json` The layout definitions object, which stores base styles for the layout block support, has been removed from the core `theme.json` (`settings.layout.definitions`) and moved into the internal layout support files. Extending or overriding core layout definitions was never officially supported and including those definitions in a theme `theme.json` file resulted in bugs such as [#49914](https://github.com/WordPress/gutenberg/issues/49914). Create Block Theme 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. generated `theme.json` files that included the layout definitions object before the 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. was fixed in [#50268](https://github.com/WordPress/gutenberg/pull/50268), so theme authors are advised to remove any layout definitions that may have been inadvertently included in their `theme.json` files in order to prevent buggy behavior. ## New Grid layout type A new grid layout type is available, based on CSS Grid, and defaulting to an `auto- fill` approach with configurable column width. It is also possible to set a fixed number of columns, by using the `columnCount` property in the layout object. ([#49018](https://github.com/WordPress/gutenberg/pull/49018)) To create a block with a grid layout, the following needs to be added in the `supports` object of the block’s `block.json`: ```notranslate "layout": { "default": { "type": "grid" } } ``` ## Layout and block spacing support added to Post Template block Previously, the Post Template block had custom layout styles that allowed for either a “list” or a “grid” (implemented behind the scenes with CSS flex) layout, with controls living in its parent Query block. For 6.3, layout and block spacing support have been added to Post Template, and its controls now live in the Post Template toolbar. There is still a choice of “ list” and “grid” styles, but “grid” is now implemented with the grid layout type.( [#49050](https://github.com/WordPress/gutenberg/pull/49050)) ## Spacer block gets orientation from the parent block layout Spacer blocks inside a `flex` type layout block will now use the orientation of the parent layout. It is still possible to pass Spacer an orientation value from the parent block context, but Spacer blocks inside flex layouts will prioritize the flex orientation over the context one. (#[49322](https://github.com/WordPress/gutenberg/pull/49322)) _Props for co-editing to [@andrewserong](https://profiles.wordpress.org/andrewserong/)_ _and review to [@bph](https://profiles.wordpress.org/bph/) and _[@leonnugraha](https://profiles.wordpress.org/leonnugraha/). [#6-3](https://make.wordpress.org/core/tag/6-3/), [#dev-notes](https://make.wordpress.org/core/tag/dev-notes/), [#dev-notes6-3](https://make.wordpress.org/core/tag/dev-notes6-3/) # Post navigation [← Older posts](https://make.wordpress.org/core/tag/dev-notes6-3/page/2/?output_format=md)