Wordpress and Gutenberg August 2020 Update

The WordPress 5.5 Beta 1 came out on 7th July, followed by Beta 2 on 14th July, Beta 3 on 21st July, and Beta 4 on 27th July. Subsequently, the team also published the primary release candidate of WordPress 5.5 on 28th July. 

The second release of WordPress 5.5 is now here!

WordPress 5.5 is slated for release on August 11, 2020, but we'd like your help to urge there—if you haven’t tried 5.5 yet, now's the time!

You can check the WordPress 5.5 new release in 2 ways:

• Try the WordPress Beta Tester plugin and then choose the 'bleeding edge nightlies' option
• Or download the release candidate here (zip).

If you found Bug Create a ticket in wordpress community bug tracker.

From now onwards, no more commits for any new enhancements or feature requests during this release cycle, only bug fixes, and inline documentation. Work can continue on enhancements/feature requests not completed and committed by now, and maybe picked up for commit again at the beginning of the WordPress 5.6 development cycle.

Plugin and Theme Developers

This WordPress 5.5 update will expand the CMS auto-updating capabilities to themes and plugins.

Currently, auto-updating is merely available for the WordPress CMS core. to stop the location hacks, the auto-update functionality is going to be extended to themes and plugins. Auto-updating of themes and plugins is now expected to ship with a subsequent version of WordPress (v5.5)

Gutenberg 8.5 and 8.6

The core team launched Gutenberg 8.5 and 8.6. Version 8.5 – the last plugin release is going to be included entirely (without experimental features) in WordPress 5.5, introduced improvements to dam drag-and-drop and accessibility, easier updates for external images, and support for the block directory. Version 8.6 comes with features like block pattern & Cover block video position controls updates. For full details on the newest versions on these Gutenberg releases.

New Editor Features

In Slack recently, contributors to the core-editor component were encouraged to specialize in features merging into WordPress 5.5.

Definite inclusion

• New UI design
  • Block movers [PR]
  • Block Inserter panel
  • Surrounding elements
• Block patterns UI and infrastructure
  • Move patterns to Inserter
  • Pattern search
  • Pattern categories

You can also test the following features by turning them on within the Gutenberg plugin 'Experiments' screen.

• Navigation block
  • Navigator interactions
  • Submenus
• Navigation-Menu screen in wp-admin
• Widget-blocks screen in wp-admin
• Core block patterns
• Block Directory
• Block design tools

Feature Plugin: XML Sitemaps

As the native XML Sitemaps in WordPress Core which received lots of interest and feedback from the community, the XML Sitemap feature plugin (MVP) will be implemented in this version.

XML Sitemaps will enable by default making following content type's indexable

– Homepage

– Posts page

– Core Post Types (Pages and Posts)

– Custom Post Types

– Core Taxonomies (Tags and Categories)

– Custom Taxonomies

– Users (Authors)

Additionally, 'robots.txt' file exposed by WordPress will refer to the sitemap index.

Additionally, an XML Sitemaps API delivering with the plugin focusing for developers to build on top of it.

The sitemap index

A crucial feature of the sitemap index in the sitemap plugin. This is the main XML file that contains the list of all the sitemap pages found by your WordPress site and the time of each was last modified. By default, the plugin creates a sitemap index at /sitemap.xml which contains sitemaps for separated into groups by post types, all supported content, users, and taxonomies.

Sitemap pages

Each sitemap page will be available at a URL using the following structure, sitemap-{object-type}-{object-subtype}-{page}.xml. Some examples of this structure applied to the actual content include:

• Post type – posts: sitemap-posts-post-1.xml 
• Post type – pages: sitemap-posts-page-1.xml
• Taxonomy – categories: sitemap-taxonomies-category-1.xml
• Users – sitemap-users-1.xml

The official sitemaps protocol asserts that every sitemap can contain a maximum of fifty, 000 URLs and must be no larger than 50MB (52,428,800 bytes). However, in practice, the performance begins to degrade when trying to get a question that returns quite a couple of thousand URLs, so for that reason, the developer team decided to limit the default implementation to a maximum of two, 000 URLs per sitemap, which may be modified by employing a filter on the core_sitemaps_max_urls hook.

Sitemap pages for every public post type (except attachments) are going to be generated, which include URLs to individual post pages. Likewise, sitemaps are going to be generated for all public taxonomies, which include URLs to taxonomy archive pages, and sitemaps are going to be generated for all users with published public posts, which incorporates the URL for every user’s author archive page. The lists of supported sub-types for taxonomies & posts are often filtered using the core_sitemaps_taxonomies filters and core_sitemaps_post_types, respectively. Additionally, URLs for any object type are often added or removed using the subsequent filters:

• Post types: core_sitemaps_posts_url_list
• Taxonomies: core_sitemaps_taxonomies_url_list
• Users: core_sitemaps_users_url_list

Lazy-Loading Images

For several years, Lazy-loading of images has been commonly used as a mechanism to significantly improve the page-loading performance. For the WordPress ecosystem alone, countless plugins enable lazy-loading.

While historically lazy-loading images have required a custom JavaScript-based approach, there's now a native web solution that relies solely on the presence of a replacement loading attribute on img tags and provides a uniform user experience without content shifting. The HTML specifications for loading attribute are near completion and is already supported by many popular browsers, including Chrome, Firefox & edge.

Enabling lazy-loading for images in WordPress content was first proposed nearly two years ago, however, the JavaScript implementation at the time would potentially have introduced many edge cases and failures. Using the new loading attribute removes these concerns.

Performance Impact

According to HTTPArchive, images are the foremost requested asset type for many websites and typically take up more bandwidth than the other resource. 90% of sites send about 4.7 MB of images on desktop and mobile.

Native lazy-loading for the online, web.dev

Without lazy-loading, all images on an internet page are loaded immediately. this will significantly harm performance, especially on pages that contain many images.

With WordPress enabling native lazy-loading by default, it might significantly impact performance and user experience for many sites, without requiring any technical knowledge or maybe awareness of lazy-loading as an idea. Adopting the new loading attribute may be a great chance for WordPress to steer the way for a faster web overall.

Technical Solution

The loading attribute currently supports two possible values:

• Eager, to load an image immediately on pageload
• Lazy, to load an image only when it becomes relevant for the viewport

The implementation seems to enable lazy-loading images by default, by providing the 'loading' keyword with value 'lazy' on following 'img' tags:

• Images in post content
• Images in post excerpts
• Images in comments
• Images in the text widget content
• Individual images rendered 
• Avatar images rendered 

Note that loading='lazy' will only be added if the respective tags do not include a loading attribute. In other words, to exclude an image from being lazy-loaded, it's recommended to specify loading="eager".

Customization for Developers

Note that the customization capabilities outlined below and the way they work exactly is subject to vary.

While the pictures outlined above are going to be lazy-loaded by default, developers are going to be ready to override this behavior both globally and on a per-image basis.

A new filter wp_lazy_loading_enabled will provide the feature to turn on and off. For instance, one could disable lazy-loading entirely with the subsequent snippet:

This filter also passes a secondary parameter $tag_name, which may be a specific tag name to enable or disable lazy-loading for, and $context, which usually is that the name of the present filter being run. Currently, img is that the only supported value, but since adding loading support to additional tags is on the horizon (e.g. some browsers already support the loading attribute on iframe tags), this parameter exists for future compatibility. For instance, if you would like to be more specific and disable lazy-loading just for images (so that future supported tags would by default have it enabled), you'll use the subsequent snippet.

In addition to the present filter which allows customization across the whole site, there's another filter wp_set_image_loading_attr that filters the worth of the loading attribute for individual control per image. The filter passes the complete img tag markup including all attributes as the second parameter, the complete content blob that the image is a component of, and therefore the context, which usually is that the current filter being run. wp_set_image_loading_attr can for instance be used for interoperability by plugins that currently use alternative mechanisms to lazy-load, for instance, a category or a knowledge attribute. it's recommended to only do that as a transition though, and within the end of the day update such plugins to specify loading="eager", during which case core will leave that in situ as is, as mentioned before.

We are a 360-degree SaaS app development company that provides end-to-end software development services with a focus on next-gen technologies. Our development team specializes in using JavaScript technologies like Angular, Node, and ReactJS to build scalable, responsive, and feature-rich web applications. We also have a dedicated team of Full Stack developers that are capable of performing both frontend and backend tasks. Our SaaS application development services address your mission-critical project requirements through high-quality web and mobile applications that are easy to scale.