Integrate admin bar with AMP dev mode #3187
Conversation
…dev mode) * Eliminate need for keeping forked version of admin-bar.css in plugin. * Automatically add data-ampdevmode attributes to scripts and styles that depend on the admin bar, excluding them from being sanitized out of the document. * Skip processing stylesheets that have data-ampdevmode attributes.
Also add missing dynamic_element_selectors arg to stylesheet cache key.
…s for dev mode elements
…y for unauthenticated admin bars
westonruter
changed the title
Refactor methods to improve readability and organization
Add todo comments for where dev mode should be used instead of allow_dirty_*. Make closures static.
|
I'm going to add some more tests, but the scope of this I believe is complete. |
|
I'm also going to open PRs for Jetpack and Site Kit to ensure the API allows for the plugins to successfully exempt admin bar integrations from AMP validation. |
| @@ -233,6 +233,17 @@ function() { | |||
| add_action( 'amp_story_head', 'wp_site_icon', 99 ); | |||
| add_action( 'amp_story_head', 'wp_oembed_add_discovery_links' ); | |||
|
|
|||
| // Disable admin bar from even trying to be output, since wp_head and wp_footer hooks are not on the template. | |||
There was a problem hiding this comment.
Would it make sense (in a later PR) to hook the admin bar into 'amp_story_head'/'amp_story_footer' ?
There was a problem hiding this comment.
That's a good question. I'm not sure if the styles used in AMP Stories would even be compatible with the styles used for the admin bar. Since AMP Stories are a full-screen experience, I suspect that the admin bar would clash. But it would be something useful to investigate at a later time, yes.
Co-Authored-By: Alain Schlesser <alain.schlesser@gmail.com>
…ode-support * 'develop' of github.com:ampproject/amp-wp: (28 commits) Exclude development files from production build ZIPs Add filter to allow more video types in AMP story background se… (#3171) Update dependency @babel/cli to v7.6.0 (#3203) Update dependency @babel/core to v7.6.0 (#3204) Remove deprecated AMP_WP_Utils class Refresh Composer lock file Run build in a temporary folder Add shell script to clean up the current folder and then trigger a build Adapt Gruntfile to fetch optimized Composer dependencies within the build folder Retrieve Sabberworm patch directly from the GitHub PR Adding regression test for vertical text alignment issues Fixing minor errors in test descriptions Only restrict height inside non-fit text blocks Rewritten block size tests Limit height declaration to only direct descendant Remove now obsolete withEnforcedVideoUploadType HOC Update eslint-plugin-jest and apply fixes (#3192) Update dependency postcss to v7.0.18 (#3200) Update dependency terser-webpack-plugin to v2 (#3195) Update dependency webpack-cli to v3.3.8 (#3194) ...
| @@ -899,6 +935,33 @@ function amp_get_content_sanitizers( $post = null ) { | |||
| */ | |||
| $sanitizers = apply_filters( 'amp_content_sanitizers', $sanitizers, $post ); | |||
|
|
|||
| if ( amp_is_dev_mode() ) { | |||
There was a problem hiding this comment.
I think it would be preferable to have this piece of logic be part of the AMP_Dev_Mode_Sanitizer class instead, and then make that sanitizer decide when it acts or not, instead of hardcoding it in here.
It should be the responsibility of the AMP_Dev_Mode_Sanitizer to know when to do something and what to do, not some helper function collection.
There was a problem hiding this comment.
I did think about that, but I think it's preferable here because this function is inherently connected directly with WordPress as it applies a filter. There are two reasons for why this should not be in the sanitizer:
- It is important that the array of sanitizer args returned by
amp_get_content_sanitizers()be deterministic in what the resulting sanitized document be. In other words, we cannot apply filters inside of a sanitizer because then we cannot use the sanitizer args as a source of truth for computing a cache key for the post-processed output, as we can now. - We should be trending the sanitizers toward being pure PHP classes that are do not connect with WordPress APIs (especially the plugin API per above) as this is the direction needed for abstracting the sanitizers onto a CMS-agnostic package.
Additionally, this amp_is_dev_mode() function would be useful outside of the context of a sanitizer. For example, a theme/plugin may want to call this function during template generation to determine whether it can output some dev code (e.g. Query Monitor).
The amp_is_dev_mode() is gatekeeping whether or not the AMP_Dev_Mode_Sanitizer should be used in the first place. So it is operating at a higher level.
Aside: should it rather be named is_amp_dev_mode()?
There was a problem hiding this comment.
Aside: should it rather be named is_amp_dev_mode()?
I'm seeing the amp_ as a prefix here, as this could just as well be used outside of the AMP plugin, so I think the name is fine.
|
Just found an issue. When the theme has a lot of CSS and the admin bar is showing up, the We should probably mark the |
|
What comes to mind is that we could mark Dashicons as being in dev mode only if it was not directly enqueued or a dependency of any enqueued stylesheet other than |
|
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
googlebot
added
cla: no
|
@googlebot I consent. |
|
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
googlebot
added
cla: yes
See full writeup: Integrating with AMP Dev Mode in WordPress.
amp_is_dev_mode()function along with anamp_dev_mode_enabledfilter; this returnstrueby default when the user is logged-in and the admin bar is showing.AMP_Dev_Mode_Sanitizerfilter which is registered among the sanitizers whenamp_is_dev_mode()returns true. Takes as an argument an array of XPath expressions for elements to adddata-ampdevmodeto; this array can be filtered via theamp_dev_mode_element_xpathshook. When the admin bar is shown, it will at least include the XPath expressions for excluding admin bar.admin-bar.cssin plugin.data-ampdevmodeattributes to scripts and styles that depend on the admin bar, excluding them from being sanitized out of the document. This includes Dashicons, when the stylesheet is not being enqueued as part of the admin bar.data-ampdevmodeattributes.Fixes #1921.
Reverts or partially-undoes #2346, #2972, #2500, #2405.
Integrates with Dev Mode introduced in ampproject/amphtml#20974 via #3084.
Before
When themes have too much CSS for the admin bar to fit, the admin bar was removed from the page:
When there was not too much CSS, the admin bar was included in post-processing, converting all elements in the admin bar to AMP (including the Gravatar to
amp-img) and processing/tree-shaking theadmin-bar.cssanddashicons.css; theadmin-bar.jswas dequeued and any plugins that tried to add JS to put interactivity in the admin bar were blocked as validation errors:After
The admin bar element tree, the admin bar stylesheets (
admin-bar.css, its inline style, anddashicons.cssif not directly enqueued by a theme/plugin) will all be marked with thedev-ampdevmodeattribute, in addition to this thedata-ampdevmodeattribute being added to the root element. The AMP validator extension will show one single error related to dev mode, but the extension will soon be updated to change this from an error badge to some other indicator specific dev mode:The root HTML element, the admin bar element tree, the styles for the admin bar (
admin-bar.css, inline style,dashicons.css), and now even theadmin-bar.jsall get thedata-ampdevmodeattribute added and thus are excluded from sanitization:Now plugins can exempt JS administrative functionality in the admin bar from AMP validation. For example, with Automattic/jetpack#13450 the Notifications module in Jetpack now works on AMP pages:
The required scripts and styles all get the
data-ampdevmodeattribute:Even when there is excessive CSS on the page, the admin bar will still be included:
Todo
data-ampdevmodeto thehtmlelement.data-ampdevmodeis added to all admin bar assets, both scripts and styles, and any related dependencies.data-ampdevmodeattributes.#wpadminbarfrom the page prior to running the sanitizers, and then restore it at the end, but withdata-ampdevmodeattributes being added to every element in the tree.#wpadminbartodynamic_element_selectorswhen admin bar is shown.May require Improve definition and filtering of sanitizer default args #1478.data-ampdevmodeattributes.( is_user_logged_in() && is_admin_bar_showing() )But then we'd still need the forked admin bar CSS. In reality, only a very very small number of sites would force the admin bar to be shown for unauthenticated users, so this is probably not worth worrying about. But perhaps we should still keep in place the stylesheet prioritization logic.Add support for declaring certain script/style handles as being for dev mode?(Maybe later.)Make use of(To be investigated later; Customizer integration is less important than the admin bar, and the current approach of just allowing all scripts in the Customizer preview works fine.)data-ampdevmodeto allow Customizer scripts and styles in the preview, as opposed to the sanitizer argsallow_dirty_stylesandallow_dirty_scripts.data-ampdevmode?styleattributes on elements that havedata-ampdevmode?Build for testing: amp.zip - v1.3-alpha-20190910T210727Z-e15bbe33