Summary

Fixes #2673.
Fixes #4480.
See #2069.

To accompany the “technical user” question in the onboarding wizard, there is now a Developer Tools preference on the user edit screen:

This checkbox is only presented to users who can manage_options. Actually, the checkbox is presented to users who can amp_validate, a new meta capability that is mapped to the manage_options primitive capability by default. This allows a site to customize which users can access developer tools, but by default it is limited to administrators (whereas currently it is anyone who can edit_posts).

As opposed to the DevTools toggle being null by default, it is now true by default. Admins can turn it off if they don't want it. The first time the wizard is entered, it does not consider the current user's preferences so it will ask whether they are technical without auto-selecting one option.

When an administrator has DevTools turned off, then the admin menu items for Validated URLs and Validation Errors do not appear:

Before	After

They are also hidden in the At a Glance widget on the Dashboard:

Before	After

And the admin bar simply shows a link back to the non-AMP version, with no Validate link, CSS usage info, or paired browsing (aside: the link text is not entirely intuitive here):

Before	After

Nevertheless, even though an administrator has turned off DevTools, they can still access them manually by going to /wp-admin/edit.php?post_type=amp_validated_url. All the screens then show up in the admin menu. This will be critical for allowing administrators to access the validation screens in response to the Site Health test proposed in #1756 (comment).

Naturally, when Developer Tools are turned off, no validation warning messages will appear in the editor. Additionally, no synchronous validation is performed during saving. (Scheduling a job to validate an edit to a published post needs to be done as part of #1756.) This will address the slowness of synchronous loopback requests (#2069) for non-administrators and admins with DevTools turned off.

Additionally, loopback requests to perform validation are also no longer performed when activating a new plugin if the user has DevTools turned off.

Lastly, when DevTools are enabled they will also now apply in Reader mode for the first time.

As part of this, the admin bar is now also shown in the Reader mode template. Please note that in order to support scripts that are added for the admin bar, this PR introduces wp_print_head_scripts() at amp_post_template_head and wp_print_footer_scripts() at amp_post_template_footer. Nevertheless, wp_enqueue_scripts() is not called so it's up to plugins that want to extend the sidebar in legacy Reader mode to enqueue the scripts at the admin_bar_init action.

While Developer Tools are restricted to administrator users who can amp_validate which is mapped to manage_options by default, this can be overridden for example to let editors access dev tools via code like this:

add_filter(
	'map_meta_cap',
	function ( $caps, $cap, $user_id ) {
		if ( 'amp_validate' === $cap && user_can( $user_id, 'edit_others_posts' ) ) {
			$position = array_search( $cap, $caps, true );
			if ( false !== $position ) {
				$caps[ $position ] = 'edit_others_posts';
			}
		}
		return $caps;
	},
	10,
	3
);

That then moves the DevTools to the top-level menu item:

Todo

• Add more tests.

Checklist

• My pull request is addressing an open issue (please create one otherwise).
• My code is tested and passes existing tests.
• My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).