WordPress 5.9 New Features: Full-Site Editing & New Default Theme
WordPress 5.9 is promising with many new features, big improvements, and enhancements. With this new version, WordPress brings you many new features including blocks & intrinsic web design, navigation menus, interface for theme .json, refining editing flows for blog themes, new default theme, additional design tools, and more.
Let’s see the highlight features of WordPress 5.9 now!
WordPress 5.9 New Features
The main goal for 2021 is getting full site editing to all WordPress users. For WordPress 5.9 new features, the following features are in the suggested roadmap:
- Blocks + intrinsic web design
- Navigation menus
- Interface for theme.json
- Refining editing flows for block themes
- New default theme
- Additional design tools
There are also a few roadmap hopefuls out there.
- Pattern insertion + creation
- Unzip/Rollback Failsafes
- PHPUnit Tests
- Improved compatibility with PHP 8.0 and 8.1
Blocks + intrinsic web design
- One of the biggest points of friction for pattern and theme builders are the lack of responsive tools available at a block level. This needs to be solved in a way that doesn’t disproportionally increase interface complexity.
- The block model is a good case to apply some intrinsic design principles, since a block can occupy a place in many different layouts and containers, for which prescriptive media queries that don’t take context into account are inflexible.
- Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens. For this to work well, container blocks need to absorb more layout controls. (Container queries might help expand this further in the future.)
- Typography tools need to become more fluid and internally support algorithmic clamping. Whenever possible, patterns should just work and accommodate themselves.
Patterns
- With the initial rollout of the new directory there’s a growing need to expand the inserter integration to accommodate broader categories of patterns and the experience of browsing them.
- There’s more work to be done within the setup flow of single and multi-block selections. This also includes improving the mechanisms for transforming to and from patterns, which are still nascent.
- Creation flows with patterns also need expanding from template parts and blocks to pages and templates.
Navigation Menus
- The navigation block and navigation screen projects have been underway for quite some time and are a main target for 5.9. With the principal tracking issue about to be completed, a large part of the remaining work is to improve the user experience, reduce complexity, and test as much as possible on themes.
An interface for theme.json.
- 5.8 introduced the scaffolding necessary for themes to take the reins over how various aspects of blocks render and how the interface is controlled. The natural next step ahead is to develop the user interface that will allow users to interact with these style properties. This goes by the project name “global styles” and an updated design is currently in prototype stage.
- It should be appreciated how important it is to leverage the global reach of CSS rules as we combine it with the power of blocks. The current structure deals with two large groups of design targets: blocks and elements. Elements represent things that can be styled globally and across blocks (such as “text”, “links”, “captions”, etc).
Design Tools: Colors, Typography, Spacing, Layout
- The effort to bring better and more consistent design tools continues to progress. These tools need to integrate smoothly with both the block API (through the “supports” mechanism) and theme.json. One of the main goals is consistent access to similar tools across blocks, including third-party ones.
- Running parallel to this effort comes the work on the WordPress components system, refinements to color tools, interactivity, accessibility, etc.
Formalize editing flows for block themes
- A large percentage of the infrastructure and features needed to build block themes are established. The UX and design needs the most attention, though, starting by mapping into a clearer information architecture all the possible flows that are to be supported (editing templates, parts, styles, pages, etc).
- Continue to process and take into the design process all the feedback gathered from users and theme builders.
- Begin defining transition flows from existing widget areas to block areas when appropriate, and explore the various aspects of theme switching.
- Finalize and commit all remaining blocks under the “theme” category.
Gallery Block Refactor Dev Note
The problem
If you have ever added a custom link to an image block and then tried to do the same on a Gallery image, you will understand the frustration and confusion of not having consistency between different types of image blocks. This inconsistency is because the core Gallery block stores the details of the included images as nested <img> elements within the block content. Therefore, the images within a gallery look and behave different from images within an individual image block. There are some long-standing open issues related to this:
- https://github.com/WordPress/gutenberg/issues/11436
- https://github.com/WordPress/gutenberg/issues/10057
The only way to fix this with the Gallery block in its current state is to try and replicate the additional functionality that the Image block has in the Gallery block, and vice versa. While this would be possible, it would lead to an additional maintenance overhead to keep the UI and underlying code in sync between the two blocks.
Changes made
To make the behavior of images consistent between the Image Block and Gallery, while avoiding code duplication, the core Gallery block has been refactored to save the individual images as nested core Image blocks using the standard core innerBlocks APIs. To make this work with the innerBlocks API, the gallery structure also had to change from an ordered list to a collection of figure elements within a figure. This structure change also brings the core Gallery block into line with the W3C WAI guidelines on the grouping of images.
The structure change means that Gallery images now have the ability to add custom links, or custom styles, for each image. An example of the flexible Gallery layouts this opens up can be seen below.
Gallery images will also automatically inherit new functionality that is added to the Image block, including those added by plugins. Below is an example of a Gallery block making us of the Image wave style and vintage filter option added by the CoBlocks plugin.
Other benefits include being able to use the standard move, drag and drop, copy, duplicate, and remove block functionalities. Keyboard navigation also benefits from the adoption of the standard block model by the Gallery block.
What theme and plugin authors need to do before 5.9
To support the new Gallery block format, plugin and theme authors should aim to do the following before the December release of this change in WordPress 5.9.
- Any gallery-related CSS should have additional selectors added to target images in the following structure in both the editor and front end (existing selectors must remain to support the existing gallery block content). The new structure can be seen below. See this issue for an example of the type of additional selectors that may need to be added.
<figure class="wp-block-gallery blocks-gallery-grid has-nested-images columns-default is-cropped">
<figure class="wp-block-image size-large">
<img
src="https://localhost/image1"
alt="Image gallery image"
class="wp-image-71"
/>
</figure>
<figure class="wp-block-image size-large">
<img
src="https://localhost/image2"
alt="Image gallery image"
class="wp-image-70"
/>
</figure>
</figure>
- For custom blocks with options to transform->from and transform->to the core Gallery block the plugin should be tested with the Gutenberg plugin to ensure that these transformations work correctly with both existing gallery content and the new gallery block format
In the future, when the new Gallery format is stable in a core release, the transformation filters will be deprecated, and plugin authors will need to update their transformations to handle both Gallery formats. Notice will be given ahead of this change being made.
It is also expected that existing gallery content will be automatically migrated to the new format. This will allow the old gallery version’s code to be removed from the codebase. There is currently no time frame set for this to occur.
Additional context and considerations
Other existing solutions
Third-party block developers are currently solving some of the problems caused by the limitations of the core Gallery block by implementing their custom Gallery blocks. These include some of the missing functionality, like the ability to add custom links to individual images. This can be problematic for site owners and content editors due to a large number of Gallery blocks that offer very similar functionality, but none of which appear to provide a close match to the functionality available with individual core Image blocks.
There do not appear to be any examples of plugins that already solve this problem in a way that utilizes Image blocks as inner blocks.
Backwards compatibility considerations
This is a breaking change due to the fundamental change in the underlying Gallery structure. Due to a large number of Gallery blocks already in use, along with themes and plugins that may rely on the existing structure, the following steps have been taken to mitigate the impact of this change on theme and plugin developers as much as possible:
- Initially, there will be no automatic migration of existing gallery content. This means that all existing gallery content will behave the same in the editor and front end as it does now, so will be compatible with existing plugins and themes. Only new gallery blocks added after this change will have the new structure in the editor and the front-end.
- Two temporary transformation filters have been added that will handle the transformation of 3rd party blocks to and from the core gallery block
Possible edge cases
The refactored Gallery format has been tested against the following sample block libraries that have existing transforms to and from the core Gallery block:
The following themes have also been tested to make sure that both the existing gallery content and the new format galleries display correctly:
- TwentyNineteen
- TwentyTwenty
- TwentyTwentyOne
- Astra
- Arbutus
While the refactored gallery works effectively with these plugins and themes, there may be edge cases in other plugins and themes that have not been accounted for. Themes that heavily modify the gallery CSS based on the existing <ul><li></li></ul> will definitely need to be updated if the same style changes need to be applied to the new gallery format. Therefore, it is recommended that theme and plugin authors test the changed gallery block well in advance of the 5.9 release.
Additional details about this change
Previous discussions about this change can be found on the main pull request or call for testing.
WordPress 5.9 Roadmap:
- November 16, 2021: WordPress 5.9 Beta 1 release
- November 30, 2021: WordPress 5.9 Beta 2 release
- December 14, 2021: WordPress 5.9 Release Date
Wrapping Up
Above are the latest features of WordPress 5.9. Our team has been updating our WordPress themes to support this version. Please stay tuned!
See Our Best-selling WordPress Themes:
Below are our best-selling WordPress themes compatible with the latest version of WordPress.
BROWSE ALL WORDPRESS THEMES
See our theme collections:
- See 10+ Best Elementor WooCommerce WordPress Themes 2021
- See 20+ Best multi-vendor marketplace WordPress themes 2021
- See 12+ Best Auto Parts Shop WordPress Themes 2021
- See 15+ Best Clothing & Fashion Shop WordPress Themes 2021
- See 20+ Best Electronics Store WooCommerce Themes 2021
- See 15+ Best Selling Furniture Store WordPress Themes 2021
- See 15+ Best Selling Organic Store WordPress Themes 2021
Our Support Help Desks:
Documentation: Find documentation for themes and frequently asked question on our Documentation channel wpthemego.com/document
Ticket System: Submit a ticket about your problem on WPThemeGo Support at support.wpthemego.com to get help from the support team. All your information will be kept confidential.
Email Support: Contact us via email for presale questions about our themes and other questions via contact@wpthemego.com.
Leave Your Comment