Do async site scan on plugin activation instead of synchronous validation#6685
Do async site scan on plugin activation instead of synchronous validation#6685westonruter merged 38 commits intodevelopfrom
Conversation
51fc15e to
f9ca991
Compare
b45c4c0 to
17bedd5
Compare
8f1a04f to
3857c7a
Compare
|
@westonruter I've updated the post-scan notice according to your suggestions. Also, the message for non-technical users has been updated. One plugin causing AMP incompatibilities
Two or more plugins causing AMP incompatibilities
|
|
When I tried to activate any plugin, I got the following error {
"message": "destroy is not a function",
"stack": "TypeError: destroy is not a function\n at commitHookEffectListUnmount (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:19845:13)\n at commitPassiveHookEffects (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:19903:13)\n at HTMLUnknownElement.callCallback (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:182:16)\n at Object.invokeGuardedCallbackDev (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:231:18)\n at invokeGuardedCallback (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:286:33)\n at flushPassiveEffectsImpl (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:22988:11)\n at unstable_runWithPriority (https://amp-local.test/wp-includes/js/dist/vendor/react.js?ver=16.13.1:2685:14)\n at runWithPriority$1 (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:11174:12)\n at flushPassiveEffects (https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:22955:14)\n at https://amp-local.test/wp-includes/js/dist/vendor/react-dom.js?ver=16.13.1:22834:13"
} |
|
@milindmore22 Thank you for the report. I'm not able to reproduce the error. It happens only if Gutenberg is not activated. I'm investigating it now. |
|
The issue described by @milindmore22 was caused by the fact that Gutenberg comes with React 17 while WordPress 5.8 is contains React 16.13. Version 17 brought some changes to how Along the way, I noticed some other issues: |
|
While working on this issue, I noticed a potential bug with a multisite setup: #6755 |
…sync-scan-on-plugin-activation * 'develop' of github.com:ampproject/amp-wp: Add test case for Bento lacking layout attributes; improve test coverage Fix phpcs alignment warning Cast term IDs to integers instead of using sanitize_key() Use strict check for in_array() and improve comment Derive intrinsic layout when max-width defined Validate supported layouts for converted Bento components; add support for fill and nodisplay Update AMP_Base_Sanitier::set_layout() to account for 100% width/height styles Harmonize Bento component name parsing Fix variable name Fix typos in comments Add support for converting Bento component dimensions from inline styles to AMP layout Further improve test converage and remove dead code Improve test coverage for ID attribute changes Improve Bento sanitizer and add tests Prevent bento components from being treated as light shadow DOM wrappers Prevent JS error on validated URL screen when no validation errors present Fix handling of ID attributes during sanitizer conversion Introduce Bento sanitizer to deal with BentoJS components Prevent completely tree-shaken styles from triggering excessive CSS
| if ( ! userIsTechnical ) { | ||
| return ( | ||
| <p | ||
| dangerouslySetInnerHTML={ { | ||
| __html: sprintf( | ||
| /* translators: %s is a name of a plugin or a list of plugin names separated with commas. */ | ||
| _n( | ||
| 'AMP compatibility issues discovered with %s.', | ||
| 'AMP compatibility issues discovered with the following plugins: %s.', | ||
| pluginsWithAmpIncompatibility.length, | ||
| 'amp', | ||
| ), | ||
| pluginsWithAmpIncompatibility | ||
| .map( ( pluginWithAmpIncompatibility ) => `<b>${ pluginNames[ pluginWithAmpIncompatibility.slug ] }</b>` ) | ||
| .join( ', ' ), | ||
| ), | ||
| } } | ||
| /> | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
I appreciate the concern for users who are not technical, but the additional information exposed below doesn't have anything technical on it. It just has the URLs on which issues were encountered. Listing out the URLs on which errors occur is helpful even for non-technical users so that they can check them out to see if anything is broken. Therefore I don't think this condition is needed.
Something I can see as being helpful in terms of making it more user-friendly is for the original <title> of the validated URL to be stored and for that to be displayed as the link text instead of URL. But we can explore that in a subsequent improvement.
westonruter
left a comment
There was a problem hiding this comment.
This is so great and so much better than before. Not only does it no longer slow down the activation of a plugin, it also scans all the scannable URLs instead of just one. 💯
| <a | ||
| href={ AMP_COMPATIBLE_PLUGINS_URL } | ||
| className="button" | ||
| { ...isExternalUrl( AMP_COMPATIBLE_PLUGINS_URL ) ? { target: '_blank', rel: 'noopener noreferrer' } : {} } |
There was a problem hiding this comment.
There was a problem hiding this comment.
That being said, it seems that noopener noreferrer is a common practice, e.g. the <ExternalLink> from @wordpress/components sets both rel types (plus an external type).
If that's the case, let's keep both noopener and noreferrer.
| <a href={ url } target="_blank" rel="noopener noreferrer"> | ||
| { url } | ||
| </a> |
There was a problem hiding this comment.
I guess it'd be best to use ExternalLink from @wordpress/components instead of a plain <a> tag.
| await page.waitForSelector( `tr[data-slug="${ slug }"] .deactivate a` ); | ||
| } | ||
|
|
||
| describe( 'for a user', () => { |
There was a problem hiding this comment.
We can now safely remove this nested describe since we're not testing different user types anymore.
There was a problem hiding this comment.
This has been addressed in a followup PR: #6758.






Summary
Fixes #5101
Screen.Recording.2021-11-23.at.09.37.04.PM.mp4
This PR renders an admin notice box whenever a plugin is activated. The admin notice starts a full Site Scan immediately and presents validation results as soon as the scan is complete:
Note that there is a slight difference in the implementation compared to the design. After Site Scan is done, we're listing out all plugins causing AMP incompatibilities along with the URLs on which the issues were discovered. Also, a CTA to AMP compatible plugins is not hidden inside the
<details>element but it's rather outside of it (since there might be multiple<details>elements in a single notice.According to the design, we should be showing only issues related to the plugin (or multiple plugins) that has just been activated. The CTA should be collapsed by default inside the
<details>element.On one hand, the designed approach would be more complex in terms of the implementation. Since Core doesn't store a list of plugins that were last activated (or is it?), we would have to persist it on our own, probably using the Options API. On the other hand, though, from a user point of view, I believe it's better to let a user know about every plugin that causes AMP validation errors, not just the one that has been activated.
In any case, I'm happy to change the implementation so that it matches the design.
Implementation Details
admingroup:amp-site-scan-notice.getSlugsFromValidationResultshelper had to be transformed into a more robustgetSourcesFromScannableUrlsfunction. The arrays returned bygetSlugsFromValidationResultscontained just the plugin/theme slugs like[ 'amp', 'pwa' ]. WithgetSourcesFromScannableUrls, the returned arrays also contain a list of URLs where the issues were found, e.g.[ { slug: 'amp', urls: [ ... ] }, { slug: 'pwa', urls: [ ... ] } ].class-amp-validation-manager.phpand into a new classPluginActivationSiteScan.Checklist