Lazy-loading images in 5.5

In WordPress 5.5, images will be lazy-loaded by default, using the native HTML loading attribute which became a web standard earlier in 2020. 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.

By default, WordPress will add loading="lazy" to all img tags that have width and height attributes present. Technically this is handled on page output, similar to how responsive images are facilitated in WordPress by adding srcset and sizes attributes. To improve server-side performance of the two features, a new wp_filter_content_tags() function has been introduced so that img tags only need to be parsed once while then deferring the modifications to more specific functions related to the feature.

See #44427 for the overarching TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker..

Reduced layout shifting as a prerequisite

A common user experience problem in modern website is so-called layout shifting, often caused by slow-loading media resources like images: By default, only after an image is loaded, the browser can layout the page correctly, which results in the content e.g. below the image to shift. This issue can be easily resolved by providing width and height attributes on img tags, as the browser will use them to determine the aspect ratio of the image so that it can infer the page layout ahead of actually loading the image.

While this is already a major problem without lazy-loading images, with lazy-loading it becomes more relevant. Therefore WordPress will only add loading="lazy" to img tags which have both dimension attributes present. At the same time, resolving the underlying issue is just as important to reduce layout shifting in general, which is why with version 5.5 WordPress will start back-filling width and height attributes on img tags when they are not already present. To do that, it reuses the established logic already in place for determining srcset and sizes attributes. Like with those attributes, width and height can only be determined if an image is for a WordPress attachment and if the img tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) includes the relevant wp-image-$id class.

WordPress has mostly been following this best practice, and work is being done to ensure all images in the editor will have width and height. Back-filling these attributes should not have any implications on themes, as long as a theme’s CSSCSS Cascading Style Sheets. works appropriately with classic editor content., which is expected: If an image’s width or height is modified via CSS, the respective other attribute should be set to auto, to avoid the image from being stretched.

See #50367 for further background information on this change.

Customizing lazy-loading

By default, WordPress will add a loading="lazy" attribute to the following images:

  • images within post content (the_content)
  • images within post excerpts (the_excerpt)
  • images within text widgets (widget_text_content)
  • avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. images (get_avatar)
  • template images using wp_get_attachment_image() (wp_get_attachment_image)

Developers can customize this behavior through various filters, the most foundational one being wp_lazy_loading_enabled, which receives the following parameters:

  • $default: The boolean default of true to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
  • $tag_name: An HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. tag name. While per current WordPress behavior this will always be img, it should be noted that the loading attribute is a generic attribute and may be expanded to support further elements, e.g. iframes, in the future.
  • $context: A context string as additional parameters, indicating where the image technically comes from, usually a WordPress hook name. Based on how WordPress itself uses lazy-loading, the context can be one of the five values in parentheses in the list above.

For example, if you would like to turn off lazy-loading by default for template images, you could use the following code snippet:

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

In order to modify the loading attribute for very specific images, there are two different approaches, depending on the type of images:

For images that appear within a content blob (e.g. the_content, the_excerpt, widget_text_content), another new filter wp_img_tag_add_loading_attr can be used, which receives the following parameters:

  • $value: The loading attribute value, either “lazy” (default), “eager”, or false. If you want to disable lazy-loading for an image, it is strongly recommended to specify false so that the attribute is omitted altogether.
  • $image: The entire image HTML tag with its attributes.
  • $context: The context, similar as described for the other filter above.

For example, if you would like to disable lazy-loading for a specific attachment image with ID 42 in size “large” within post content, you could use the following code snippet:

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

For images which are output via wp_get_attachment_image(), the attribute can simply be controlled through the function’s $attr parameter, which can be the same possibles values like the $value parameter for the above filter. In order to not lazy-load an image, an attribute value of false should be specified, which will result in the attribute being omitted. For example:

echo wp_get_attachment_image(
	42,
	'large',
	false,
	array( 'loading' => false ),
);

Theme developers are recommended to granularly handle loading attributes for images anytime they rely on wp_get_attachment_image() or another function based on it (such as the_post_thumbnail() or get_custom_logo()), depending on where they are used within templates. For example, if an image is placed within the header.php template and is very likely to be in the initial viewport, it is advisable to skip the loading attribute for that image.

Images that are marked as candidates for lazy-loading require the browser to resolve where the image is positioned on the page, which relies on the IntersectionObserver to be available and thus as of today slightly delays their fetching. Experiments using Chrome for Android have shown that the impact of such loading=”lazy” images in the initial viewport on the Largest Contentful Paint metric is fairly small, with a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. of <1% at the 75th and 99th percentiles compared to non lazy-loaded images – yet it is a consideration to make where theme developers can apply some fine tuning for even better user experience.

See #50425 for further background information on this change.

Browser compatibility

The loading attribute is widely supported by modern browsers, with an increasing trend: For example, while Safari support is not yet available at the time of publication, the feature is being worked on there as well and has already been merged into the underlying WebKit engine.

Yet, even browsers that currently do not support the loading attribute will not see any negative consequences from WordPress providing the attribute on images, since the native lazy-loading mechanism is implemented as a fully progressive enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.: For those browsers the attribute will simply be ignored. This also means that whenever a browser implements support for the feature, its users will get the benefits right away when they browse WordPress-powered sites.

Props @azaozz for helping with this post.

#5-5, #dev-notes, #feature-lazyloading

PHP related improvements & changes: WordPress 5.5 edition

As part of an ongoing effort to improve compatibility across all supported versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher (currently 5.6.20–7.4), several tooling additions and improvements have been made during the 5.5 cycle.

A large handful of changes were made to address the findings from these tools. Below are some that you need to be aware of.

Automated PHP compatibility scanning

During the WordPress 5.3 cycle, a new job was added to Core’s Travis-CI builds to scan for potential PHP compatibility issues using the PHPCompatibilityWP PHPCS ruleset (see #46152). However, because the scan was reporting a large number of potential issues, it was placed in the allowed_failures list until each issue could be inspected and addressed.

During the 5.5 cycle, each potential issue was examined individually and either fixed, or manually marked as a false-positive.

As of [48046], the job performing a PHP compatibility scan has been removed from the allowed_failures list. 🎉

Now that this scan is not allowed to produce errors or warnings, potential PHP incompatibilities can be flagged and inspected immediately after being committed, ensuring they are never released to the world in WordPress.

In the future when the versions of PHP supported by WordPress change (in either direction), the configuration file can easily be adjusted to detect potential problems within the new range of supported versions.

For more information, see the related ticketticket Created for both bug reports and feature development on the bug tracker. on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (#49922).

Deprecated: wp_unregister_GLOBALS()

The register_globals directive in PHP was deprecated in version 5.3 and removed entirely in 5.4. Because the first line of the function calls ini_get() (which returns false if the directive is not recognized), this function will always return early making it unnecessary.

The wp_unregister_GLOBALS() function is deprecated as of WordPress 5.5.

For more information, see the related ticket on Trac (#49938).

Deprecated: $HTTP_RAW_POST_DATA

The $HTTP_RAW_POST_DATA global variable was deprecated in PHP 5.6.0 and removed completely in PHP 7.0.0. Because of this, developers should not be relying the presence or accuracy of this variable. However, a search of the plugin directory for this variable still yields ~1,500 results. Although some of these matches are flagging $HTTP_RAW_POST_DATA within comments or in compatibility shims, developers should audit their code to remove this variable whenever possible.

Because PHP 5.6 is still supported and this variable is present in a large number of plugins, it will not be completely removed in WordPress 5.5. However, it will be removed from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. when the supported versions of PHP is changed to PHP >= 7.0.

The following is the recommended replacement:

$var = file_get_contents( 'php://input' );

A few occurrences of this variable that did not affect the outcome of the code have been removed in 5.5. However, there are 2 instances that will remain because they were deemed particularly risky to remove before communicating the bad practice to the community.

  • xmplrpc.php (source)
  • wp-includes/rest-api/class-wp-rest-server.php (source)

For more information, refer to the related ticket on Trac (#49810).

Spread operator usage in the IXR library

In WordPress 5.3, the PHP spread operator was introduced throughout the code base. There are several benefits to utilizing the spread operator in addition to code modernization:

“Using the spread operator allowed for simplifying the code and improves performance – both in speed as well as memory use -, especially as it has been introduced in a number of functions which are used a multitude of times during every single pageload…”

WP 5.3: Introducing the spread operator by @jrf

The IXR library bundled with Core (now treated as an “adopted” library) powers XML-RPC related functionality in WordPress.

All func_get_args() calls within the IXR library’s code have now been updated to utilize the spread operator.

For more information, refer to the Trac ticket (#48267), the WP 5.3: Introducing the spread operator dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., or the Trac ticket that originally introduced the spread operator to Core (#47678).

Installing PHPUnit with Composer

Getting a local environment up and running for contributing to WordPress Core can sometimes be difficult, especially when running the PHPUnit test suite is desired. Different combinations of WordPress and PHP versions require different versions of PHPUnit.

Composer is a tool for dependency management in PHP. When project dependencies are specified, it will manage installing and updating those dependencies for you appropriately.

As of [47881], PHPUnit is now defined as a dev requirement in WordPress Core’s composer.json file.

Running composer install will determine the appropriate version of PHPUnit to install based on the PHP version Composer runs on.

For more information, refer to the Trac ticket (#46815).

Other Build/Test Tool improvements

  • Plugins and themes within src are now ignored when running Core linting locally. This will prevent coding standards violations from being flagged when developing locally using src instead of build (see #49781).
  • Previously, when the lint:php job ran on Travis-CI, the code was formatted using PHPCBF prior to linting. Since running composer format returns an error when changes are made, the linting part would not execute and a report would not be generated. Core will no longer run the formatting command prior to linting the code base for issues (see #49722).
  • The WordPress Coding Standards ruleset has been updated from version 2.1.1 to 2.3.0. For a full list of changes included in this update, read ruleset’s release notes (see #50258).
  • The recommended version of PHP specified in the readme.html file has been changed from 7.3 to 7.4. This brings the recommendation in line with the recommendations found on WordPress.org (see #50480)

Props @earnjam for review.

#5-5, #build-tools, #dev-notes, #php

New CSS styles for buttons with disabled state in WP 5.5

[last modified on July 10, 2020 at 10:58 UTC]

In WordPress 5.5, the styles for both primary and secondary buttons were updated in the WordPress adminadmin (and super admin) to produce a more consistent experience when the buttons are disabled.

Previously, the disabled button styling was inconsistent in the WordPress admin between the default and alternate color schemes. Styling was also different between primary and secondary buttons.

Prior to WordPress 5.5 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was decided to simplify all disabled button states to use the same design. There is no need for disabled buttons to convey primary and secondary visual semantics since the disabled state denotes that status.

This change introduces new unified CSSCSS Cascading Style Sheets. declarations for disabled buttons:

color: #a0a5aa;
background: #f7f7f7;
border-color: #ddd;

Those above CSS declarations are used both in the WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. dashboard and the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.

New styles for disabled primary and secondary buttons:

PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors and WordPress developers are encouraged to update the CSS styles they use for their buttons with disabled state for better consistency across the ecosystem. Of course, they are even more encouraged to not use custom styles and to rather user default core UIUI User interface styles instead.

Disabled state of buttons can be easily targeted in CSS, for example by using the following selectors:

button[disabled],
input[type=button][disabled],
input[type=submit][disabled] {
	color: #a0a5aa;
	background: #f7f7f7;
	border-color: #ddd;
}

For reference, see the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.: #48709.

Props @whyisjake, @desrosj and @afercia for proofreading.

#5-5, #accessibility, #core-css, #dev-notes

Accessibility improvements to widgets outputting lists of links in 5.5

When lists of links are displayed on a page for navigational purpose, it can become difficult for users utilizing assistive technologies to navigate between these lists while maintaining an understanding of the purpose of the links. The <ul> element also does not convey proper context.

Starting in WordPress 5.5, a new theme support feature (navigation-widgets) has been added to address this issue. When support is declared, all default widgets included in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that produce lists of links will be output wrapped in the <nav> element. Note: the markup produced inside this wrapper will remain unchanged.

Additionally, an aria-label attribute (which is spoken to users using assistive technologies) is automatically generated based on the widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user.’s title field and added to the nav element to help distinguish each navigation widget from other nav elements on the page (such as a primary navigation).

The feature is fully opt-in. Theme developers must declare HTML5 support for navigation-widgets. For many themes, this may need some additional CSSCSS Cascading Style Sheets. rules or adjustments to ensure the widgets remain properly styled when outputting the new markup.

Theme developers are highly encouraged to utilize this improvement in their themes. This new theme support feature is an easy way to improve semantics and accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) in all of the sites using your theme.

Widgets affected

The following default Core widgets are impacted by this change:

  • Navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site.
  • Archives
  • Categories
  • Pages
  • Recent posts
  • Recent comments
  • MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.
  • RSS

How to declare support

Theme developers are encouraged to declare support for navigation widgets in their functions.php file. This can be done by calling add_theme_support() and passing the preexisting html5 feature with the new navigation-widgets type.

Example

// Declare support for navigation widgets markup.
add_theme_support( 'html5', array( 'navigation-widgets' ) );

// This can be combined with other HTML5 types if supported.
add_theme_support(
	'html5',
	array(
		'navigation-widgets',
		'comment-list',
		'comment-form',
		'search-form',
		'gallery',
		'caption',
		'style',
		'script'
	)
);

For reference, see the related documentation on DevHub.

As mentioned above, an aria-label will be generated for each widget based on the widget’s “Title” field. Below is a screenshot when aria-label attributes are not present to illustrate the problem for users utilizing a screen reader.

The screenshot above shows how the absence of aria-label attributes contributes to a poor experience when utilizing a screen reader. Props @afercia.

The screenshot below shows how the user’s experience is improved when by aria-label attributes.

The screenshot above shows how aria-label attributes helps users utilizing a screen reader to distinguish navigation elements from each other. Props @afercia.

Markup changes

Below is what the output markup looks like when support for navigation-widgets is not declared.

<!-- Without declaration for HTML5 `navigation-widgets` feature support -->
<div class="widget widget_archive">
	<div class="widget-content">
		<h2 class="widget-title">Archives</h2>
		<ul>
			<li><a href="mywebsite/2020/07/">July 2020</a></li>
			<li><a href="mywebsite/2019/12/">December 2019</a></li>
		</ul>
	</div>
</div>

Below is what the new output markup will look like when support for navigation-widgets is declared.

<!-- When the theme declares HTML5 `navigation-widgets` feature support -->
<div class="widget widget_archive">
	<div class="widget-content">
		<h2 class="widget-title">Archives</h2>
		<nav role="navigation" aria-label="Archives">
			<ul>
				<li><a href="mywebsite/2020/07/">July 2020</a></li>
				<li><a href="mywebsite/2019/12/">December 2019</a></li>
			</ul>
		</nav>
	</div>
</div>

Forcing navigation-widgets support

Support for HTML5 navigation-widgets feature can be forced on a site by using the new navigation_widgets_format filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. This hook determines the type of markup used in widgets that contain navigation links.

This filter accepts two different values: html5 and xhtml. Returning any other value to this filter will output the old markup without these accessibility improvements.

// Force HTML5 markup.
function mytheme_force_semantic_nav_widgets( $value ) {
	return 'html5';
}
add_filter( 'navigation_widgets_format', 'mytheme_force_semantic_nav_widgets');

// Force legacy markup.
function mytheme_force_legacy_nav_widgets( $value ) {
	return 'xhmtl';
}
add_filter( 'navigation_widgets_format', 'mytheme_force_legacy_nav_widgets');

For reference, see the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker.: #48170.

Props @whyisjake and @desrosj for proofreading.

#5-5, #accessibility, #dev-notes, #html5, #widgets

External Library updates in WordPress 5.5: call for testing

Edit 7/1/20: The post initially indicated that a minified version of Moment.js was now included in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. This was incorrect, a minified version has always been included, but as a direct copy from upstream. That copy now has a sourceMappingURL reference (which is not desired). For that reason, the library is now minified in the Core build process instead. That sentence was removed to prevent confusion. Props @sergeybiryukov for catching that.

Edit 7/2/20: After this note was published, new versions of the Moment.js and getID3 libraries were committed. The version updates for each have been adjusted appropriately.


WordPress 5.5 is currently slated to bring some long awaited updates to a handful of external libraries bundled with Core. A few of the updates are particularly large, and while backwards compatibility measures were taken, they could potentially require adjustments to plugins, themes, and custom code. For that reason, this developer note also doubles as a call for testing.

Please help test these library updates, and report back any bugs to help ensure that no edge cases were missed during the initial testing.

You can test these changes by installing the WordPress Beta Tester pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party (choose the “bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk. nightlies” option), or download the nightly package directly (regenerated from trunk daily).


Remember, running the nightly version of WordPress is not recommended for production environments. Consider setting up a local development environment to test instead.


A full list of External Library tickets can be found on Trac, but below are the library updates currently slated to ship with WordPress 5.5, including all of the details you need to be aware of. The libraries that require an extra keen attention to detail are marked “please test”.

PHPMailer (please test)

Because of conflicting PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher support policies (support for PHP < 5.5 in was dropped in newer versions of the PHPMailer library), WordPress Core has been stuck on the 5.x version of PHPMailer for quite some time, even though a newer, 6.x version exists. However, now that WordPress only officially supports PHP back to version 5.6.20, PHPMailer can finally be updated.

This is a major update to the library. Please help by testing this update to ensure any edge cases are discovered.

Plugins that appear to be utilizing the library will soon receive an email to test their code. Below is what you need to know about the changes as they relate to WordPress Core.

Note: this is not an exhaustive list. For a more complete list of changes, please consult the Upgrading from PHPMailer 5.2 to 6.0 guide.

New file locations

To make updating the library easier, the PHPMailer files have been moved into the wp-includes/PHPMailer directory. The old files will remain for backwards compatibility and load the new corresponding files, but loading them will now throw a _deprecated_file() warning.

  • wp-includes/class-phpmailer.php is replaced by wp-includes/PHPMailer/PHPMailer.php.
  • wp-includes/class-smtp.php is replaced by wp-includes/PHPMailer/SMTP.php.

Additionally, the phpmailerException class is now separated into its own file, wp-includes/PHPMailer/Exception.php (previously, it was included at the bottom of the class-phpmailer.php file). When loading the PHPMailer library, the Exception.php file is required, and should also be loaded. If the old class-phpmailer.php file is loaded, the exception class will be loaded automatically to minimize failures.

New PHPMailer namespace

In past versions, the PHPMailer class existed within the global space. However, moving forward, the PHPMailer library is under the new PHPMailer\PHPMailer namespace. Below is an example of the old usage, and an example of the new way to utilize the library.

Old method

<?php
require_once ABSPATH . WPINC . '/class-phpmailer.php;
$phpmailer_instance = new PHPMailer();

New methods

Both examples will produce identical results.

<?php
use PHPMailer\PHPMailer\PHPMailer;
require_once ABSPATH . WPINC . '/PHPMailer/PHPMailer.php;
require_once ABSPATH . WPINC . '/PHPMailer/Exception.php;
$phpmailer_instance = new PHPMailer();
<?php
require_once ABSPATH . WPINC . '/PHPMailer/PHPMailer.php;
require_once ABSPATH . WPINC . '/PHPMailer/Exception.php;
$phpmailer_instance = new PHPMailer\PHPMailer\PHPMailer();

Similar changes must also be made when utilizing the PHPMailer Exception class.

The old classes have been registered as aliases of the new, properly namespaced classes using class_alias() in PHP (this is true for the PHPMailer, phpmailerException and SMTP classes). This means that a plugin containing code similar to the “old method” will continue to work seamlessly until it can be updated (with the exception of the _deprecated_file() notice).

Note: the aliases will only exist if the old, deprecated files are included. A plugin relying on Core to load the PHPMailer library will not have an alias present as the new files are now loaded instead.

Deprecated elements have been removed

Another big change in the 6.x update was the removal of all deprecated properties and methods. A full list of removed elements can be found in the upgrade guide.

Plugins using PHPMailer

All plugins that appear to be utilizing PHPMailer will soon be receiving an email notification to test their code and make any necessary adjustments.


For more information, check out the full list of changes included with this update, the PHPMailer 6.0 upgrade guide, or the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets (#41750, #50379, #50380).

SimplePie (please test)

SimplePie is a RSS and Atom feed framework bundled with WordPress Core to handle the consumption of RSS and Atom feeds. The library has remained largely untouched for several years, but has been updated from version 1.3.1 to the latest version (1.5.5) for WordPress 5.5.

This update includes bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes, compatibility fixes for newer versions of PHP, added support for additional date formats, and minor improvements to ensure that feeds continue to be parsed correctly. Support for caching feed data to Redis and Memcached has also been added.

It is highly recommended that you test your code if your site fetches and processes RSS/Atom feeds.

Plugin authors were previously notified to test their code against the 1.5.5 update in early May, and the authors of plugins that were identified as using SimplePie should have received an additional follow up email. While no issues have been reported so far, it’s still possible that there may be undiscovered edge cases.

For more information, check out the full list of changes in SimplePie 1.3.1 to 1.5.5, or the related Trac ticketticket Created for both bug reports and feature development on the bug tracker. (#36669).

Twemoji

Earlier this year, the Unicode Consortium announced that Emoji v13.0 had been finalized. In addition to the 62 brand new emojis that were added, 55 gender and skin-tone variants were also added.

Platforms will begin rolling out native support later this year. But why wait? The Twemoji library has already been updated to support the new emojis, and that update will be included in WordPress 5.5.

So start spicing up your blogblog (versus network, site) about ninja (🥷) techniques, using tamales (🫔) and olives (🫒) on your food blog, and beavers (🦫) or polar bears (🐻‍❄️) on your wildlife blog.

For more information, check out the full list of new emojis added in Emoji v13.0, the Twemoji 13.0 release notes, or the corresponding ticket on Trac (#50148).

Masonry & imagesLoaded

The Masonry library has been updated from version v3.3.2 to 4.2.2, and the related imagesLoaded library has been updated from v3.2.0 to v4.1.4.

The biggest change in this update is the removal of support for IE versions 8 & 9. Core has not supported these versions of IE since WordPress 4.8, but if supporting these versions of Internet Explorer is important to your user base, please explore enqueuing your own versions of these libraries instead.

For more information, check out the full list of changes in Masonry, the full list of changes in imagesLoaded, or the related Trac ticket (#37675).

getID3

The getID3 library has been updated from version v1.9.18 to v1.9.20. This is a minor update that fixed several bugs. These fixes included one that caused a PHP notice when using PHP 7.4 and processing MP3 audio files.

For more information, check out the full list of changes in getID3 or the related Trac ticket (#49945).

Moment.js

The Moment.js library has been updated from version 2.22.2 to 2.27.0. For more information, check out the full list of changes in Moment.js, or the related Trac ticket (#50408).

clipboard.js

The clipboard.js library has been updated from version v2.0.4 to v2.0.6. For more information, check out the related Trac ticket (#50306).

Props @earnjam for technical review, @newyorkerlaura and @justinahinon for proof reading.

#5-5, #dev-notes, #external-libraries

Updating jQuery version shipped with WordPress

This has been a long time coming; the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #37110 is already few years old.

Following the recommendations of the jQuery team, the updating has to happen in stages:

  1. Remove jQuery Migrate 1.x. This is planned for WordPress 5.5.
  2. Update to the latest version of jQuery and add the latest jQuery Migrate. This is tentatively planned for WordPress 5.6 depending on test results. Updating to the latest jQuery UIUI User interface, version 1.12.1, is also planned for 5.6.
  3. Remove jQuery Migrate. This is tentatively planned for WordPress 5.7 or later, depending on testing.

As planned, a Test jQuery Updates pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party was released to make it easy to test different versions of jQuery, jQuery Migrate, and jQuery UI. Please install it and thoroughly test if everything works as expected, especially on the front-end, or at the settings pages of other WordPress plugins.

How to help with testing

The plugin has a settings screen found under the Plugins menu in WordPress adminadmin (and super admin). Different versions of the jQuery libraries can be selected there for testing. Please test by:

  1. Disabling jQuery Migrate, and leaving jQuery and jQuery UI at the default versions (for WordPress 5.5).
  2. Selecting jQuery 3.5.1, enabling jQuery Migrate, and selecting jQuery UI 1.12.1 (for WordPress 5.6).
Test jQuery Updates settings screen, under the Plugins menu.

Updating your code

To get ready for this jQuery update, it’s important that you update your code. The migrate plugin will assist you in identifying issues. Additionally, the jQuery Core 3.0 Upgrade Guide and 3.5 Upgrade Guide provide detailed information about what has changed. As the browser supported list is also updated, this is also a great time for you to revisit what versions of browsers are supported by your themes and plugins.

See a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?

If you find a bug in Test jQuery Updates, or if you run into a jQuery related issue, please report it at https://github.com/WordPress/wp-jquery-update-test. If the issue is with a default script in WordPress, please open a new ticket on Trac.

Thanks @andreamiddleton, @annezazu, and @jorbin for helping with this post.

#5-5, #jquery

#dev-notes

WordPress 5.5: Better fine grained control of redirect_guess_404_permalink()

Since WordPress 2.3.0, the redirect_guess_404_permalink() function has existed to attempt guessing the desired URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org based on the query variables available. This is especially useful when a post’s parent changes (for hierarchical post types), or a post’s slug is changed.

Guessing a URL to redirect 404 requests is fine for the majority of WordPress sites, but site owners, developers, and pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors may want more fine grained control over the guessing logic.

This is a long-standing issue, as the original ticketticket Created for both bug reports and feature development on the bug tracker. was opened 9 years ago. So long, WordPress 5.5 will add the ability to manage that feature properly.

Short-circuiting default guessing logic

The new pre_redirect_guess_404_permalink filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. can now be used to short-circuit the function, bypassing the default guessing logic. This is useful to execute custom logic that better fits each individual site’s needs to make a more accurate guesses.

Returning a non-false value to the filter will cause the function to return the filtered value early.

Example

function mysite_pre_redirect_guess_404_permalink() {
    // Custom redirect URL guessing logic.
   return $new_redirect_url;
}
add_filter( 'pre_redirect_guess_404_permalink', 'mysite_pre_redirect_guess_404_permalink' );

Controlling “strict” vs. “loose” comparison

The strict_redirect_guess_404_permalink can now be used to filter whether a “strict” or “loose” comparison is used to make a redirect URL guess.

“Strict” comparisons (true) will make a guess suggestion for a redirect only when exact post_name matches are found.

“Loose” comparisons (false) is the default option and will perform a LIKE query on post_name.

Example

The following example will enable “strict” comparisons in redirect_guess_404_permalink():

add_filter( 'strict_redirect_guess_404_permalink', '__return_true' );

Disable 404 redirect guessing

The do_redirect_guess_404_permalink filter can now be used to completely disable redirect guessing. Returning false to the filter will disable the feature entirely.

Example

add_filter( 'do_redirect_guess_404_permalink', '__return_false' );

For more information on these changes, consult the related TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket: #16557.

#5-5, #dev-notes, #permalinks