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: tyxla <tyxla@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>

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

Kind of aside. I wonder about the "deprecate classic block" message we see when we write something in the code editor. Why are we showing this message instead of using the HTML block directly or have a message that don't mention "classic block"? I'm thinking having unmarked html is common and doesn't necessarily mean someone was reaching for the classic block.

These media-related pieces are really fragile. I'm looking forward to when we promote this experiment to a bigger change in Core and clean up a bit in the process.

Noting here — for anyone else and for my future self — that with the dequeueing of mce-view there will remain a Backbone template sent down the wire but never used: tmpl-editor-gallery. Unfortunately, it is output by wp_print_media_templates, which we can't ignore.

Yep, I wish they were more flexible and easier to orchestrate. wp_tinymce_inline_scripts() is also pretty bad, it doesn't really allow you to properly prevent those inline scripts from being added (it's possible to do, but very hacky):

https://github.com/WordPress/wordpress-develop/blob/be6a6103d43580d77dcd1efcb2512cddbba4e2b1/src/wp-includes/script-loader.php#L643-L651

https://github.com/WordPress/wordpress-develop/blob/be6a6103d43580d77dcd1efcb2512cddbba4e2b1/src/wp-admin/edit-form-blocks.php#L321

To handle this properly, we'll need to make some changes to core. But that's the next step, we should first remove the experiment wrapper once we're happy with how it works and test it for some time.

Kind of aside. I wonder about the "deprecate classic block" message we see when we write something in the code editor. Why are we showing this message instead of using the HTML block directly or have a message that don't mention "classic block"? I'm thinking having unmarked html is common and doesn't necessarily mean someone was reaching for the classic block.

It's because we want to be less abrupt in this transition. We're intentionally not fully removing the classic block, because it might be the case that someone needs it and relies on it - both with a raw HTML inside the editor, and with a wp:core/freeform instance. And if they do, we still want them to have the old experience (including if they do it in runtime). We're basically removing the Classic block when it's not used, and for any new posts. This is the first step to test the waters; if it goes well, we can get more aggressive and fully remove the Classic block in favor of HTML block, without an easy way to get it back. That being said, I'm happy to improve the messaging if you have any suggestions.

While we're on the topic of messaging, I did notice a bit of UX that could be better, but I'm not sure how to improve it. One of the sentences reads:

Alternatively, you can refresh the page to use the Classic block.

But, if the editor is dirty, refreshing will require a save. The user may be confused to see beforeunload confirmation prompt when they were just "doing as told" by the UI, possibly leading to loss of unsaved data.

Thanks - that's been bothering me too. How about something like this:

Alternatively, if you have unsaved changes, you can save them and refresh to use the Classic block.

That could work. It's the little things. :)

That could work. It's the little things. :)

Updating in #73485, please have a look when you get a chance.