Feature description

Every time a post is saved in the editor, the AMP plugin performs a loopback request to that post's permalink on the frontend to then check it for validation errors. In the block editor, this loopback request is doing during the handling of the PUT request; this is done so that the PUT response can include all of the validation error data, but it also means that the PUT request takes much longer then it would normally.

In the classic editor this loopback request is performed when the the whole page is reloading after saving, and it is also done when activating a new plugin and switching between template modes. The loopback requests here also slow down the page load time, but with the benefit being the validation results can be easily displayed immediately in the page response.

Nevertheless, it would be much better to switch to doing asynchronous loopback requests. When updating a post in the block editor, a successful PUT request should then trigger another request to a new REST API endpoint dedicated to URL validation. So clicking the Save button would then kick off a new loading message and spinner that could say, “Checking AMP validity”. When this returns, any AMP validation messages would be added/removed in the block interface.

Similarly, when activating a new plugin, this loopback request should be performed via Ajax on the plugin screen; an admin notice can be added which contains, “Re-checking AMP validity…” with the notice then updated to he success or error based on the result.

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

Acceptance criteria

• Switch to asynchronous loopback requests
• When updating a post in the block editor, a successful PUT request should trigger another request to a new REST API endpoint dedicated to URL validation.
• Clicking the Save button should kick off a new loading message and spinner that could say, “Checking AMP validity”.
  • When this returns, any AMP validation messages should be added/removed in the block interface.

Implementation brief

• Consider adding a new amp_uuid block attribute for all blocks which persists across page loads. This must be a UUID that remains unique even after duplicating a block. If such a UUID were in place, then it would be possible to store the amp_uuid with the block attributes in the validation error, and this could then be used to connect a validation error to the corresponding block in the editor.

QA testing instructions

Demo

Changelog entry