Create batch routine to perform conversion to blocks

[bobbingwide]

The new block editor, code named Gutenberg, already provides a ‘Convert to blocks’ function inside the editor. It’s not aware of the complexities of many shortcodes and the combinations in which they can be used. Developing the REACT code to support this ‘one time’ conversion for existing content may prove to be problematic. It would be nice to have a well defined process for a batch conversion of content, particularly shortcodes.

Requirement

• A batch / server routine that will perform conversion of post_content from Classic editor to Blocks.

Proposed solution

• Extensible architecture to allow supporting plugins to convert their own shortcodes using existing shortcode parsing and expansion logic.
• For each piece of content to be converted new action hooks and filters will be invoked.
• Existing shortcode functions will be replaced by shortcode migration functions
• When the post content is processed the do_shortcode logic will invoke the shortcode migration routine.
• Rather than expanding the shortcode, the migration routine will create the appropriate block / blocks for use in the block editor.
• Only those shortcodes which have registered a migration routine will be converted.
• Inline shortcodes will be left AS IS.
• It may be necessary to ensure that inline shortcodes are appropriately encapsulated in core blocks, to prevent future problems running convert to blocks in the block editor.

Pre-requisites

• A generic shortcode block which supports multiple attributes.
• Generic shortcode block to support positional and named attributes.
• Generic shortcode block to support embedded content
• Shortcode specific blocks.
• Ability to switch between static and dynamic version of a block.

Example

[bw_csv y=Y n=N]Shortcode,Inline,Convert to?
Bw_csv,N,oik-block/csv
Bw_css,N,oik-block/css
Bw_geshi,N,oik-block/geshi
Bw_contact_form,N,oik-block/shortcode
Wp,Y,
Bw,Y,
[/bw_csv]

Will be converted to a dynamic shortcode block

<!-- oik/csv y=“Y” n=“N” -->
Embedded content for the bw_csv shortcode exactly the same

Oh bugger. Will this work? How do you create a dynamic block with embedded content.

Let’s try tabulating the requirements again.

Shortcode	Inline	Convert to
Bw_csv	N	oik-block/csv
Bw_css	N	oik-block/css
Bw_geshi	N	oik-block/geshi
Bw_contact_form	N	oik-block/shortcode
Wp	Y
Bw	Y

Bw_csv, bw_css and bw_geshi are complex shortcodes which handle embedded content. None of them can be converted to the core shortcode block due to its current limitations.
See WordPress/gutenberg#5123 and WordPress/gutenberg#4456.
Each block requires RAW DATA to process as if it were the $content parameter to the shortcode.

Bw_contact_form is a simple shortcode with a few parameters that could be easily supported by a generic shortcode block - see pre-requisites.

Wp and bw are inline shortcodes that can be used in any block that accepts HTML content.
e.g. Here at [bw] we like [wp]. This site is currenty running [wp v].

[bobbingwide]

Catering for inline shortcodes will require a filter function - oik_block_query_inline_shortcodes.
The conversion to the generic oik-block/shortcode is obviously dependent upon #16
Conversion to specific named blocks is dependent on the block supporting all the parameter attributes used in the shortcode.

[bobbingwide]

Conversion to dynamic blocks may be dependent on whether or not the shortcode requires/supports content.

[bobbingwide]

How do you create a dynamic block with embedded content?

It looks like we’re dependent upon a solution to WordPress/gutenberg#5760

If Gutenberg can’t provide its own performant solution to block parsing then we’re no better off than we were with shortcode heavy content, such as that which is generated by some of the current page builders.

In fact, the workaround involves the generic shortcode block that appears to be a static block but which includes the shortcode with its embedded content.

<!-- oik-block/shortcode -->
[bw_csv y=“Y” n=“N”] ...
...
[/bw_csv]
<!-- /oik-block/shortcode -->

So we have a double whammy. First we parse the content into blocks, then we have to parse the shortcodes.