Add Speculation Rules settings and UI

[felixarntz]

Summary

Fixes #906

Relevant technical choices

• Setting uses an associative array, to avoid using multiple options in the database.
• UI to control the settings is added to Settings > Reading.
• See the spec for additional context on the available choices.
• Test coverage is included.
• Includes Fix new WPCS violation after trunk refresh #937, just to prevent irrelevant lint failure.

Checklist

• PR has either [Focus] or Infrastructure label.
• PR has a [Type] label.
• PR has a milestone or the no milestone label.

[jeremyroman]

if any change is made above it should be reflected here

[felixarntz]

Is there a good way for me to stay in the loop on this? If not, it would be great if you could ping me should there be related discussions.

[jeremyroman]

There's an internal mailing list where Chrome stuff spanning this area is discussed, and sometimes that includes status updates (though it also has other discussion that may be noise to you). I'm in the process of refreshing an evergreen status doc, too. I'll try to remember to send it to you when done.

[westonruter]

Almost there!

[westonruter]

While unlikely, couldn't it be that perhaps $option['mode'] isn't set here? If someone put an array into the plsr_speculation_rules without setting that key, then either $option['mode'] or $option['eagerness'] may not be set. So for extra defensive coding, I think this would be even more robust:

Suggested change

	$option = get_option( 'plsr_speculation_rules' );
	if ( ! $option ) {
	$option = plsr_get_setting_default();
	}
	$mode = $option['mode'];
	$eagerness = $option['eagerness'];
	$option = get_option( 'plsr_speculation_rules' );
	if ( ! is_array( $option ) ) {
	$option = array();
	}
	$option = array_merge( plsr_get_setting_default(), $option );
	$mode = $option['mode'];
	$eagerness = $option['eagerness'];

[felixarntz]

This is extremely unlikely as in the scenario you're describing the value would still always be sanitized at the lowest level (within update_option()) to include both values, per the setting registration.

Still, fair enough to do this from a defensive coding perspective. Updated in d490f93

[westonruter]

Not sure if my suggestion here is warranted as I don't recall how this argument is even used versus what is passed to plsr_render_settings_field()

Suggested change

	$args['title'],
	esc_html( $args['title'] ),

[felixarntz]

I don't think that's needed, as the output of this is handled by core and thus responsibility of core. This isn't something WPCS complains about, so I don't think it's needed here.

[adamsilverstein]

I tested this in Chrome Canary and verified the speculation rules are working.

Checking the page source, I see the json object:

Also, I noticed the plugin generator tag includes the js-and-css/speculation-rules string.

Checking DevTools -> Application->Speculative Loads->Speculations I can see that all of the links on my (local test) homepage are included. When I hover over a link, I see that the prerender is triggered and the "Ready":

Finally, even on my local machine clicking these prerendered links is notably faster!

[adamsilverstein]

Fantastic!

[adamsilverstein]

Not sure what this message is about, I only added my review and I still see them as reviewers so 🤷🏼