-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability for theme/site to prevent AMP from being disabled #2314
Comments
There seems to be a case for the scenario of having a site on Native AMP while keeping some posts and/or templates excluded: Native AMP for parts of the site, no AMP for other parts. How can we account for that? Would removing the amp attribute from the doc account for cases such as the sidebar one? |
+1 |
Discussed offline: the above is correct, but the approach here is to provide the option to allow scenarios such as a theme requiring AMP for all content. |
I think this is closely related to #1864. |
I don't think we should do this. We should actually remove the ability for a theme to prevent AMP from being disabled. The challenge is if a theme depends on AMP components, then disabling AMP will cause problems. But when Bento AMP is a thing and themes can depend on AMP components specifically, then themes can have AMP turned off and reliably use AMP components. |
On posts there is an “Enable AMP” for users to be able to opt-out of AMP:
For sites in Native mode, this could actually result in the page being broken if the theme makes use of AMP components like
amp-sidebar
(ref #2312).The same thing can happen if a user decides to disable AMP for some templates:
What there needs to be is a way for a theme to easily indicate that it does not support AMP to be turned off. Such an option should:
This option could be defined in code by the theme (as an
amp
theme support flag) or via a checkbox on the admin screen.Also, being able to disable AMP for a given post is something that should perhaps be scoped to the Editor role (or Administrator).
Similarly, rejection of validation errors should be limited to higher-privileged users, with Authors and Contributors shown validation errors warnings that prompt them either to remove the invalid block (#2285) or to escalate the error to an administrator for support. Update: For this, see #2673.
The text was updated successfully, but these errors were encountered: