-
Notifications
You must be signed in to change notification settings - Fork 292
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 support for AMP dev mode #505
Conversation
FYI: I've attached a build of the AMP plugin with a link the PR description at ampproject/amp-wp#3187 |
@felixarntz I forgot that I had created an issue for this. See #438. Updated description to indicate the relationship. |
AMP plugin v1.3 has now been released with the Admin Bar support. Can this be moved forward? |
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.
@westonruter This looks good, just one compatibility fix would be good - and maybe we can solve one piece a bit more elegantly.
Can you also make this a proper (non-draft) PR? :)
* @return string[] XPath queries. | ||
*/ | ||
public function add_amp_dev_mode( $xpath_queries ) { | ||
$xpath_queries[] = '//script[ contains( text(), "googlesitekit" ) ]'; |
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.
Just to clarify, this is only for inline scripts then right? The non-inline scripts receive the attribute in their own *_loader_tag
hooks I see.
Adding a random googlesitekit
comment to all these scripts is not so great. Is there not a way to add the data-ampdevmode
attribute to those inline scripts with a filter too?
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.
Just to clarify, this is only for inline scripts then right? The non-inline scripts receive the attribute in their own
*_loader_tag
hooks I see.
Yes, that is correct.
Adding a random
googlesitekit
comment to all these scripts is not so great. Is there not a way to add thedata-ampdevmode
attribute to those inline scripts with a filter too?
It's not awesome, but it is effective and somewhat nice for debugging to locate and identify scripts coming from Site Kit.
I did try to find a way to filter the inline scripts to inject this data-amp-dev-mode
attribute, but I was unable to. The extra scripts get printed in \WP_Scripts::print_extra_script()
which unfortunately has no filter like script_loader_tag
.
…dev-mode-support * 'develop' of github.com:google/site-kit-wp: (538 commits) keep array casting refactor earnings datapoint to not use array_merge Improve error handling in proxy mode by relying on the actual error response. Revert back to clientId in third-party code argument. fix: Always show proxy setup page when proxy is on fix: Rename TagManagerTest.php file fix docblocks in Data_Request add assertion for data request object immutability update docblock for get_batch_data revert changes to get_batch_data call in SC module Move Data_Request to REST_API namespace refactor Data Request getters with magic methods Fix incorrect Travis-CI script order. Ensure environment preparation failures result in errors in Travis-CI. Remove unnecessary array_map. Improve regex in PHP-Scoper configuration. fix: Rename third-party library preserve case change in Tag Manager datapoints update references to Google_Client fix intVal global prefixing ...
It was a draft because it wasn't fully working. There are a bunch of other script dependencies from Core/Gutenberg that need to get flagged as being in dev mode as well. They include:
As well as script localization inline scripts. |
add_filter( | ||
'script_loader_tag', | ||
function ( $tag, $handle ) use ( $assets ) { | ||
if ( $this->context->is_amp() && isset( $assets[ $handle ] ) && $assets[ $handle ] instanceof Script ) { |
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.
This apparently needs to look to also look to see if the $handle
is a dependency of any $assets
as well.
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.
We can probably add a get_dependency_handles()
method to Google\Site_Kit\Core\Assets\Asset
, which we can then leverage here to check that.
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.
Out of curiosity, why would the amp plugin not just add the attribute to all style and script tags? Why only whitelist Site Kit assets and dependencies? If needed, why wouldn't the amp plugin add the attributes and let other plugins hook in to whitelist its assets rather than each plugin reimplementing this itself?
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.
The attribute should only be added to JS that is related to functionality not relevant to the frontend (and which thus would not actually break AMP compatibility of the frontend, as long as you're logged-out). That's why it needs to be conservative, any plugin that has JS-powered admin bar functionality needs to explicitly declare that.
Regarding addition of the attributes, that's a good point. @westonruter Maybe the AMP plugin could include a central solution for adding the attribute that scripts/stylesheets could leverage via e.g. a wp_*_add_data( ... )
?
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.
Note that any script or stylesheet that has admin-bar
as a dependency will automatically get the dev mode attribute. The issue is with scripts/styles that do not have this explicit admin bar linkage, such as dependencies on general libraries.
Maybe the AMP plugin could include a central solution for adding the attribute that scripts/stylesheets could leverage via e.g. a
wp_*_add_data( ... )
?
I'm not sure I understand. Are you saying you could do something like:
wp_script_add_data( 'lodash', 'ampdevmode', true );
And that this could be used as a dev mode signal equivalent to dependence on the admin-bar
script? Then the AMP plugin could include a script_loader_tag
filter which adds the data-ampdevmode
attribute automatically to any script that has the ampdevmode
data or which depends on a script that has this attribute?
This could also be used to automatically add the comment for inline scripts as well. Whereas right now we are manually adding /* googlesitekit */
to the inline scripts, there could be a wp_print_scripts
action which loops over all scripts prior to printing and any script which contains the ampdevmode
data could also then do:
wp_add_inline_script( $handle, '/*ampdevmode*/' );
And this pattern could be automatically added to the list of amp_dev_mode_element_xpaths
.
Does this sound right?
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.
@westonruter Yes, that would be great - really like including inline script support as well.
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.
Work in progress: ampproject/amp-wp#4001
add_filter( | ||
'script_loader_tag', | ||
function ( $tag, $handle ) use ( $assets ) { | ||
if ( $this->context->is_amp() && isset( $assets[ $handle ] ) && $assets[ $handle ] instanceof Script ) { |
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.
We can probably add a get_dependency_handles()
method to Google\Site_Kit\Core\Assets\Asset
, which we can then leverage here to check that.
…-wp into add/amp-dev-mode-support
…cies of wp-element and wp-compose respectively.
With the latest commits, AMP dev mode works as expected. Some notes:
|
Awesome. I deployed it to my AMP-first site and I can see the Site Kit admin bar and there are no validation errors being reported! |
Co-Authored-By: Evan Mattson <evan.mattson@10up.com>
Addresses issue #438.
Summary
Depends on ampproject/amp-wp#3187.
As noted in ampproject/amp-wp#1921, AMP now supports a dev mode (ampproject/amphtml#20974) which allows a document to mark certain elements as being excluded for AMP validation. This is exactly what the AMP plugin has needed to allow the admin bar without fighting against the 50KB CSS limit. It also opens up the door to using scripts on AMP pages to add interactivity to the admin bar without worrying about AMP compatibility. This is exactly what Site Kit has needed for its admin bar integration on AMP pages.
This PR begins to implement support for that. I'll need help to complete it. In short, any markup that is being added by Site Kit to the frontend should be amended with the
data-ampdevmode
attribute to each element. The elements in the admin bar items will get this automatically, so the primary concern is thescript
,link
, andstyle
elements that are output to integrate Site Kit on the frontend admin bar.Relevant technical choices
data-ampdevmode
to elements for scripts and styles on AMP pages to exempt them from AMP validation.Checklist