Refactor conditional checks in is_amp_endpoint() and improve guidance when _doing_it_wrong()

[hansschuijff]

Moved checking against is_embed() and is_feed() after
checking if parse_query has run and $wp_query has been filled, since
both these functions will fire _doing_it_wrong when $wp_query
is not yet set.

Summary

Fixes #4525

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).

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[schlessera]

Thanks so much for the pull request @hansschuijff !

There's a code style issue right now that prevents the actual tests from running. See my review comment on how to fix it.

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[schlessera]

@hansschuijff It looks like there's no obvious way right now to add a regression test for the above fix. I've opened an issue to that regard: #4576

[westonruter]

I just realized that REST_REQUEST maybe being checked too early here. It is defined in the rest_api_loaded() function which is called at the parse_request action. So perhaps we need to add another check for whether the parse_request action was done.

[hansschuijff]

If I understand it correctly, that seems to not lead to problems, since than REST_REQUEST just won't be defined and it will pass through the conditional and just fire _doing_it_wrong until the parse_request action is performed and the $wp_query is filled. Is_embed and is_feed just needed to move since otherwise the error reported had no obvious relation with is_amp_endpoint. It might be right to let the function report an error anyway if the function is called too early in the process, so that the plugin developers get to see where what they did wrong?

[westonruter]

I think the issue is just that during REST API requests, the wp action is never triggered so it's somewhat misleading. In order to check the constant we need to check if the parse_request action was fired, or else it's not good to check this constant since it will never be defined. I'm going to push up a change to this to account for this and you can see what I mean.

[westonruter]

OK, I've rearranged the checks in 0bdf639 which I think will produce better results. This change will also ensure that a call to is_amp_endpoint() won't cause a warning in addition to warnings about calling is_embed() and is_feed().

[westonruter]

One more thing that comes to mind to improve this is to look at the call stack to find out which theme/plugin is actually responsible for calling is_amp_endpoint() prematurely. While this is out of scope of this PR, it's something that we can either add here or look at in another PR.

[schlessera]

Early bails should be preferred over if/else constructs. This is easier to reason about and keeps the level of indentation down.

Suggested change

	if ( current_theme_supports( AMP_Theme_Support::SLUG ) ) {
	$availability = AMP_Theme_Support::get_template_availability( $wp_query );
	$supported = $availability['supported'];
	} else {
	$queried_object = get_queried_object();
	$supported = ( $wp_query->is_singular() || $wp_query->is_posts_page ) && $queried_object instanceof WP_Post && post_supports_amp( $queried_object );
	}
	if ( current_theme_supports( AMP_Theme_Support::SLUG ) ) {
	$availability = AMP_Theme_Support::get_template_availability( $wp_query );
	return $availability['supported'];
	}
	$queried_object = get_queried_object();
	return ( $wp_query->is_singular() || $wp_query->is_posts_page ) && $queried_object instanceof WP_Post && post_supports_amp( $queried_object );

[schlessera]

I can't provide a suggestion for the rest of this piece of code, as suggestions don't seem to work across deleted lines.
But the change should basically be from this:

if () {
	if () {
		$supported = ...
	else {
		$supported = ...
	}
} else {
	$supported = ...
}
return $supported;

...to this:

if () {
	if () {
		return ...;
	}
	return ...;
}
return ...;

[westonruter]

Addressed in 751c645

[schlessera]

Why is code coverage being ignored here? This would warrant an explanatory comment.

[westonruter]

Because exit cannot be tested.

[westonruter]

@hansschuijff Sorry for increasing the scope of the PR so greatly. Your original change was very needed, and then it identified a whole bunch of other improvements that also needed to be made.

[hansschuijff]

@westonruter No worries. I'm glad I could help, even if it was just in a small way. Seeing you guys work is educational too and having done my first pr. Sometimes just initiating something is enough and glad it inspired to enhance amp even more.

Feedback addressed