What’s New in WordPress 5.5 — A Deep Dive Into an (Epic) Release

WordPress 5.5 “Eckstine” is out, and it’s time for us to introduce the most noticeable changes and features added to Core with the second WordPress release of the year.

These days, we are used to seeing many additions to the block editor at each WordPress release. WordPress 5.5 is no exception!

This version also brings tons of changes not related to the editor that should have a great impact on the way we use the CMS.

While WordPress 5.5 brings many changes to WordPress Core, several features awaited with 5.5 have been delayed and removed from this version because of several unresolved issues. So, full-site editing, navigation block, navigation screen, and widget screen aren’t part of WordPress 5.5.

If you want to read more about WordPress 5.5 development cycle, check the links below:

• 7 July 2020: Beta 1
• 14 July 2020: Beta 2
• 21 July 2020: Beta 3
• 27 July 2020: Beta 4
• 28 July 2020: RC 1
• 4 August 2020: RC 2
• 10 August 2020: RC 3
• 10 August 2020: Dry run for release of WordPress 5.5
• 11 August 2020: Final release of WordPress 5.5 “Eckstine“

So, what’s new in WordPress 5.5?

What’s New With The Block Editor

With the final release of WordPress 5.5, ten versions of the Gutenberg plugin have been added to the core, bringing a huge number of UI improvements, features, enhancements, and bug fixes affecting every aspect of the editing experience, from usability to functionality and performance.

It’d be close to impossible to mention all these changes here, so in this post, you’ll just find a hand-picked selection of our favorite new features and improvements.

For a more comprehensive listing of improvement and features added to the block editor with WordPress 5.5, see the official announcements of the plugin releases: 7.5, 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5.

That being said, here we’ll cover the following additions brought to the block editor with WordPress 5.5:

1. New UI Design
2. Block Design Tools
3. Inline Image Editing
4. Block Categories and New Block Inserter Panel
5. The Block Directory and Block Plugins
6. Block Patterns

New UI Design

Each version of the Gutenberg plugin brings small and not-so-small improvements that are silently changing the overall editing experience. A lot of these changes are now going to be merged into WordPress core. So, when you first launch the block editor in WordPress 5.5, a slightly different interface should grab your attention. You’ll find:

• A simplified Block Toolbar
• Stronger color contrast
• New icons
• Block movers
• Surrounding elements
• Device Previews
• Improved drag and drop
• Improved and unified block focus styles across the whole UI
• Ability to format multiple blocks at once
• Better performance

Those mentioned above are only a few of the many changes affecting the editing experience.

Additional changes also include:

Subscript and Superscript Options

Formatting options for subscript and superscript text are now available through the Rich Text controls (Gutenberg 8.0).

Parent Block Selection

A brand new toolbar button now shows up when hovering over the left side of the block toolbar. The new button allows to select parent blocks in nested contexts (Gutenberg 8.3).

Block Design Tools

Several design tools have been added to the Gutenberg plugin over the last months and now are going to be included in the core with WordPress 5.5.

Height Control and Background Gradients

A first set of tools provide control over dimensions and background color for several blocks (Gutenberg 7.9).

Padding and Link Color Controls

Two additional features landed to the core (Gutenberg 8.3) but at the time of this writing they’re still marked as experimental:

• Padding control for Cover block.
• Link color control for Paragraph, Heading, Group, Columns and Media & Text blocks.

Padding control and link color control are off by default and developers have to explicitly declare support for them, as explained in the Block Editor Handbook.

If you want to add padding controls for the Cover block to your themes, simply add the following line to your theme’s functions.php:

add_theme_support( 'experimental-custom-spacing' );

If you want to enable link color control for Paragraph, Heading, Group, Columns, and Media & Text blocks, just add the following line to your theme’s functions file:

add_theme_support( 'experimental-link-color' );

Custom Units and Custom Line Heights

This new feature allows you to set px, em, rem, vw and vh height values for the Cover block (Gutenberg 7.9). % is also supported but it’s omitted because of the unpredictable rendering of percentage heights.

With the enhanced height control, you can jump values by 10 by holding down Shift while pressing up or down.

Developers can add support for Custom Units by defining the custom-units support flag:

add_theme_support( 'custom-units' );

You can also set specific custom units:

add_theme_support( 'custom-units', 'rem', 'em' );

Developers can also add Custom Line Heights for heading and paragraphs by defining the custom-line-height support flag:

add_theme_support( 'custom-line-height' );

Inline Image Editing

A new editing feature has been added to the block editor with Gutenberg 8.4 allowing users to edit images directly from the Image block.

Now it’s been merged to core and, as of WordPress 5.5, you can crop, rotate, zoom and adjust image positions without the need to launch the Media Library resulting in a faster editing experience.

If you use to publish tons of photos, no doubt you’ll enjoy this feature.

Just click on the Crop button in the image toolbar and you’ll have access to the new editing functionalities. When you’re happy with your customizations, apply your changes and you’re done.

WordPress will save a new image as attachment in the Media Library and copy details from the original image (title, description, caption, alt text, and EXIF data). This gives you complete control over new image versions.

Block Categories and New Block Inserter Panel

A redesigned block inserter panel shows up blocks and patterns by categories, significantly improving the editing experience and making blocks and patterns easier to find (Gutenberg 8.3).

The Block Directory and Block Plugins

With the implementation of the block directory, you can find, install, and add third-party blocks directly from the block inserter.

When you search for a block, if you haven’t it already installed, you’ll be prompted a list of plugins available in the Plugin Directory. Those plugins are called “block plugins” and you can add them to your editor with a single click.

Thanks to this new awesome feature, you can now build your own blocks and publish them to the Plugin Directory making your creations available to the whole WordPress community.

The good news is that, to create your custom blocks, you don’t need to be a PHP guru. You’d just need some working knowledge of JavaScript.

Not sure how to get started developing your own blocks? The awesome WordPress community got you covered with an easy step by step tutorial.

The first version of the block tutorial is already available in the official Block Editor Handbook to help you learn the basics of block development. You can read more about the block directory and block plugin development on the Make WordPress Plugins blog.

Block Patterns

Back in March 2020, Gutenberg 7.7 and Gutenberg 7.8 introduced block patterns and the block patterns API for themes and plugins.

Block patterns are predefined block layouts allowing users to quickly add complex structures of nested blocks to their pages. Their intent is to help content writers and site admins to overcome the “blank page syndrome” and build professional layouts and advanced views with ease.

We should see block patterns at their best with full-site editing.

A clear explanation of what block patterns are intended for comes from Mathias Ventura, Lead architect of the Gutenberg project:

One clarification — the “block patterns” setup is less about template parts (which are structurally meaningful) and more about general design elements made of smaller blocks. Once inserted they are not stored separately. For example, a “Cover” image that combines a few blocks to achieve a specific look that would otherwise take users some work to accomplish. Think of it more as a collection of designs that can be added anywhere without necessarily representing a reusable part of a theme template.

Different from template parts, block patterns are design elements that should help site admins and content creators to speed up and improve their editing experience.

Launched with Gutenberg 7.7, at first Block Patterns appeared in a sidebar plugin. Later, with the release of Gutenberg 8.0, they moved into a revamped block inserter now appearing as a panel placed on the left side of the editor, as shown in the image below:

In their early stage, block patterns come with a very limited set of patterns. Anyway, they bring a huge enhancement to the editing experience, and hopefully, more would be added in the near future.

Like regular blocks, patterns are searchable and come organized in the following categories:

• Text
• Hero
• Columns
• Buttons
• Gallery
• Features
• Testimonials
• Uncategorized

In addition to built-in block patterns, WordPress developers can provide their themes and plugins with custom patterns by taking advantage of a brand new API.

You can register your custom patterns using the register_block_pattern function and register_block_pattern_category for categories.

register_block_pattern takes two arguments:

1. The name of the pattern.
2. An array of pattern properties.

Properties include the following:

• title
• content
• description
• categories
• keywords
• viewportWidth

register_block_pattern_category takes two arguments, as well:

1. The name of the pattern category.
2. An array of properties.

The API also provides two functions to unregister patterns and categories: unregister_block_pattern and unregister_block_pattern_category.

The way you can build your own block patterns is pretty straightforward. For example, copy and paste the following code into a custom plugin or a child theme’s functions file, then change the name of the pattern according to your preferences.

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

The code above is simple customization of the original snippet from the Block API Reference. As you can see, no JavaScript is required.

See also Block Patterns in WordPress 5.5.

Native Image Lazy-Loading in WordPress Core

Lazy loading is an optimization technique that defers loading of non-critical resources. This means that the browser is instructed to load visible content on page load and defer the downloading and rendering of images placed below the fold until they are actually needed.

Before native lazy loading, web developers could lazily load assets via JavaScript, using the IntersectionObserver API or using scroll, resize, and orientationchange event handlers.

But since lazy loading became a standard, we don’t need to write custom code or use JavaScript libraries anymore and lazyload images can be implemented using the new loading attribute in img and iframe tags.

The loading attribute determines if the browser should load a resource immediately or wait until some conditions are met. It currently supports the following values:

• lazy: wait until some conditions are met
• eager: load the resource immediately

At the time of this writing, native lazy loading is supported by Microsoft Edge, Firefox, Google Chrome, Opera browser, Android browser, and Chrome for Android.

Before WordPress 5.5, lazy loading was only possible in WordPress with an optimization plugin like Autoptimize, BJ Lazy Load, or others. Now it’s part of WordPress Core and won’t require additional plugins to be installed!

Native Lazy Loading in WordPress

As Felix Arntz reported in an old blog post on Make WordPress Core blog a JavaScript implementation of lazy loading in WordPress was initially proposed a couple of years ago, but it never became part of the Core. The new implementation of native lazy image loading removes any compatibility concern so the new feature could safely be merged into the Core with WordPress 5.5.

According to Felix, native lazy loading on WordPress images should have a beneficial impact on site performance and user experience for a huge number of WordPress websites that don’t make use of lazy loading plugins:

… without requiring any technical knowledge or even awareness of lazy-loading as a concept. Adopting the new loading attribute is a great chance for WordPress to lead the way for a faster web overall.

In order to prevent layout shifting, loading="lazy" will automatically be added to img tags with width and height attributes and that is only possible if the image is available for WordPress as attachment and includes a wp-image-$id class.

Lazy loading is a must-have optimization for every WordPress installation and website with a considerable amount of images. Felix notes:

This will drastically save bandwidth on both servers as well as user agents across sites where images further down the page used to be loaded right away, even in the case the user might never scroll towards them.

Native lazy loading in WordPress works with the following images:

• Images in post content (the_content).
• Images in post excerpts (the_excerpt).
• Images in text widgets (widget_text_content).
• Avatar images rendered via get_avatar().
• Template images using wp_get_attachment_image

With the first implementation, lazy loading only supports images, but we may expect a future enhancement of lazy load on iframe tags.

Lazy Loading for WordPress Developers

Developers can override the default behavior using several new filters. Among those filters, wp_lazy_loading_enabled and wp_img_tag_add_loading_attr are the most useful for developers:

• wp_lazy_loading_enabled turns the loading attribute on and off. This filter can be applied globally or per tag.
• wp_img_tag_add_loading_attr filters the loading attribute value and provides a way to control lazy loading per image.

The following example shows how to globally disable lazy loading:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

We can also disable lazy loading for a specific tag. In the example below, lazy loading is turned off on images in the_content context (read more on Make WordPress Core):

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'img' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

• $default: The boolean default value (true).
• $tag_name: The tag name of the elements to be lazy-loaded.
• $context: An optional parameter specifying the context of the image (see the list above).

Note that, at the time of this writing, the $tag_name parameter only supports the img tag. Anyway, as mentioned above, more tags should be added to future implementations.

If you want more granular control over image lazy loading in WordPress, you can follow two different approaches depending on the context.

If you are working on the content (i.e. the_content, the_excerpt, widget_text_content), you could use the wp_img_tag_add_loading_attr filter. The following example shows how to disable lazy loading on a specific image:

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_attachment_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' . $image_url . '"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

Theme developers can also control images via wp_get_attachment_image. In this scenario, you can simply set the loading attribute value of the image to false:

echo wp_get_attachment_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

You’ll find further info about lazy-loading images in WordPress 5.5 on the Make WordPress Core blog.

Auto-Updates for Plugins and Themes

One of the greatest concerns for site owners is site security and keeping your software up to date is a common recommendation every site owner should take into account.

WordPress Automatic updates have been available as a feature since WordPress 3.7. Now, the problem here is that while automatic updates are enabled by default for core maintenance and security releases, before WordPress 5.5, many site owners didn’t take advantage of auto-updates for plugins and themes.

Reason being that this feature required basic knowledge of WordPress development. In fact, developers could fine-tune their update preferences by defining one or more constants in wp-config.php or using a filter in a plugin.

Now with WordPress 5.5, site admins can toggle plugin and theme auto-updates on and off with a single click directly in their WordPress dashboard.

Plugin auto-updates can be enabled and disabled by clicking on the link appearing in the Automatic Updates column now available in the Plugins screen.

If you want to enable automatic updates for your theme, browse to Appearance > Themes, then hover over your theme and click on Theme Details. Then, click on the new Enable auto-updates link and you’re done.

The new auto-updates UI for plugins and themes come together with several functions and hooks available for developers to customize the auto-update experience.

Auto-Update Functions and Filters for Plugin and Theme Developers

A new function and several filters allow WordPress developers to customize many aspects of plugin and theme auto-updates.

Check Automatic Update UI

The new wp_is_auto_update_enabled_for_type() WordPress function checks whether auto-update UI is enabled for a given type. The new function accepts a single argument ($type) which determines the type of update to check for ('theme' or 'plugin') and returns true or false accordingly.

The new auto-update UI can be disabled for plugins or themes thanks to two new filters: plugins_auto_update_enabled and themes_auto_update_enabled. See the example below:

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

The filters above are documented in wp-admin/includes/update.php.

Customize Auto-Update Links

Plugin and theme developers can customize the HTML output of auto-update links.

The plugin_auto_update_setting_html filter allows to customize toggle links and time lapse between two update attempts.

The callback function takes three arguments:

• $html: The HTML of the plugin’s auto-update column content, including toggle auto-update action links and time to next update.
• $plugin_file: Path to the plugin file relative to the plugins directory.
• $plugin_data: An array of plugin data.

Now, if you want to customize the label of the auto-update link text, you can use the filter as shown in the following snippet.

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

The image below shows the result on the screen.

This filter is documented in wp-admin/includes/class-wp-plugins-list-table.php.

On single sites, you can customize the JS template of the auto-update link via the theme_auto_update_setting_template filter. The blog post introducing plugin and theme auto-updates provides the following example for this filter:

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

It’s recommended to check for the target theme using the data.id parameter.

If you are working on a WordPress multisite install, then you need the theme_auto_update_setting_html filter, which allows you to customize the Automatic Updates links of the Themes screen in the same way as the Plugins screen.

Finally, two additional filters control all automatic updates for every theme and plugin, including themes and plugins that should be installed in the future.

These filters, available since WordPress 3.7, override all auto-update settings in your WordPress dashboard. You can read more about that in our Deep Dive Into WordPress Automatic Updates. For a deeper view of Automatic Updates for plugins and themes, read more in this blog post.

Auto-Update Email Notifications and Site Health Information

Since WordPress 5.5, an email notification is sent after any auto-update attempt.

The auto_plugin_theme_update_email filter hook filters the emails sent after an automatic background update. See the dev-notes blog post for an example of usage.

Auto-update email notifications can also be disabled using two new filters:

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Plugin and theme auto-update information is also displayed in the Site Health Info tab.

Developers can customize the text appearing on this screen using the plugin_auto_update_debug_string and theme_auto_update_debug_string filters. More info and several examples are available here.

Extensible Core Sitemaps

A sitemap is simply a list of URLs allowing search engines to quickly crawl your website.

Sitemaps are quite similar to robots.txt, with the difference that a robots.txt file excludes content from being indexed, while a sitemap provides a list of URLs to be indexed by search engines.

Before WordPress 5.5, sitemaps could be only added to WordPress websites using a plugin or other tools.

Now, WordPress 5.5 brings a brand new XML sitemaps feature to WordPress Core.

The new feature adds basic functionality, but it comes with a good number of hooks and filters allowing plugin developers to further extend built-in functionalities.

XML sitemaps are enabled by default (unless you discourage search engines from indexing your website) and provide the following object types:

• Homepage
• Posts page
• Core post types (Pages and Posts)
• Custom post types
• Core taxonomies (Tags and Categories)
• Custom taxonomies
• Author archives

The sitemap index is available at /wp-sitemap.xml, which contains a maximum of 2,000 URLs. When the maximum limit is reached, then a new sitemap file is added.

As mentioned before, plugin developers can customize their sitemaps using one or more of the many available actions and filters.

As an example, you can programmatically disable core sitemaps by using the wp_sitemaps_enabled filter, which filters whether XML Sitemaps are enabled or not:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Core sitemaps should not conflict with any sitemap plugins you may have installed on your website. According to Pascal Birchler on Make WordPress Core:

The core sitemaps feature was built in a robust and easily extensible way. If for some reason two sitemaps are exposed on a website (one by core, one by a plugin), this does not result in any negative consequences for the site’s discoverability.

As part of the XML Sitemaps feature, a new esc_xml() function escapes strings for XML blocks. The function and the corresponding filter are documented in wp-includes/formatting.php.

At the time of this writing, the new sitemap feature doesn’t support image/video/news sitemaps and probably this won’t change in the future. Anyway, new filters and hooks allowing developers to add this feature could be added in future versions.

For more info on extensible sitemaps, see the developer introduction to sitemaps which covers new classes, functions, hooks, and filters.

Passing Arguments to Template Files

Before WordPress 5.5, passing data to template files was only possible via global variables, query vars, and a few other non-optimal options. Now, starting with WordPress 5.5, a $args parameter has been added to template loading functions (the corresponding hooks have been updated accordingly):

• get_header()
• get_footer()
• get_sidebar()
• get_template_part()
• locate_template()
• load_template()

Theme developers can now set a variable in a template file and make it accessible in any included template part by simply passing an array of arguments.

Now, while this feature opens new wide opportunities for theme developers, Justin Tadlock at WP Tavern places a good question:

One question remains: is the arrival of this feature too late? With WordPress on track to revamp the entire theme system to integrate with the upcoming full-site editing feature, will this feature be useful for only the next few months?

A good point comes from John Blackbourne:

Even in a future with full site editing, there’s still plenty of need for template parts. Dynamically rendered block types can and do make good use of structured template parts, for example. They aren’t mutually exclusive, and there will always be opinionated themes that don’t make extensive use of blocks for layout.

We finally reached Enrico Sorcinelli, WP Core Contributor, who shared his thoughts with us:

If you’re asking me if we got here too late, from my point of view it’s never too late!
I believe that in the future theme developers can benefit from this opportunity, which does not exclude that it can be used in symbiosis with the emerging full-site editing approach (e.g. for blocks with dynamic rendering).

Maybe it’s simply too early to say how exactly this feature would pair with full-site editing, but one thing seems certain: future development will bring great opportunities to build better websites for both users and developers.

Updating Plugins and Themes From a .zip File

I know what you’re thinking: it may seem quite “unexpected” to see this feature appearing in conjunction with automatic updates. Nonetheless, it does make sense.

Before WordPress 5.5, when lacking a one-click update feature, site admins could only upload plugin/theme updates via FTP/SFTP or file manager (learn the difference between FTP and SFTP). That was mostly true with custom plugins/themes or with extensions hosted on third-party marketplaces.

Starting with WordPress 5.5, you can update plugins and themes by uploading a .zip package from your computer within your WordPress dashboard.

If you want to update a plugin, browse to Plugins > Add New screen and click on the Upload Plugin button. Then, if you have the plugin installed on your website, a new screen lets you know that “This plugin is already installed” and shows the current version and uploaded version details.

The process is pretty similar with theme updates.

Browse to Appearance > Themes screen, then click on Add New, then on Upload Theme. If you have the theme already installed on your WordPress website, a new screen lets you know that “This theme is already installed” and shows the current version and uploaded version details.

Additional Improvements for Developers Coming With WordPress 5.5

In addition to what we’ve covered so far, a couple of additions deserve a developer’s attention.

New wp_get_environment_type() Function

A new wp_get_environment_type() function allows you to detect the current environment type of a website, allowing developers to adapt plugin and theme functionalities to the current environment.

By default, wp_get_environment_type() returns production. Other supported values are development and staging. Anyway, developers are allowed to define additional environment types if needed.

There are three available methods to set a website environment type. From a priority order, you can use:

• WP_ENVIRONMENT_TYPE PHP environment variable.
• WP_ENVIRONMENT_TYPE constant.
• wp_get_environment_type filter.

As an example, if you want to set your environment to staging, you may define the WP_ENVIRONMENT_TYPE constant in your wp-config.php file as shown below:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

If the environment type is development, WP_DEBUG will be automatically set to true even if you haven’t defined it explicitly.

REST API Changes in WordPress 5.5

WordPress 5.5 also brings many changes to the REST API. We’ll see several new endpoints, new parameters and JSON schema changes, new functions, and further enhancements.

Here is a quick list of new endpoints:

Block Types

A new endpoint allows to get all registered block types:

• GET /wp/v2/block-types will return all registered block types.
• GET /wp/v2/block-types/core will return all blocks within the core namespace.
• GET /wp/v2/block-types/core/quote will return the core quote block definition.

Plugins

A new endpoint allows to manage plugins:

• GET /wp/v2/plugins will return a list of all installed plugins.
• GET /wp/v2/plugins/plugin-name/plugin-name will return information about the specified plugin.
• POST /wp/v2/plugins { slug: "plugin-name" } installs the specified plugin from the Plugins Directory
• PUT /wp/v2/plugins/plugin-name/plugin-name { status: "active" } activates the specified plugin
• DELETE /wp/v2/plugins/plugin-name/plugin-name deletes an inactive plugin.

Block Directory

A new endpoint allows to search the block directory:

• GET /wp/v2/block-directory/search?term=block-name searches the block directory for block-name

Image Editing

Pairing with the new inline image editing feature, a new endpoint allows to edit image attachments in the Media Library:

POST /wp/v2/media/5/edit edits the image with ID 5

See WordPress Core dev notes for a closer view at all changes to the REST API coming with WordPress 5.5.

Summary

We are thrilled about all these new features and enhancements WordPress 5.5 brings in a single release.

It shows the huge amount of work happening behind the scenes and we deeply appreciate all the efforts and commitment from every core contributor.

If the changes listed above are not enough for you, here are more you should check out for additional improvements coming with WordPress 5.5:

• 65 new icons added to the Dashicons icon font in WordPress Core
• Accessibility improvements to lists of links in widgets
• New CSS styles for disabled buttons
• Opcode Cache Invalidation
• Better control of redirect_guess_404_permalink()
• PHP Related Improvements
• Codebase changes
• Changes to custom logo functions and filter
• Block API updates
• Archive page headings filters
• Adding icons in Twenty Twenty
• And many more

Now it’s your turn. What are the features and/or improvements you like the most in WordPress 5.5? And what features would you like to be added to WordPress 5.6? Share your thoughts in the comment section below!