Site-kit-wp: "Notice: amp_is_available was called incorrectly" raised on wp-admin/main/repair.php

[netnaps]

Bug Description

Currently Site Kit raises the following PHP notice when the plugin is active with the AMP plugin:

Notice: amp_is_available was called incorrectly. amp_is_available() (or amp_is_request(), formerly is_amp_endpoint()) was called too early and so it will not work properly. WordPress is currently doing the "style_loader_tag" action. Calling this function before the "wp" action means it will not have access to WP_Query and the queried object to determine if it is an AMP response, thus neither the "amp_skip_post()" filter nor the AMP enabled toggle will be considered. Please see Debugging in WordPress for more information. (This message was added in version 2.0.0.) in /var/www/netnaps.com/wp-includes/functions.php on line 5225

Because this is a special non-standard page load, the wp action is never run which causes this notice to be triggered when Context->is_amp() is called via our callback on the style_loader_tag hook.

Steps to reproduce

1) Can be seen at wp-admin/maint/repair.php page only
2) If the Debug is enabled
3) Have made a screencast of the same.

Screenshots

https://youtu.be/8v14QteD5QI

opened this with WordPress

---

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

Acceptance criteria

• Site Kit should not load its core functionality on the special wp-admin/maint/repair.php page

Implementation Brief

• In the main google-site-kit.php plugin entry point file, if defined( 'WP_REPAIRING' ) && WP_REPAIRING, don't load the includes/loader.php file to bootstrap the plugin.

QA Brief

Changelog entry

[jamesozzie]

@netnaps Thanks for providing the info, very useful recording.

@felixarntz @aaemnnosttv It looks like we may be calling is_amp_endpoint as a callback of style loader tag.

Would you be able to take a look?

[aaemnnosttv]

I was able to reproduce this, but I believe this is a side-effect of the maint/repair.php page which is a non-standard page load. Under normal circumstances, the wp action would have run by the time HTML (and thus style tags) are being output so this a bit of an edge case. The solution here I think is to simply not load the plugin when WP_REPAIRING is true.

I'll update the issue here and forward this along for further definition.

[westonruter]

Wow! What a throughly helpful recording!

Actually I'm also shocked because in all my years of using WordPress I've never seen this maint/repair.php screen before!

Now I can see this is actually a bug with the AMP plugin. I'll open a PR to fix.

[netnaps]

@westonruter actually I even couldn't have noticed this anywhere other than repair.php page, I made a tutorial on my blog that made me use this repair page for taking screenshots.
Thanks Again

[westonruter]

Opened PR to fix: https://github.com/ampproject/amp-wp/pull/5362

[aaemnnosttv]

@westonruter did you intend to close this issue by reference?

[westonruter]

It can be closed yes.