Auto convert to blocks

[ellatrix]

Let's slowly try to auto convert classic content to blocks.

Ideas from @mtias: let's start small, don't do it for post types without revisions, maybe opt-in for non-exact conversions.

To do list:

• Auto convert a post on load if it meets the following conditions: (I think some work from Freeform: autoconvert on mount (opt-in) #62442 could be reused)
  • The whole post is freeform (no blocks present)
  • The post supports revisions
  • The resulting blocks (excluding block delimiters) matches with the original content exactly. We could use the existing isEquivalentHTML to compare the content without whitespace.
• See what content fails and improve the raw handler. For example:
  • Match div elements to group (use a raw transform in block.json). Maybe even include other tags because the group block supports a custom tag name. Also match class name etc.
  • Store other kinds of attributes present on other blocks such as id on a paragraph etc.
  • Improve rich text content handling (there are existing PRs such as Convert to blocks: upgrade and remove spans if possible #62659, Raw handling: fix too aggressive indented list removal #62622, Raw handling: preserve class #60331, Raw handling: preserve empty paragraphs #59476). I think @saulyz has a lot more cases that need to be resolved.
  • The philosophy of the raw handler is to preserve content as well as possible (except for useless things such as spans without attributes). This is in contract to the paste handler, where we only want to preserve semantic content.

Cc @azaozz @mtias

[mtias]

Another further thought on opt-in / opt-out: we could add a flag in wp_config : AUTO_CONVERT_TO_BLOCKS which could support a post type array argument.

[azaozz]

Been looking / thinking about this a bit and have few questions/comments:

1. Perhaps it would be better to convert all "freeform" content in all cases, not only if this is an old post that has never been edited in Gutenberg and doesn't contain any blocks. There doesn't seem to be a good reason to have "loose HTML" between blocks. This may have been considered "parity with the old editor" but that was 5 years ago? :)
2. Assuming after some content has been auto-converted, there will be a user-notice that would contain an "Undo" button. What should happen when a user clicks that Undo?

• As far as I see best would be to "convert" the freeform content into HTML block(s). Otherwise will have to set some prop to prevent the auto-convert-to-blocks-on-load from happening the next time the post is opened for editing or it may get really annoying for some users. Creating HTML blocks from the freeform blocks has other advantages: better structure of the posts edited in the block editor (there will not be any "loose HTML" between blocks), no more need to run autop on displaying them, resolving the buginess/unexpected results around using setFreeformContentHandlerName, etc.
• If the above sounds good, the HTML block would need some updates, mostly a "Convert to Blocks" button, and "Visual Editor" button that would load TinyMCE on demand.
• If it doesn't sound good perhaps the core/freeform blocks can be made permanent, i.e. saved in the DB as any other block. Thinking this will still make it possible to not run autop on every page load on the front-end which will be a very nice speed improvement.

[saulyz]

Let's say we run a multisite. There can be various combinations among sites: a) run Gutenberg and have posts, pages (use block themes); b) run Gutenberg but use ACF on Custom Post types, c) run legacy themes with Classic editor on posts and pages.

I understand that suggested option AUTO_CONVERT_TO_BLOCKS would affect only group A. And for group C, only after migration to block themes this would start making impact.

As conversion to blocks is inevitable, this might not cause any real problem.

However there can be some situations to consider:

• Different sites == different owners. The same post type in config for auto conversion might not match the different owners intentions.
• There can be some limitations to use Core blocks. The core/group and core/html are good examples for cases when we want to enforce brand styles and leave editors with certain and custom layouting means. When talking about statistics of conversion failure - <div> is a major issue when core/group and core/html blocks are not available.

What would be very helpful with AUTO_CONVERT_TO_BLOCKS introduction is that we could mark all these posts as failing. And further maybe alert via log or email. The editors or authors might initiate the auto convert, but the administrators are ones to solve the issues. So flagging failing auto conversions would make a more efficient discovery.

[mtias]

@ellatrix should we close #44054 ?

[ellatrix]

@mtias Or we move this conversation there, up to you.