WP.com block editor: Exclude features from Jetpack sites

[mmtr]

Changes proposed in this Pull Request

We shouldn't expose all the common features from wpcom-block-editor to Jetpack sites, since some of them are intended specifically for WP.com users such as:

• Disable NUX tour.
• Unregister experimental blocks.
• Reorder CoBlocks blocks.

This PR seeks to fix that by splitting the common features into 2 new bundles:

• default: loaded on all sites.
• wpcom: loaded only on WP.com sites.

The common bundle is no longer maintained and it is replaced by the default bundle. Note that the common build needs to keep being served on widgets.wp.com since it will be still used by Jetpack and Atomic sites running Jetpack 8.0 or earlier.

Testing instructions

• Apply D36841-code and sandbox widgets.wp.com for adding the new bundles to your sandbox:
• Prepare a Simple, a Jetpack and an Atomic test site:
  • Simple: Apply D36377-code and sandbox any WP.com simple site.
  • Jetpack: Spin up a new JN site running jetpack#14230.
  • Atomic: Install the Jetpack beta plugin and switch the Jetpack branch to update/wpcom-block-editor-exclude-features-jetpack.
• Make sure the features are enabled/disabled according to the following table:

Feature	Editor	Simple site	Atomic site	Jetpack site
rich-text: Extensions for the Rich Text toolbar with the Calypso buttons missing on Core (i.e. underline, justify).	WP Admin	✅	✅	✅
	Calypso	✅	✅	✅
switch-to-classic: Appends a button to the "More tools" menu for switching to the classic editor.	WP Admin	✅	❌	❌
	Calypso	✅	✅	✅
fix-block-invalidation-errors: Performs block attempt block recovery on editor load if validation errors are detected.	WP Admin	✅	✅	❌
	Calypso	✅	✅	❌
reorder-block-categories: Moves Jetpack and CoBlocks Block Categories below Core Categories.	WP Admin	✅	✅	❌
	Calypso	✅	✅	❌
tracking: Adds analytics around specific user actions.	WP Admin	✅	✅	❌
	Calypso	✅	✅	❌
iframe-bridge-server: Server-side handlers of the different communication channels we establish with the client-side when Calypso loads the iframed block editor. See calypsoify-iframe.jsx.	WP Admin	❌	❌	❌
	Calypso	✅	✅	✅
tinymce: Tiny MCE plugin that overrides the core media modal used on classic blocks with the Calypso media modal.	WP Admin	❌	❌	❌
	Calypso	✅	✅	✅

Fixes #34476

[matticbot]

Test live: https://calypso.live/?branch=update/wpcom-block-editor-jp-scripts

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[kwight]

Shouldn't switch-to-classic be in wpcom instead of common?

[mmtr]

Shouldn't switch-to-classic be in wpcom instead of common?

We want to show the "Switch to classic" button on Calypso for Jetpack sites as well, so we need to keep it in the shared utilities. It's true we don't want to show it on the WP Admin block editor, but we can control that with wpcomGutenberg.switchToClassic.isVisible.

[simison]

but we can control that with wpcomGutenberg.switchToClassic.isVisible.

Should things in common bundle be a little bit more defensive about objects or CSS selectors potentially not existing?

So e.g.; lodash.get( window, [ 'wpcomGutenberg', 'switchToClassic', 'isVisible' ], false )

If I understood correct, common runs also self-hosted Jetpack sites? We don't really control what version of Gutenberg is running there or what other oddities are going on.

[mmtr]

Should things in common bundle be a little bit more defensive about objects or CSS selectors potentially not existing?

So e.g.; lodash.get( window, [ 'wpcomGutenberg', 'switchToClassic', 'isVisible' ], false )

Yup, nice catch. I opted for the optional chaining ?. (which is available in Calypso and thus correctly polyfilled in the generated builds) in 0f7e5a0.

If I understood correct, common runs also self-hosted Jetpack sites? We don't really control what version of Gutenberg is running there or what other oddities are going on.

Correct. That's the reason why we still use @wordpress/editor instead of @wordpress/block-editor. We made sure that all the features are backwards compatible.

[simison]

Correct. That's the reason why we still use @wordpress/editor instead of @wordpress/block-editor. We made sure that all the features are backwards compatible.

Latest Jetpack version supports new enough WP core to use @wordpress/block-editor — is there any mechanism in this setup to differentiate between Jetpack versions, or do you just run the latest from CDN for all possible Jetpack versions? If latter, you might be stuck with backwards compatibility support for quite some time...

[mmtr]

do you just run the latest from CDN for all possible Jetpack versions? you might be stuck with backwards compatibility support for quite some time...

Unfortunately, this is the case. I think we could have versioned builds and then update the wpcom-block-editor module in Jetpack to use a specific version. Anyway, current features are relatively simple and we didn't need to add so much backwards compatibility support.

[kwight]

We want to show the "Switch to classic" button on Calypso for Jetpack sites as well, so we need to keep it in the shared utilities.

Oh, right – "classic", meaning, the Calypso editor 🙃 Yeesh.

[gwwar]

Verified Simple Site Behavior, no regressions found so far

[gwwar]

Having switch to classic appear in the iframe for WordPress.com but not in wp-admin for Atomic seems a little odd. Non-blocking, as this is current behavior and we can follow up with that.

[gwwar]

✅ Atomic features appear to work well

[gwwar]

✅ Also smoketested Jetpack standalone: no tracking, Calypso media integration, rich text integration

[gwwar]

Thanks @mmtr! I think this approach should work well, though I have two last points to consider before we

• Are the filenames here too generic? We likely have a high chance of asset name collision. Folks in the future might have trouble tracing this back
• It may be worth copying over the full feature table in the summary to the readme

[gwwar]

Note that it may also make sense to group needed changes for Automattic/jetpack#14233

I'd prefer if we had a systematic way of splitting out CSS vs a manual one off, as we're likely going to miss this in the future.

[mmtr]

I'd prefer if we had a systematic way of splitting out CSS vs a manual one off, as we're likely going to miss this in the future.

Even with different dist files (which I agree is a good idea), Automattic/jetpack#14233 would still needed since the goal there is to avoid an extra network request (see p1576247513008200-slack-perfops).

Anyway, I think we can improve our build script in order to automatically open diffs and PRs that updates those inline styles if they are modified in the wpcom-block-editor Calypso app.

[mmtr]

Are the filenames here too generic? We likely have a high chance of asset name collision. Folks in the future might have trouble tracing this back

Bundles are all served under the widget.wp.com/wpcom-block-editor path (i.e. https://widgets.wp.com/wpcom-block-editor/default.js), so that should guard against name collisions since the app cannot have two bundles with the same name.

[mmtr]

Alright, I performed a bunch of changes:

• Added the full feature table to the readme.
• Split bundles into editor and view modes (first will be loaded only on editor, latter on both editor and frontend).
• Remove no longer needed features:
  • Disable NUX: we're enabling it again in WPCOM Block Editor: Remove disable-nux-tour #38369
  • Unregister experimental blocks: they are unregistered by default now on Gutenberg, and experiments cannot be turned on on Simple/Atomic sites.
• Created new diff that adds the new assets to widgets.wp.com (D36841-code).
• Updated D36377-code and WP.com block editor: Exclude WP.com features from Jetpack sites jetpack#14230 for loading new assets.
• Updated WP.com block editor: Exclude WP.com features from Jetpack sites jetpack#14230 for adding inline the default styles (copied from WP.com Block Editor: Add Justify styles inline rather than by enqueuing. jetpack#14233).

[gwwar]

Smoke Tested:
✅Simple /block-editor
✅Simple /wp-admin
✅Jetpack standalone /wp-admin
✅Jetpack standalone /block-editor
✅Atomic /wp-admin
✅Atomic /block-editor

[gwwar]

Great I think this is good to go @mmtr ! If there's anything we missed we can add onto it in follow ups.

I also verified that view styles are inlined for Simple Sites: