Upcoming in WordPress 5.5: Features and Changes Theme Authors Should Know About

August 11, the target release date for WordPress 5.5, is just shy of two weeks away. For developers who have not been completely on top of the upcoming release, now is a good time to start looking at how changes might affect their projects. Theme authors in particular can expect several new features and some breaking changes.

For the most part, WordPress 5.5 will introduce new features that theme developers can begin to add to their themes. However, the two biggest changes that could negatively impact their themes will be automatic updates and direct HTML changes to the custom logo output.

Outside of the new features and changes, theme authors should catch up on our coverage of the Gutenberg plugin and test against its updates that are being merged into core WordPress.

Auto Updates

WordPress 5.5 will finally introduce automatic updates for plugins and themes. It is a long-awaited feature and should be a good thing in terms of keeping end-users updated and running what is usually the most secure version of their extensions. However, the big downside to automatic updates is that most themes and plugins will not have the same level of quality control as core WordPress receives. Even the best development companies might have only a few people looking over the code.

On the flip-side, the automatic updates feature means that theme authors can push fixes out to end-users much more quickly.

The big thing is that theme developers need to be aware that users will be enabling automatic updates. For some, this might not mean changing anything with their release cycles. For others, it might mean tacking on some extra time to ensure that extra quality control is in place. The success of automatic updates lies directly on the shoulders of the plugin and theme authors. It is a huge responsibility that should not be taken lightly. WordPress is placing a lot of trust in its development community to get this right.

HTML Change for Custom Logos

As part of an accessibility-related ticket for WordPress 5.5, the core get_custom_logo() and the_custom_logo() functions will no longer output a link around the logo image when viewing the site homepage. This change was made because the link itself points to the homepage by default and is unnecessary in that context.

Right now, there are 183 themes in the official theme directory that target the link in their CSS. This does not necessarily mean that all 183 themes will be broken upon update. However, it likely means that some of them will need a tweak or two.

Theme authors are encouraged to target the .custom-logo-link class instead of any particular HTML element. The new change will add a element rather than an element on the homepage. Both will use the same class.

Block Patterns Have Arrived

It is no secret that I am downright giddy about the prospect of theme designers being loosed upon the world, allowing their talents to shine via block patterns. Patterns have been one of the missing features since the initial launch of the Gutenberg project. For theme authors, they represent that missing link between designing unique “templates” or “sections” and providing end-users a means to add them to their sites.

Block patterns are essentially groups of pre-configured blocks that users can insert into their posts or pages at the click of a button. The beauty of the system is that theme authors can design whatever patterns their hearts desire and make them easily available to their users. No need for complicated theme settings. No lengthy tutorials explaining how to recreate the demo. Design something in the block editor. Register it as a pattern. Let users insert it into a post and rejoice.

This is an opportunity that theme authors have never had before. It is an opportunity to create beautiful designs without having to worry about overcomplicating it for the average user. It is a pivotal moment in WordPress theme design history. Theme authors have the chance to push the system and see what WordPress and its block editor are truly capable of.

Building a restaurant theme? Provide users with multiple food menu patterns. Creating something for novelists or other book authors? Give users some layout options for showcasing their books.

The block patterns API removes many prior limits to what theme authors could realistically do. Now, it’s time for those theme authors to take charge.

Line Heights and Custom Units

The block editor has two new tools for end-users to take advantage of: custom line-heights and custom units. Theme authors can opt into allowing users to edit the line-height of paragraphs and headings with the custom-line-heights theme support flag. They can also allow users to switch between various units, such as when defining the Cover block’s height, with the custom-units flag. In addition to pixels, themes can define which units are supported.

Allowing users to customize the line-height value for text can be tricky business. There are some situations where it is warranted. However, for theme authors who prefer to maintain a strict vertical rhythm, this could lead to disaster. This will likely come down to a personal choice for developers based on what type of theme they are building.

Accessible Widgets Navigation

Starting with WordPress 5.5, theme authors will be able to opt into outputting more accessible widgets. By default, widgets that display unordered lists do so without any context. This can make it difficult for those using assistive technologies to navigate the site.

Theme authors can now add navigation-widgets to the HTML5 theme supports array to add the new markup. WordPress will then wrap all core widgets with a

element and an aria-label based on the widget title.

This will not affect widgets from third-party plugins. Plugin authors should reevaluate their widgets to determine if they want to support this feature.

Template Functions Updates

WordPress is tacking on some nice features for its templating functions in the upcoming release. The first major change is that theme authors can pass data to template files. We have previously covered this story on the Tavern. This feature, while years late, should still be useful for more complex theming setups and allow developers to bypass odd workarounds or in-house solutions.

Template-loading functions, such as get_template_part() and others, will also return a value in WordPress 5.5. If the template is not found, the function will return a false value. Otherwise, it will return void. This will be helpful in situations where theme authors need to run a conditional to check if a template exists.