What’s new for developers? (April 2024)

What a month it’s been! WordPress 6.5 “Regina” officially launched after a minor issue set the release back one week. And there are plenty of developer-related goodies, most of which you can check out in past monthly roundups or many of the other tutorials published here on the Developer Blog in the last couple of months.

And there’s still more to come, as our contributing writers are hard at work finalizing additional content. Really, 6.5 was one of the heaviest developer-focused releases we’ve had in a while, and I guarantee there’s something you’ll find useful for your projects.

But the development cycle keeps spinning, and that means it’s time to set our sights on the next major release: WordPress 6.6. In this edition of the monthly roundup, you’ll find a lot of new things that are on the horizon.

Heads up: WordPress 6.6 will officially drop support of PHP 7.0 and 7.1. The new minimum supported PHP version will be 7.2.24. This shouldn’t affect most users, but be sure to upgrade any old versions before the 6.6 release if you’re one of the 2.45% of WordPress users still on one of those versions.

As usual, be sure to test the changes listed below with WordPress trunk and the latest version of the Gutenberg plugin.

Table of Contents

Highlights

Interactive grid layouts and more

Awesome grid support is coming to WordPress. I know so many of you have been asking for more since it was introduced here on the Developer Blog. Over the last several weeks, contributors have added some big features to grid layouts.

In Gutenberg 17.9, an experimental “interactivity” mode was added, allowing you to drag blocks across columns and rows that are nested within a Grid. You can enable this by visiting Gutenberg > Experiments in your WordPress admin and enabling the Grid interactivity option.

Gutenberg 18.0 shipped new enhancements to make the feature more powerful:

Column Start and Row Start controls were added to the inspector for Grid children.
You can now select multiple blocks and group them as a Grid as you would with other Group block variations.

Color and typography presets in Global Styles

In a nod to theme authors who have traditionally provided selectable typography sets and color schemes, contributors built a similar system in Gutenberg 17.9. Under the Styles panel in the Site Editor, both the Colors and Typography panels will now show presets that users can select to make quick global changes.

This new feature is backed by the existing global style variations system. Any colors or typography settings and styles defined via JSON files located in your theme’s /styles folder will automatically become color or typography presets. In practice, you could even create color or typography-only style variations just for this purpose.

Root support for background images

Gutenberg 18.1 lets you define a top-level background image for the site in theme.json, which will open many opportunities for you to create new and unique designs. Use the example code below to test this feature:

{
	"$schema": "https://github.com/WordPress/gutenberg/raw/trunk/schemas/json/theme.json",
	"version": 2,
	"styles": {
		"background": {
			"backgroundImage": {
				"url": "https://i0.wp.com/wordpress.org/files/2023/12/sotw-dotorg-drawer.png?w=1807&ssl=1",
				"source": "file"
			},
			"backgroundPosition": "center center",
			"backgroundRepeat": "repeat",
			"backgroundSize": "cover"
		}
	}
}

There is currently no method of defining a theme source and referencing a relative image path that is stored in the theme. This is expected in a followup enhancement.

This change is also accompanied by a UI control that lets you set a background from the Styles panel in the Site Editor.

Needs feedback: Major changes for meta boxes

A significant change is coming to how meta boxes are displayed in the Post Editor. Instead of showing them at the bottom of the screen, this PR collects and displays them in a modal connected to a button in the top toolbar:

Meta boxes have been the de facto standard interface for letting users enter custom data from the post-editing screen throughout most of WordPress’s history, at least until the launch of the Block Editor in version 5.0. To unify the Site and Post Editors, the Post Editor needs to be loaded in an iframe, and the current meta box implementation prevents this from happening. This change will provide a consistent WYSIWYG experience between the Editor and frontend views.

Ideally, if you are building a plugin that extends the editor with custom data input, you would transition to one of the available SlotFills in the interface, creating a more integrated user experience.

Contributors ask for assistance in testing this PR with all sorts of plugins. To test, download the ZIP file from the ticket, unzip it into the plugin directory of your test environment, and activate the plugin. It needs to be unzipped and can’t be uploaded through the plugin page. Leave your feedback on the ticket. For questions, you can also join the #outreach channel on WordPress Make Slack.

Plugins and tools

Playground plugin and more

The WordPress Playground project continues to evolve at a fast clip, and as always, we encourage you to give it a spin if you haven’t already done so.

The biggest news is the availability of a new Playground plugin, which lets you run a sandbox of your site in Playground and even test and install plugins inside the sandbox. There are still some kinks to work out, such as this potential performance issue with large amounts of data. But give it a try and report any issues you run into.

Other notable items include:

The start of a new Blueprints PHP library for creating a consistent site setup tool that works with Playground, Docker, and hosted environments.
Stability improvements, including over 50 resolved issues related to compatibility with native PHP, crashes, and error reporting.
The discussion on version 2 of the Blueprints schema continues, and your feedback is wanted on the future of how Blueprints work.

Block Bindings API updates

The initial version of the Block Bindings API shipped with WordPress 6.5, but there is still much more work to be done before the API is as powerful as it should be. A good place to start is an update to the “Connected to custom field” message when a block is bound to a custom data source, which was addressed in Gutenberg 17.9.

A few key bug fixes were also shipped in the 6.5 release:

Bindings were corrected when used inside the Query Loop block in the Editor.
Protected fields bound to blocks are no longer shown.
Pressing Enter when a bound block is selected now behaves correctly, creating a new block in the Editor.

Component updates

Gutenberg 18.0 updated support for a couple of components:

<TextControl> now supports date, time, and datetime-local types.
Nested <MenuGroup> components are styled when used inside the <Dropdown> component.

Coding Standards updates

Both the WordPress Coding Standards and PHP_CodeSniffer projects have been updated in the past month. Be sure to upgrade if you rely on either of them:

Requests library updated

Requests, the Core library that handles HTTP requests for interacting with other sites, has been updated to version 2.0.11 with several changes. The most noteworthy are updates for PHP 8.4 support. This version of the library will ship with WordPress 6.6.

Unifying the Post and Site Editor

An effort is underway to unify and align the publishing functionality between the Post and Site Editor. This requires slots, actions, and selectors that were previously only available in the edit-post package to be moved to the editor package, which is available in both editors. Notably, the following slots are now available in the Site Editor:

These slots will continue to work if you import them from the edit-post package, but they will be deprecated when WordPress 6.6 is released in July.

Code blocks and line breaks

As part of WordPress 6.5, the RichText component was updated so that line breaks are always serialized as HTML elements. This was done to improve performance but had the unintended consequence of breaking third-party plugins that apply syntax highlighting to the Code blocks.

A fix was implemented before WordPress 6.5 was released, but any plugins that directly modify the save function of the Code block will need to make additional adjustments. Guidance is provided in the pull request.

If you rely on a syntax highlighting plugin that experiences issues in WordPress 6.5, you can implement a temporary fix yourself by adding the following filter to your theme:

/**
 * Replace breaks with new lines in all Code blocks on the front end.
 * This filter fixes an issue in the Code Syntax Block.
 *
 * @param string $block_content The block content about to be filtered.
 * @return string The filtered block content.
 */
function themeslug_code_block_add_line_breaks( $block_content ) {
	return str_ireplace(
		[ '<br>', '<br/>', '<br />' ],
		"\n",
		$block_content
	);
}

add_filter( 'render_block_core/code', 'themeslug_code_block_add_line_breaks', 10, 1 );

Pascal case template variable added to Create Block

The Create Block package has a new namespacePascalCase template variable for populating valid PHP namespaces. So, a namespace of create-block becomes CreateBlock when used for PHP namespaces and @package tags.

Extend the list of post content blocks

Gutenberg 18.1 introduced a new editor.postContentBlockTypes JavaScript-based filter hook for the Editor. It lets you customize the list of blocks that should be enabled, even when used inside a locked template.

Themes

WordPress 6.5 introduced a regression for how lightbox settings work in theme.json. The issue made it impossible to enable lightbox while disabling user editing. There is a fix in place, which was shipped with version 6.5.2.

Reducing specificity of global styles

Two PRs landed in Gutenberg 18.1 aimed at reducing the specificity of global styles, which nearly anyone who’s built a theme should appreciate. These tickets were split into their component parts from an earlier effort to reduce specificity:

Reduce specificity of block library styles conflicting with block supports.
Reduce specificity of global styles selectors only.

Be sure to test these changes thoroughly alongside your themes if they have custom styles to ensure compatibility.

Custom block CSS only rendered when in use

Gutenberg 16.9 introduced a nice enhancement that cuts back on the CSS loaded on any given page. Your block-specific custom CSS will now only render on the front end if the block is in use.

Template part replacement flow added to inspector controls

This is more of a user-facing enhancement, but it should create fewer support headaches for you if you build and distribute block themes. In Gutenberg 18.1, users can replace template parts via the inspector sidebar panel in the Sidebar Panel, which will display the alternative parts and patterns available. This change makes the process of replacing a template part globally much easier.

Pattern overrides to use block name

The pattern overrides feature was not shipped with WordPress 6.5 as originally intended. But work on the feature continues for a version 6.6 release. One of the primary issues was how to denote blocks as overridable in patterns. The current solution is to use the existing block naming feature.

Featured image support for the Media & Text block

In Gutenberg 18.0, you can set the Media & Text block to use the featured image, just like the existing Cover image implementation. This opens a wealth of design possibilities for column-based layouts inside the Query Loop block or for single post/page templates.

Block library updates

Several noteworthy block library updates have been added in the past month:

In Gutenberg 17.9, the Search block icon began using a relative size (1.25em).
Added in Gutenberg 18.0, the Post Featured Image block supports shadows.
The Search block input field will correctly inherit its typography rules as of Gutenberg 18.1.
Since Gutenberg 18.0, the Table block uses fixed-width cells by default.
The Medium and Reddit icons were updated to reflect the latest brand guidelines in Gutenberg 18.0.
Gutenberg 18.1 added HTML element support to Site Tagline.

Notable bug fixes

Theme fonts should no longer be loaded twice in Gutenberg 17.9 since these are now handled by the font face resolver.
In Gutenberg 18.0, the Cover block overlay will correctly display when connected to the featured image but there is no featured image present.
Also in Gutenberg 18.0, Social Link block label markup will only be rendered when there’s a label.
In Gutenberg 18.1, pattern previews should correctly use a pattern’s defined viewport width.

Resources

Developer Hours and Learn WordPress Tutorials

It’s been a busy few weeks for Developer Hours and Learn WordPress. Check out the recordings and tutorials below:

Hallway Hangouts

Hallway Hangouts are an opportunity for the community to come together and discuss important topics in WordPress. Recaps for the two events hosted in April are available:

Developer Blog

Check out the most recent tutorial here on the Developer Blog if you haven’t already, and stay tuned for more content showcasing features now available for WordPress 6.5 and those being developed for WordPress 6.6:

Props to @ndiego and @bph for co-writing and reviewing this article.

2 responses to “What’s new for developers? (April 2024)”

Tommaso

April 17, 2024

Support for mega menu was initially hypothesized for WordPress 6.5 and then later delayed to 6.6.
I can’t see here any mentions related to the navigation block and the possibility to create mega menus.

sophia adam

May 19, 2024

What a month it’s been! I’m excited about the official launch of WordPress 6.5 “Regina,” even though a minor issue delayed it by a week. There are plenty of developer-related goodies to explore, as highlighted in the recent monthly roundups and tutorials. With WordPress 6.6 on the horizon, don’t forget to upgrade from PHP 7.0 and 7.1 before support drops. And if you’re looking to upgrade your style too, check out these leather jackets for men!

What’s new for developers? (April 2024)