Theme/plugin responsible for prematurely calling is_amp_endpoint() should be identified

[westonruter]

Feature description

A very common issue for themes and plugins integrating with the AMP plugin is calling is_amp_endpoint() before the wp action, for example:

• Jetpack: AMP: Jetpack now always hides the admin bar Automattic/jetpack#15353
• LightSpeed Cache: https://wordpress.org/support/topic/amp-not-working-with-litespeed/
• Schema & Structured Data for WP & AMP: https://wordpress.org/support/topic/notice-is_amp_endpoint-was-called-incorrectly-3/

Often users think that the AMP plugin is at fault because they only see the issue being emitted from the AMP plugin. In reality the issue is with another theme/plugin, but the other theme/plugin is not being identified. In #4574 (comment) I proposed:

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.

This would be really helpful for users trying to find out who to contact about the problem. We can make use of the same logic used to identify a theme/plugin for the validation error source stacks here. At the moment, this logic is contained in \AMP_Validation_Manager::get_source( $callback ). If we can grab all the functions from the callstack via debug_backtrace() and then obtain the function from each and obtain the source, we can then list the theme/plugin in the message that is emitted by _doing_it_wrong.

Note that this should probably only be done when WP_DEBUG is enabled.

If the admin bar is being displayed (and WP_DEBUG is not enabled) perhaps the issue should be called out as a warning under the AMP admin menu item. And if there, should the issue also be called out on the Validated URL screen? This gets into some new territory for the Validation screens, namely in the beginning they were limited to showing AMP validation errors. However, then they added Stylesheet information. I've also proposed that fatal errors occurring during validation should be exposed (#4580). What about incorrect usage issues or other problems with AMP content? The AMP validator itself has two classes of issues: errors and warnings. Invalid JSON is actually a warning and not an error (see #4430). Should those there be a section on the validated URL screen for warnings, including things like invalid JSON, calling is_amp_endpoint incorrectly, and fatal errors?

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• When a theme or plugin calls is_amp_endpoint() (and friends) too early, any notice that is displayed should identify that theme or plugin as the culprit.

Implementation brief

• Use debug_backgrace() to obtain the first call stack entry outside the AMP plugin to identify who called the function.

QA testing instructions

Demo

Changelog entry

[westonruter]

QA Passed. ✅

Must-Use Plugin

<?php
/**
 * Plugin Name: Must use calling is_amp_endpoint() early
 */
add_action( 'init', function () {
	is_amp_endpoint();
} );

Plugin

<?php
/**
 * Plugin Name: Call is_amp_endpoint() early
 */
add_action( 'init', function () {
	is_amp_endpoint();
} );

Theme

Adding this code to Twenty Twenty:

add_action( 'init', function () {
	is_amp_endpoint();
} );