profile
viewpoint

Ask questionsAllow Developer Tools to be turned off to minimize (even hide) validation error info

AMP validation error notices are concerning to non-technical users:

Screen Shot 2019-06-21 at 17 02 31 (1)

Rejection of validation errors should be limited to higher-privileged users, with Authors and Contributors (or other non-Admin role) shown validation errors warnings that just prompt them either to remove the invalid block (#2285) or to escalate the error to an administrator for support.

There should perhaps be a filter to configure the verbosity of the warnings for authors. There's a tough balance here because at one hand the warnings could be hidden to not concern users, but then at the same time the errors mean that markup is being removed. So if the validation error notice is not presented to the user, there needs to be a way for those validation errors to be escalated to an administrator.


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

Acceptance criteria

  • Whether developer tools are disabled should no longer be determined by the template mode. Developer tools should be able to be enabled in Reader mode the same way as they are in Transitional/Standard modes.
  • A new user preference (exposed on the profile screen) should be exposed for whether developer tools are enabled. (This may also be exposed in the wizard per #4705.)
  • Only administrators have access to the developer tools, although this should be gated behind a new amp_validate capability which by default is mapped by the manage_options capability (in the same way as customize is by default granted by edit_theme_options).
  • When developer tools are turned off, the validation screens are not displayed in the admin menu (although they can still be accessed by users who can amp_validate).
  • When developer tools are turned off, synchronous validation is not performed in the editor when saving a post. Instead, saving a published post should schedule an event to validate that URL. (To be done as part of #1756.)
  • When there are unreviewed validation errors, a Site Health test should be make this known. See https://github.com/ampproject/amp-wp/issues/1756#issuecomment-623864593.

Implementation brief

  • <!-- One or more bullet points for how to technically resolve the issue. For significant Implementation Design, it is ok use a Google document accessible by anyone. -->

QA testing instructions

  • <!-- One or more bullet points to describe how to test the implementation in QA. -->

Demo

  • <!-- A video or screenshots demoing the implementation. -->

Changelog entry

  • <!-- One sentence summarizing the PR, to be used in the changelog. -->
ampproject/amp-wp

Answer questions westonruter

On a related note, I think the “Enable AMP” checkbox should be only presented to administrator users. Instead of non-admin authors seeing AMP validation errors and just going straight to disabling AMP for the post, they should instead be directed to contact the administrator to get advice on the issue and then the administrator can decide whether to disable AMP for the post.

Furthermore, the “Enable AMP” checkbox should be gated behind whether developer tools are enabled, not just whether the user is an administrator. For more on this, see https://github.com/ampproject/amp-wp/issues/1864#issuecomment-631850402.

useful!

Related questions

URL validation failed to due to the absence of the expected JSON-containing AMP_VALIDATION comment after the body. hot 1
URL validation failed to due to the absence of the expected JSON-containing AMP_VALIDATION comment after the body. hot 1
Github User Rank List