Feature description

In #4795 for theme compatibility scanning, we need a way to determine whether we can recommend a user to select a separate Reader theme in Reader template mode:

There's one big caveat here for recommending Reader mode, and specifically a Reader theme. In particular, it may not be advisable if the active theme is violating a best practice of registering post types, taxonomies, post types, blocks, and widgets in plugins rather than in theme. If the active theme is registering a post type, for example, and a Reader theme is selected, then this post type will be absent entirely.

We need a way to determine if the theme is registering any such entities before we can recommend this.

In the same way, for plugin compatibility scanning (#4719), we may recommend to the user that they suppress certain plugins when using a paired AMP mode. However, if this involves suppressing a plugin that registers an important post type, block, or shortcode, then this would be bad as it could break their site content. (In particular, if a plugin is suppressed then we should at the same time automatically disable AMP for whatever post types it registers.)

In #5751 there was an initial exploration for how to detect the entities that are registered by themes. It takes the approach of gathering the list of all entities registered on the site when the theme is active, and then subtracts that list of entities in another request when the theme is deactivated. This works, but it lacks the identification of plugin-specific entities. In order to detect those, it's not feasible to try suppressing plugins one-by-one to find out what entities are present/absent since certain plugins may have dependencies on other plugins.

Therefore, I propose a different approach to identifying the theme/plugins responsible for the various registered entities, and it closely relates to the existing CallbackReflection logic that we're already using in the PluginSuppression and AMP_Validation_Manager. During a validation request, we hook into the all action to add wrappers around each registered filter/action and run logic before/after to detect when a callback has registered something (e.g. scripts and styles) by comparing what was registered before with what was registered after. When a change is detected, the CallbackReflection logic can obtain the source for the callback—the theme or the plugin. This same approach we can use to determine which theme/plugin is responsible for registering the various entities (again, post types, shortcodes, blocks, etc).

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

Acceptance criteria

Implementation brief

1. Create a new service called EntityRegistrantDetection.
2. In the same way that the validation manager has an amp_validate nonce, this endpoint requires that a amp_entity_registrant_detection_nonce query parameter to be provided. Refer to AMP_Validation_Manager::get_amp_validate_nonce() for how to generate this nonce (without authentication) and AMP_Validation_Manager::should_validate_response() for validation.
3. The service needs to be registered as early as possible to start watching for entity registrations, so make sure it starts at plugins_loaded.
4. The service's logic to start listening for registrations must check if isset($_GET['amp_entity_registrant_detection_nonce']), and then proceed only if hash_equals() the current nonce. (Or come to think of it, maybe wp_verify_nonce() should be used instead.)
5. If the nonce has been validated, then add the all action as seen in AMP_Validation_Manager::add_validation_error_sourcing() with a callback like AMP_Validation_Manager::wrap_hook_callbacks() which wrapps all added callbacks with an invokableArrayAccess class like AMP_Validation_Callback_Wrapper() which is responsible for capturing the diff of the registered entities during the callback's invocation.
6. The service will expose a new REST API endpoint for /wp-json/amp/v1/entity-registrants/ which requires manage_options permission. This endpoint will first check to see if a valid nonce was provided, and if not it will return with an error (as otherwise the listener would not have gathered any entity registrations). If a valid nonce was provided, then provide the results that were gathered during finalization of the wrapped hook callback.

QA testing instructions

Demo

Changelog entry