Amp-wp: Redesign Validation Screens (Developer Tools)

[westonruter]

The admin screens for the Validated URLs and the Validation Errors are implemented in a classic WordPress way™, using post list tables and other traditional admin hooks. The end result is that much of the operations require full page loads, and the interfaces are dated. The UI needs to be revamped using modern WordPress interfaces pioneered with Gutenberg (e.g. using React). In the same way, we should eliminate synchronous validation as much as possible: https://github.com/ampproject/amp-wp/issues/2069.

Additionally, more of the management of the validation errors should be surfaced inside of the validation error notices on the edit post screen. Instead of merely indicating the number of validation errors as well as the invalid markup with each block, there should be a way to access full error details and source information from the editor itself; authors should just be able to remove the block (#2285) and/or escalate the validation error to an administrator. Non-administrators should not be able to change the validation error state, and they should not be able to access the compatibility tool screens. In short, redesigning the compatibility tool screens should involve components which can be re-used in the context of the validation warning notices.

As part of this, the site validation functionality needs to be fully implemented in the REST API. Currently we have a bare minimum implemented for Gutenberg integration, the read-only amp_validity field added to the post entity. In addition to that, there needs to be endpoints for:

• Listing all validated URLs.
• Requesting a URL to be validated.
• Listing the validation errors for a given URL.
• Listing validation errors.
• Listing URLs containing a given validation error.
• Changing the validation status for one or more errors.

[amedina]

• Allowing for advance information and options to be hidden (toggled), similarly to how advanced settings are dealt with in Chrome.

[amedina]

• Revise and improve all messages/copy in the plugin
• Change language from "Accepted" and "Rejected" to reflect the status of the error rather than the action taken by the user: i.e. "Markup Removed" and "Markup not Removed" (this will align the debugging workflow and language with the Sanitization aspects/approaches). See #2023.
• Redesign information exposure approach (i.e. expose baseline information, and make more complex/advance information accessible on demand)

/cc @pbakaus

[pbakaus]

OMG I'm so excited!

[amedina]

• Enable contextual strict mode, where users on non-admin roles (e.g. editors, authors, contributors) would not have access to the compatibility tool and will not be allowed to control the transition status of plugin actions (e.g. can’t change a validation error action from “Accepted” to “Rejected”. See #2673.

[amedina]

• Provide programmatic access to hide compatibility tool

[westonruter]

Something else to consider for this is to integrate the compatibility tool into the admin bar. In #3365 there is a demonstration of how to put the frontend in an iframe in a paired browsing experience. In this experience, the parent window could add additional UI at the top for managing the validation errors in the AMP iframe, even without there needing to be an iframe for the non-AMP experience. When changing the validation error status (rejected to accepted) then this could cause the AMP iframe to reload (and persist the scroll position), and the user could more quickly see the effect.

[westonruter]

Something to consider for guidance is what Plugin Detective where it could guide the user through removing/keeping invalid markup based on answering questions.

[westonruter]

See also https://github.com/ampproject/amp-wp/issues/3664#issuecomment-575734739:

With the work being done to add stylesheet information to the validated URL screen (#4026), we also need to surface this information proactively in the post editor, in a similar way to how validation errors will get surfaced. One idea would be to incorporate the admin bar item similar to what Site Kit does.

The same admin bar item could also be present on the frontend. Clicking it would trigger a validation request and then show the results right there on the frontend instead of having to go to the validated URL screen.