Welcome to the first edition of a new monthly series for developers. This post—and hopefully many more to come—will list all of the features, changes, and other vital items the WordPress extender community should know about.
The goal of the monthly roundup is to cut through the noise of a busy release cycle and present you all with a full list of resources to help keep up to date. The roundup includes notes specific to plugin and theme development as well as a list of educational resources created by members of the WordPress community. Because this is the first edition, feedback on the format and the content of this post is encouraged. Please share your thoughts in the comments.
Note that this first roundup includes some features that span both January 2023 and December 2022, but subsequent posts will only cover the previous month.
Table of contents
Highlights
Many exciting features have landed in the last couple of months, and each should ship with WordPress 6.2. It’s recommended to test against at least version 15.1 of the Gutenberg plugin since features can change rapidly during the release cycle.
Style Book
Gutenberg 14.8 introduced a new Style Book feature in the site editor as part of the Styles interface. It allows users to see the changes they make to each block, even if it’s not in the template they are editing. For theme designers, it offers a convenient location to test and modify each block’s design in their themes.
The Style Book also automatically supports third-party blocks, so plugin developers do not have to worry about any special integration. Everything just works.
Box shadows
Gutenberg 14.9 introduced box-shadow support via theme.json. It allows theme developers to add a group of custom shadow presets, which can then be assigned to blocks and elements. Gutenberg 15.1 adds a shadow selector to the Styles interface for registered shadow presets.
Visit the tutorial on the Dev Blog for using the shadow feature for themes.
Custom CSS
The first iteration of a Custom CSS feature landed in Gutenberg 14.8. The goal is to bring feature parity with the customizer’s “Additional CSS” field so that users and developers can make direct style modifications via the site editor.
You can locate the CSS field by visiting the site editor and clicking on the Edit button for any template. Then, select the Styles menu and click the vertical ellipsis button (⋮). Finally, click the Additional CSS item in the dropdown menu. Once custom CSS is added, the option will appear permanently in the sidebar.
As of Gutenberg 15.1, per-block CSS customization is available. Developers can also add CSS for individual blocks via theme.json.
Currently, the field shows a validation message for broken CSS, but it is not a full linting solution. Extended tools will likely not land until after WordPress 6.2. Keep track of the following related tickets for more information:
- Add inline code completion and linting to input box similar to customizer
- Provide list of blocks that have had custom CSS applied at the block level
Breaking changes and deprecations
There are two major changes that developers should to test their plugins and themes against before WordPress 6.2 lands. There may be scenarios where code needs to be changed.
Potential breaking change: The Query Loop block no longer has color support. It is now purely a settings-only block without design-related options. WordPress will introduce a wrapping Group block over its nested blocks and should migrate existing colors settings to the Group. Developers should test this to make sure that this does not negatively affect existing uses of Query Loop blocks in their themes.
The get_page_by_title() function will be deprecated in WordPress 6.2. Plugin and theme developers should switch any uses of it to a WP_Query instance.
Plugins and tools
Split block tools
Gutenberg 14.7 introduced a change that splits the block tools panel into separate tabs: styles and settings. The former groups all of the design-related tools together, and the latter houses all other options.
Block developers should test their custom blocks to ensure their custom settings are under the correct tab. If not, the update also introduced a group attribute for InspectorControls, which allows plugin authors to attach controls to the appropriate tab. By default, registered controls are placed under the settings tab.
Bottom margins for components
There is an ongoing project to overhaul components to remove their default bottom margin, which allows them to more easily be used in various contexts. Several components have had their bottom margins removed and have a new opt-in __nextHasNoMarginBottom prop:
ID support for block wrapper attributes
The get_block_wrapper_attributes() function now includes an id attribute as an item in the associative array that it returns. The additional attribute goes alongside the existing class and style attributes that the function previously returned.
Control the search columns for WP_Query
WP_Query now supports a new search_columns argument, which allows developers to control which database columns are included when performing a search query via the s argument. By default, the post_title, post_content, and post_excerpt columns are included. The new argument allows developers to fine-tune the search without filtering and manually adjusting the SQL query directly.
The change also introduced the posts_search_columns filter hook, which provides an array of the columns to search.
Custom attachment filenames for wp_mail()
Nine years after the ticket was first opened, the wp_mail() function now allows developers to customize the email attachment filenames. The changeset adds support for passing an associative array named $attachments where string keys are used as the filenames.
Disabled property for the TabPanel component
The TabPanel component now supports a disabled property when set on one of its tabs objects. Developers can use this to show the tab to users for custom implementations in the editor while not allowing them to interact with it.
Get the last inserted block client ID
A new selector for getting the last inserted block client ID was first introduced. However, it was deprecated in favor of a selector for returning an array of multiple block client IDs. The new getLastInsertedBlocksClientIds selector allows tracking the state when one or multiple blocks were inserted.
Check if a theme has a theme.json
WordPress is introducing a new wp_theme_has_theme_json() function. It is a conditional for checking whether the currently active theme or its parent has a theme.json file.
Revised Link control component
The LinkControl component is in the midst of a UI overhaul. While this is mostly a visual change that won’t affect block developers, any blocks or custom components that consume it should be checked for potential issues.
Hooks
Contributors have added a few new hooks over the past month. The first is a new wp_set_password action hook that fires whenever the wp_set_password() function is called. This allows developers to catch any instance of a password being set and run their own functionality.
The wp_ajax_save_attachment action hook executes after an attachment has been updated but before the JSON response is sent. This allows developers to update any additional attachment fields that have been rendered.
A new bulk_edit_posts action hook fires after processing the post data on a bulk edit. This should make it easier for developers to save extra data in this scenario without relying on custom Ajax.
While it is not a new hook, developers who added a filter on wp_lazy_loading_enabled have been unable to control whether the featured image on a page was lazily loaded. A recent patch now addresses the logic behind this, allowing for full control over how images are loaded.
Themes
Hallway Hangouts
Two Hallway Hangouts related to block themes have been held over the past couple of months:
- Performance considerations for block themes: This session was primarily about the changes under the hood and discussed such things as making the JSON parsing system more efficient.
- Themer Goodies: This event covered more practical scenarios for theme authors with a heavy focus on style-related features.
Typography updates
The fluid typography feature introduced in WordPress 6.1 made it much easier for theme designers to dip their toes into intrinsic design via a few settings in theme.json. Now, they will be able to further refine how font sizes scale by setting a minimum size.
More and more blocks are reaching parity with one another and allowing for full support of the typography-related design tools. In the past month, the Page List block gained support for the full suite of options.
Layout updates
WordPress 6.1 fleshed out much of its layout system for theme authors, and contributors continue building upon that foundation. Flex layouts now support more dimension options. Children of the Row block has a new width control. Likewise, children of the Stack block have a height control. Each of these controls has three options:
- Fit: Block fits to fill its needed space.
- Fill: Block stretches to fill any available space. This requires a fixed height for the Stack block to stretch at all.
- Fixed: When selected, a specific unit-based width/height can be set for the block.
Position support is currently being worked on, and the first iteration of a “sticky” position is available via the Gutenberg 15.1. This will allow designers to create themes with features such as sticky headers. The foundation of the feature should ship with WordPress 6.2. However, there are several followup tasks to flesh out this feature that have been punted to the WordPress 6.3 development cycle.
Post editor in an iframe for block themes
The post editor’s content canvas is in an iframe similar to the site editor when a block theme is active. This should not directly affect any existing code, but it may allow theme authors to cut out some CSS hacks for edge cases. Essentially, the change should make for fewer CSS conflicts.
Update: there is currently an open ticket related to supporting third-party script dependencies in the iframed post editor that might affect some custom blocks.
Update – 2023-02-16: this has been reverted for WordPress core to give plugin authors more time to support the change. In the next version, the editor will only be in an iframe if all blocks are using version 3 of the API or later.
Template types for patterns
The Patterns API now supports registering patterns for template types. This is a feature that theme authors should keep an eye on in the WordPress 6.2 development cycle. It could play an integral role within the template-creation workflow, but it has not yet been merged into the UI.
Edit block style variations from the Styles interface
Users can now edit existing block style variations via the Styles interface in the site editor. This could have an impact on theme-registered styles, which generally have custom CSS associated with them. The longer term goal would be for the creation of custom block styles directly from the UI.
Appearance tools support via functions.php
Originally added in WordPress 6.1, themes could enable several appearance-related defaults via theme.json. Version 6.2 will introduce a theme-support equivalent that developers can opt into via functions.php.
Updated block pattern categories and descriptions
WordPress 6.2 will support descriptions for block pattern categories. Core is also introducing several new default categories that theme authors can use:
- banner
- call-to-action
- contact
- portfolio
- posts
- services
- team
- testimonials
Educational resources
WordPress TV video tutorials
The WordPress Training team has published several new video tutorials that will be helpful for developers:
- Streamline your block theme development with Create Block Theme: Learn how to use the Create Bock Theme plugin to streamline your block theme development processes.
- Introduction to securely developing plugins: Introduces new developers to the first five areas of plugin security using easy-to-understand examples.
- Using theme.json with classic themes: Learn how to integrate
theme.jsoninto a classic theme and control block settings and styles. - The WordPress REST API:
- Using the WP REST API: Learn how to use the WP REST API to interact with existing WordPress data.
- Interacting with the WP REST API: Learn how to interact add and delete data. The tutorial also looks at a useful developer tool for testing endpoints.
- WP REST API updates, custom fields, and authentication: Learn how to use the REST API and Backbone.js to make update requests, add/update custom fields, and authenticate requests when logged out.
- WP REST API – modifying responses: Learn one of the ways to extend the REST API by modifying responses.
- WP REST API – custom routes and endpoints: Learn how to create custom routes and endpoints and test them with Postman.
Props to @bph for co-writing and wrangling all of the resources and @richtabor and @annezazu for feedback and review.
Leave a Reply