-
Notifications
You must be signed in to change notification settings - Fork 815
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
Allow invalid AMP in Jetpack using a filter #16901
Conversation
Caution: This PR has changes that must be merged to WordPress.com |
This is an automated check which relies on E2E results is available here (for debugging purposes): https://jetpack-e2e-dashboard.herokuapp.com/pr-16901 |
I'm going to review this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a key difficulty with attempting to use AMP Dev Mode for exempting certain elements from AMP validation. And that is the AMP pages in Dev Mode will always have one validation error:
Tag 'html' marked with attribute 'data-ampdevmode'. Validator will suppress errors regarding any other tag with this attribute.
When logged-in to WordPress and the admin bar is showing, Dev Mode is enabled in order to include the additional scripts on the page and intentionally not be a valid AMP page. Nevertheless, these AMP-invalid scripts are only present when the user is logged in: they won't show up when being crawled by Googlebot. If, however, you force AMP Dev Mode to be enabled then users will start seeing Google Search Console warnings for AMP validation errors.
If intending to use AMP Dev Mode in this way, we'd need to also provide the capability to omit the amp
attribute from the html
element. In this way, the page won't even be marked as AMP and so GSC won't try to validated it as an AMP page. This capability would make sense for a site in Standard mode.
For example, let's say that you force Dev Mode to be enabled via:
add_filter( 'amp_dev_mode_enabled', '__return_true' );
And then we introduce a new filter for whether the document should be marked as AMP, so you could turn it off:
add_filter( 'amp_dev_mode_document_marked', '__return_false' ); // Tentative naming.
This really should only be allowed on a Standard mode site, as if you do it on a paired mode site, crawlers will navigate to the amphtml
links and complain about being linked to a non-AMP page.
Then on a Standard mode site, you'd have an HTML page with the AMP runtime but it would not be marked as AMP. Note that this usage of AMP is not yet official supported. It will only be really safe/supported to do this once Bento AMP ships, as otherwise the AMP runtime is not expecting for 3rd-party JS to be mutating the document.
Note that omitting the amp
attribute from the html
element is also the behavior of Standard mode sites that have excessive CSS: instead of stripping out the excessive CSS to make it a valid AMP page (which is the behavior in Transitional mode), in Standard mode the default behavior is to not strip it out and then to just mark the page as non-AMP. This is because in Standard mode there is no non-AMP version to go to if the AMP version is broken due to the removed styles.
* @since 1.3 | ||
*/ | ||
public function sanitize() { | ||
$this->dom->documentElement->setAttribute( AMP_Rule_Spec::DEV_MODE_ATTRIBUTE, '' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As opposed to setting this attribute manually, you can use the amp_dev_mode_enabled
filter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevertheless, this filter is probably not ideal either.
What is really needed is to conditionally add this attribute on the root html
element if any element in the page had data-ampdevmode
attribute added. This would mean AMP pages that don't have any such widgets on them would not need to enable AMP Dev Mode and could be fully valid AMP pages.
$xpath = new DOMXPath( $this->dom ); | ||
foreach ( self::$asset_xpaths as $element_xpath ) { | ||
foreach ( $xpath->query( $element_xpath ) as $node ) { | ||
if ( $node instanceof DOMElement ) { | ||
$node->setAttribute( AMP_Rule_Spec::DEV_MODE_ATTRIBUTE, '' ); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of manually setting these, you can use the amp_dev_mode_element_xpaths
filter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or not, if the amp_dev_mode_enabled
filter is not being used to force AMP Dev Mode to be enabled.
@gravityrail I've opened a separate PR for what I believe is a better solution for making the OpenTable block AMP-compatible: #17085 |
PR for AMP-compatibility for the Pinterest block: #17086. |
Thanks for the contributions @westonruter ! |
PR for Eventbrite block: #17164 |
@westonruter looks like we only need a solution for Calendly now - nice work! Any chance you'll be able to put something together for that service? |
This comment has been minimized.
This comment has been minimized.
See #17216. |
See: #14395
A few widgets, such as OpenTable, don't work in AMP due to their reliance on external javascript.
However, in order to transition to AMP standard mode, sites would like the option of reaping the performance benefits of AMP without necessarily having every page be 100% strict AMP.
This PR provides a filter,
jetpack_allow_unsanitary_amp_content
(better names suggestions welcome) which - when set to true - allows various widgets to work at the expense of 100% AMP compatibility.It does this by setting the ampdevmode attribute on the
html
element and also any matching invalid assets.Repaired widgets: