Fix the AMP Preview button not being shown in the block editor

[pierlon]

Summary

This PR fixes of the "Preview AMP" button no longer being shown on the edit post page (determined to be last working on Gutenberg v8.7.1). This has been tested on Gutenberg versions v6.8.0, v8.7.1, and v9.0.0.

The issue arises from the (non-AMP) "Preview" button no longer being available on DOM load (possibly due to async rendering of the component, but I have not confirmed). Previously, we would bail and not render the "Preview AMP" button if the "Preview" button was not found:

amp-wp/assets/src/block-editor/index.js

Lines 65 to 67 in 239a334

	domReady( () => {
	renderPreviewButton( AMPPreview );
	} );

amp-wp/assets/src/block-editor/helpers/index.js

Lines 728 to 735 in 239a334

	export const renderPreviewButton = ( PreviewComponent ) => {
	const postPreviewButton = document.querySelector( `.${ POST_PREVIEW_CLASS }` );
	const ampPreviewButtonWrapperId = 'amp-wrapper-post-preview';
	// Exit if the non-AMP 'Preview' button doesn't exist.
	if ( ! postPreviewButton || ! postPreviewButton.nextSibling ) {
	return;
	}

To fix this issue, the "Preview AMP" button component is no longer rendered on DOM load; the component is now registered as a block editor plugin. Once the block editor calls the component's render function, it will be rendered inside a DOM node we control (a portal), and not within the editor (yet). As the component is about to be mounted into the DOM node, a check is made to see if the "Preview" button is present, and if so, the component will be inserted immediately after the "Preview" button.

Upgrade Notice

For versions of WP prior to 5.2 or if Gutenberg 5.4+ is not running, then a warning is displayed prompting administrators to upgrade:

Checklist

• My pull request is addressing an open issue (please create one otherwise).
• My code is tested and passes existing tests.
• My code follows the Engineering Guidelines (updates are often made to the guidelines, check it out periodically).

[github-actions]

Plugin builds for 9321696 are ready 🛎️!

• Download development build
• Download production build

[johnwatkins0]

A couple of small pieces of feedback, @pierlon.

Also, while the approach here with createPortal and inserting an element into the DOM on component mount is working, I think there should be a little more separation of concerns so that the component doing all the preview work doesn't have to be so aware of the DOM context. Two possible ways to achieve this:

1. Create and insert the DOM element at the start of the script, and then render the component into the created element using standard ReactDOM.render. This would require registering this particular editor plugin outside the loop where plugins are being registered, but I don't think that's a problem.
2. If you still want to register the plugin inside the loop, I suggest doing the DOM manipulation work in a parent component that has that one job, and doing all the preview-related work in a child component.

[johnwatkins0]

Maybe this should be a class instead of an ID. While unlikely, it's technically possible for this component to be rendered multiple times on a page.

[pierlon]

@johnwatkins0 I've opted for option #​2 from your review as I think it's the most applicable here. If I understand correctly, option #​1 would've entailed moving the rendered component next to the 'Preview' button once the component had been mounted. I'm not entirely sure what you meant by:

This would require registering this particular editor plugin outside the loop where plugins are being registered, but I don't think that's a problem.

[pierlon]

I've opted to make this a pure component as this does not warrant unnecessary re-rendering, unless I'm missing something. @johnwatkins0 thoughts?

[johnwatkins0]

I think this is a good idea. I've seen side effects from having createPortal inside components that re-render often. E.g., not applicable in this case, but if there were any CSS animations on any of the element inside the portal, the animation might restart on every rerender.

[johnwatkins0]

This would require registering this particular editor plugin outside the loop where plugins are being registered, but I don't think that's a problem.

@pierlon I was referring to these lines:

amp-wp/assets/src/block-editor/index.js

Lines 25 to 29 in 5902120

	plugins.keys().forEach( ( modulePath ) => {
	const { name, render, icon } = plugins( modulePath );
	registerPlugin( name, { icon, render } );
	} );

All the plugin's editor plugins are expected to export the same variables to be registered in this loop. I already found this to be too limiting in a WIP branch I'm working on for the plugin sidebar, so I don't think we necessarily need to lock all editor plugins into this model. Performing DOM manipulation on the screen before registering the editor plugin is one use case that won't fit into the loop. But since your approach is working, this is a nonissue anyway.

[johnwatkins0]

Nice work!

[westonruter]

There is a slight style difference between Core and GB:

Version	Screenshot
Core
GB 9.1

This seems to be resolved via:

.wp-core-ui .amp-editor-post-preview {
    margin-right: 0 !important;
}

In GB 9.1 these styles are causing the extra margin:

Should we fix the margins?

[pierlon]

Ah good catch. That should be resolved in c2c883c.

[westonruter]

As discussed over chat, this is working back to WP 5.2:

However, in 5.1 and 5.0, neither the Preview button nor the AMP Enabled toggle appear:

[westonruter]

Suggested change

	wp.data.dispatch( "core/notices" ).createWarningNotice( "%s" )
	wp.data.dispatch( "core/notices" ).createWarningNotice( %s )

[westonruter]

Suggested change

	__( 'AMP functionality is not available in the Block Editor as the current version installed is not supported. Please update the Block Editor plugin to the latest version or use the Classic Editor instead.', 'amp' )
	wp_json_encode( __( 'AMP functionality is not available in the Block Editor as the current version installed is not supported. Please update the Block Editor plugin to the latest version or use the Classic Editor instead.', 'amp' ) )

[westonruter]

Why 5.3.0 specifically?

[pierlon]

It was the first stable release that worked without any errors. I guess I could bump it to 5.4.0 since that was the version bundled with WP 5.2.

[westonruter]

How about wrapping this in a current_user_can( 'manage_options' ) check? It doesn't do much good to show this warning to non-admin users.

[pierlon]

Yea that's a good idea.

[pierlon]

Done in 7d9ea2b.

[jwold]

@pierlon my testing steps were:

1. Fresh install of WordPress
2. Version 9.0.0 of Gutenberg
3. Version 2.0 branch for QA
4. Go to edit post and see preview button. https://d.pr/i/fQ8PuV

This is working as expected. Did I miss something though? Want to make sure I'm testing the right thing.

[westonruter]

@jwold You need to switch to a Paired AMP mode (either Reader mode or Transitional mode). Then you should see an AMP-specific preview button like so:

[jwold]

That worked! Thanks. QA passed.