Robots API and max-image-preview directive in WordPress 5.7

WordPress 5.7 introduces a 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.-based Robots APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., providing central control over the robots 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. 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.). It furthermore adds a max-image-preview:large directive to the tag by default.

The robots meta tag lets you utilize a granular, page-specific approach to controlling how an individual page should be indexed and served to users in search engine results. This meta tag is commonly placed in the <head> section of a given page:

<!DOCTYPE html>
<html>
	<head>
		<meta name="robots" content="max-image-preview:large" />
	</head>

The max-image-preview:large directive allows search engines to display large image previews for the site resulting in an enhanced user experience. The directive is now added by default to sites that wish to be indexed by search engines.

wp_robots() new function

WP 5.7 introduces a wp_robots() function which outputs a robots meta tag. The function is automatically integrated with the relevant areas in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., for example it is added to wp_head so that the robots meta tag is available in the frontend. Plugins and themes should not typically call this function manually; for special cases though, e.g. a custom frontend template that does not use wp_head(), the new function can be hooked into a custom filter:

add_action( 'my_custom_template_head', 'wp_robots' );

How to hook into the Robots API

The robots meta tag attributes can be filtered using the wp_robots hook. The wp_robots() function is entirely filter-based, so if no filter is added to wp_robots, no directives will be present, and therefore the entire robots meta tag will be omitted.

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 developers that add their own robots meta tags are encouraged to switch to using the new Robots API, hooking their custom directives into the wp_robots filter.

Default robots meta tag values

As mentioned above, the robots meta tag is now included by default in wp_head as follows for WordPress sites that wish to be indexed by search engines:

<meta name="robots" content="max-image-preview:large" />

Developers can disable this directive using the following PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher snippet:

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

The Robots API is also used to generate robots meta tags on some specific screens, with the following values:

  • When the “Discourage search engines from indexing this site” setting is enabled, the front end includes a noindex,nofollow directive in the Robots meta tag, as in previous versions. In this case, the max-image-preview:large directive is not added.
  • Within the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. preview, the site includes a noindex directive in the Robots meta tag, as in previous versions.
  • The WordPress login page (wp-activate.php) includes a noindex,noarchive directive in the Robots meta tag, as well as a <meta name="referrer" content="strict-origin-when-cross-origin" /> tag, as in previous versions.
  • In multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, the site activation page (wp-activate.php), where a newly registered user can confirm their newly created site, includes a noindex,noarchive directive in the Robots meta tag, as well as a <meta name="referrer" content="strict-origin-when-cross-origin" /> tag, as in previous versions.

Add custom values to robots meta tag

The wp_robots filter takes an array of key-value pairs. To add custom values to the robots meta tag, use the following filter:

function wporg_wp_robots_add_follow( $robots ) {
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'wporg_wp_robots_add_follow' );

It will add the follow value in addition to any existing values. Given the max-image-preview:large is already added by default, this snippet will generate the following:

<meta name="robots" content="max-image-preview:large, follow" />

It’s also possible to unset existing values:

function wporg_wp_robots_add_follow( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'wporg_wp_robots_add_follow' );

Deprecated functions

The new Robots API controlled via the wp_robots filter replaces various separately injected robots meta tags that WordPress core used to conditionally provide. As such, the following functions have been deprecated and should no longer be used:

  • noindex(); instead, the new wp_robots_noindex() function can be hooked into the wp_robots filter.
  • wp_no_robots(); instead, the new wp_robots_no_robots() function can be hooked into the wp_robots filter.
  • wp_sensitive_page_meta(); this function placed two tags, so it has two separate replacements:
    • For the noindex,noarchive robots directive, the new wp_robots_sensitive_page() function can be hooked into the wp_robots filter.
    • For the extra referrer tag, the new wp_strict_cross_origin_referrer() function can be called.

For reference, see 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. #51511

Props to @davidbaumwald, @flixos90, and @tweetythierry for proofreading

#5-7, #dev-notes

Feature Plugin: Rollback Update Failure

This feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. is an offshoot of Matt’s 9 Projects for 2019. Specifically it’s a follow-up to auto-updates for plugins and themes. Our goal is to provide a safety mechanism of sorts should an update, including auto-updates, fail potentially leaving the user’s site in an unstable state.

This is a feature plugin based on the PR for #51857. We are working towards inclusion in WordPress 5.8. The general overview is to provide a mechanism whereby a failed 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 or theme update does not leave the site in an unstable state. This part of the project is not about ensuring that a successful update does not cause any issues.

Some of the issues of failed updates include:

  • Having a plugin folder content be deleted and the plugin no longer active.
  • Having a plugin not completely update and result in a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher fatal message or WSOD

While these are not the only results of failed updates, they seem to consistute the majority of reported issues.

The assumption is that most of the errors in large plugins/themes occur during the copy_dir() part of WP_Upgrader::install_package(). 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. #52342 brought more error reporting to copy_dir() and Trac ticket #52831 provides a 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. hook in order to process the rollback in the event of a plugin/theme update failure. As of WordPress 5.7-beta1 both of these tickets are in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

It is during the WP_Upgrader::install_package() that the currently installed plugin/theme is deleted in anticipation of copying the new update into that location. Having an empty plugin/theme folder or an incompletely copied update seems to be the most common issue.

Rollback Update Failure Feature Plugin is available for feedback and testing. Contributions from the WordPress community are welcome on the plugin’s GitHub repository.

Testing

There was much discussion regarding the thought that adding additional IO processes for the zip and unzip process could result in server timeout issues on resource starved shared hosts. Activating the feature plugin will result in the creation of a ZIP file of the installed plugin/theme being updated every time an update is performed. The unzip only occurs during testing or if a WP_Error is returned from WP_Upgrader::install_package(). Any issues would only happen during a plugin or theme update.

For the sake of testing assume any server timeout occurring during the update process might be releated to the additional IO processes creating the zipfile. Please report these in GitHub Issues and report your server details. ( Host, RAM, OS, etc. )

There will be messaging in the event of an error and successful or unsuccessful rollback.

To simulate a failure, use the filter add_filter( 'rollback_update_testing', '__return_true' );

Alternatively you can install the Rollback Update Testing plugin, activating it as needed. If you have GitHub Updater installed, you can easily install this Gist from the Install Plugin tab. Select Gist as the Remote Repository Host.

Next Steps

The Rollback Update Failure feature plugin is an early step towards inclusion in WordPress Core. We need your help. Simply installing and activating the plugin will help test whether or not the additional server IO processes may cause issue with resource starved shared hosting.

Thanks @audrasjb for reviewing.

#rollback

Lazy-loading iframes in 5.7

In WordPress 5.7, iframes will be lazy-loaded by default, using the browser-level loading attribute. This will bring to iframes the same performance benefits which WordPress 5.5 introduced by lazy-loading images.

Similar to how it affects images, WordPress will add loading="lazy" to only those iframe tags that have both width and height attributes present, to avoid any perceived negative impact on layout shifting. The attribute is added on page output using the wp_filter_content_tags() function which was introduced in WordPress 5.5 with specifically that extensibility in mind which now allows reusing it for this new performance feature. Since the considerations of lazy-loading iframes are similar to those of lazy-loading images, please refer to the original image lazy-loading announcement post as well as this article on browser-level lazy-loading for background information on the topic.

See also #50756 for the ticketticket Created for both bug reports and feature development on the bug tracker. where this feature was worked on.

Impact on oEmbed content

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

  • iframes within post content (the_content)
  • iframes within post excerpts (the_excerpt)
  • iframes within text widgets (widget_text_content)

The majority of iframes used on WordPress sites typically come from its oEmbed integration, which will automatically transform a URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to certain web platform resources (such as tweets or YouTube videos) into the referenced embedded media when pasted into the editor.

The markup of those iframe tags is controlled by the respective web service, and only some of those web services follow the best practice of providing width and height attribute. Since WordPress cannot guess the dimensions of the embedded resource, the loading="lazy" attribute will only be added if the oEmbed iframe 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.) comes with both dimension attributes present.

Customizing lazy-loading iframes

Developers can customize whether and how iframes are lazy-loaded in a similar way to how they can for images, with the primary 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. being the existing wp_lazy_loading_enabled, which going forward will return true for iframe tags by default.

For example, if you would like to turn off lazy-loading by default for iframes within post content, you could use the following code snippet:

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

In addition, there is a new wp_iframe_tag_add_loading_attr filter which allows customization of a specific iframe tag. For example, you could use this filter to skip addition of the loading attribute on an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. that will likely appear within the initially visible viewport, to avoid impacting the Largest Contentful Paint metric. The filter has the same signature as the related wp_img_tag_add_loading_attr filter for images.

Here is an example code snippet which would disable lazy-loading iframes that embed YouTube videos within post content:

function skip_loading_lazy_youtube_iframes( $value, $iframe, $context ) {
	if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) ) {
		return false;
	}
	return $value;
}
add_filter(
	'wp_iframe_tag_add_loading_attr',
	'skip_loading_lazy_youtube_iframes',
	10,
	3
);

Please refer to the “Customizing lazy-loading” section of the image lazy-loading announcement post for additional guidance.

Props @audrasjb for proofreading.

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

Hallway Hangout: Fool me once — Writing end-to-end tests against regressions

On Thursday, I hosted a little walkthrough on how to write a simple end-to-end test to make sure a specific piece of editor functionality that had broken in the past wouldn’t break again.

As GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ grows, the project sometimes experiences regressions: Features that used to work suddenly don’t anymore. In order to prevent these regressions from happening, contributors can write end-to-end (e2e) tests that cover a given piece of functionality and alert us when that functionality is broken. Combined with a Continuous Integration system such as GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions, this is a very powerful tool, since it can notify a PR author that their PR might break something before they even merge that PR.

I’ve recently tried to keep more track of such regressions, and have started filing issues requesting e2e tests to cover them. In the hangout, I’ve picked one of these issues and demonstrated how to write an e2e test for it.

Continue reading

#core-editor, #e2e-tests, #gutenberg, #hallwayhangout

CSS Chat Summary: 18 February 2021

The meeting took place here on Slack. @notlaura facilitated and @danfarrow wrote up these notes.

Housekeeping

  • @ryelle volunteered to run next week’s 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. scrub (Thursday 25 February @ 21:00 UTC) – thanks @ryelle!

Discussion: Deprecation flow for base styles

  • Last week’s bug scrub brought up this Gutenberg issue about an SCSS variable that was removed from the wordpress/base-styles npm package
  • The issue asks if a deprecation policy & notice period exists, or should exist, for SCSS variables, since they may be used by developers in contexts other than coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
  • After some discussion @ryelle suggested the #core-editor meeting might be better equipped to delve into this issue
  • @notlaura offered to bring this up at the next #core-editor meeting (Wednesday 24 February @ 14:00 UTC)

Updates

Color Scheming (#49999)

CSSCSS Cascading Style Sheets. Audit (#49582)

Visual 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. testing (#49606)

Open Floor + CSS Link Share

With that the meeting drew to a close.

Thanks everyone!

#core-css, #summary

X-post: A home and a name for Site Editor Documentation (Full Site Editing Feature)

X-comment from +make.wordpress.org/docs: Comment on A home and a name for Site Editor Documentation (Full Site Editing Feature)

Test scrub for WordPress 5.7 Beta 3 and office hours

As part of the 5.7 release, we’ll be hosting a  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. 3 focused test scrub on February 19, 2021 13:30 UTC in the #core channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

In particular, we will focus on user testing and highlighted tickets to ensure there are no regressions.

Please join us and share your valuable feedback.

You can read more about Beta 3 on its announcement post.
https://wordpress.org/news/2021/02/wordpress-5-7-beta-3/

What you need
– Test website
– WordPress 5.7 Beta 3:
– Try the WordPress Beta Tester plugin (choose the “Bleeding edgebleeding edge The latest revision of the software, generally in development and often unstable. Also known as trunk.” channel and Beta/RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). Only” stream options)
– Or download the Beta 3 here (zip).

Looking forward to testing with you!

#test#testing