Client-side media processing: Disable in Gutenberg just for now

[andrewserong]

What?

Follows:

• Media: Graduate client-side media processing from experimental #75112

Disable the client-side media experiment in Gutenberg (for now)

Note: this is intended as a quick-fix to ensure GB 22.6 is in a stable state. If there's a better approach to this, feel free to close this PR out!

Why?

The client-side media experiment was stabilised in #75112 and in time for the WP 7.0 feature freeze. However, there are still a couple of outstanding bugs that need to be resolved, and currently things in trunk are not quite ready to be used on production sites.

To give a little more time in Gutenberg releases to polish the remaining bugs, this PR proposes switching the default for client-side media to false. This will allow GB 22.6 to ship without client-side media processing enabled, and we can revisit re-enabling it in Gutenberg for 22.7 and beyond.

How?

Add a filter to disable the feature in Gutenberg, but also add a filter to enable it in tests.

Testing Instructions

With this PR checked out, open up the post editor and drag and drop a PDF file to the editor. If the file block shows the same filename as exists in the filesystem, it will have worked.

Screenshots or screencast

Before

Note the bug in client-side media processing is present, that strips the names of files when uploaded:

After

With this PR applied, the client-side media experiment should be switched off, so filenames should persist as expected:

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ramonjd]

Thanks for prepping this PR. It works as described for me.

I think the temporary tech debt is worth it to prevent surprises for folks downloading the next plugin version.

I wonder if the different defaults (WP trunk vs GB) will confuse developers/tester in the meantime. E.g. “it’s on in Core trunk but not when I use the plugin”.

Edit: the above question was rhetorical. I think if we markup our doc blocks and future testing instructions to stress “off in plugin only for the interim" then that's okay.

[andrewserong]

Thanks for the quick reviews!

I think the temporary tech debt is worth it to prevent surprises for folks downloading the next plugin version.
I wonder if the different defaults (WP trunk vs GB) will confuse developers/tester in the meantime. E.g. “it’s on in Core trunk but not when I use the plugin”.

I see what you mean. Hopefully we shouldn't have drift here for too long, as I expect this PR will only be temporary. The larger backport PR is still open here WordPress/wordpress-develop#10868 (planning to take it for a spin after lunch)

I reckon we can merge this in the immediate-term and revisit.

[Mamaduka]

It looks like the test/e2e/specs/editor/various/cross-origin-isolation.spec.js tests are now failing on trunk. I'm guessing it requires the feature to be active.

[andrewserong]

Dang, sorry about that, I should have rebased and waited for the e2es to pass. I'll take a quick look.

[andrewserong]

I've opened #75763 to try out enabling the client-side media processing just when we run those e2e tests, so that we still have active coverage. If that's no good, an alternative would be to skip the test suite.

Let's see how that PR goes.

[ellatrix]

I think we shouldn't disable it. We have until next Wednesday to try to make it work? cc @ockham

[andrewserong]

I think we shouldn't disable it. We have until next Wednesday to try to make it work? cc @ockham

Sounds good if the outstanding issues can be resolved in time! My main interest here was ensuring we don't accidentally land the next GB release with something broken. This PR will be easy to revert if we're ready by Wednesday.

[ockham]

I just cherry-picked this PR to the release/22.6 branch to get it included in the next release: 5738dc1