DB-6671: Preview Button Regression in WordPress 6.3

[backlineint]

In WordPress 6.3 dispatching an autosave event in the block editor via JS now triggers additional actions by WordPress that expect the default preview button to exist. This was causing React to throw an exception in the block editor.

In order to resolve this, we're now hiding the standard preview button with CSS rather than removing it from the dom via JS.

I also took a long look at adding test coverage for this. Since this functionality depends on client side JS our existing suite of PHP unit tests won't help. From what I can tell, WordPress does not have a core solution for functional or browser tests. The only JS testing is JQuery unit testing, which I also don't think can cover this use case. wp-browser (https://wpbrowser.wptestkit.dev/) seems like it would meet our needs, but the implementation would be outside the scope of this ticket. wp-browser uses codeception rather than phpunit, and assumes that a live WordPress environment already exists.

We have an upcoming need for End to End testing, so I think that would be the most efficient way to address this.

Long term:

• We could take on the effort to implement browser based testing.
• or refactor the plugin to handle more of these changes on the server side. Our client side approach has proven to be brittle.

[CobyPear]

Tested with our dev sandbox by using the DB-6671 branch and it LGTM

[pwtyler]

@CobyPear @backlineint should "Tested up To" be incremented again?

[backlineint]

Yup - sorry that slipped my mind.