Free-form regions in block templates

[mboynes]

As a theme and plugin developer, I want to be able to define free-form regions in templates so that I can leverage the editorial structure of templates without sacrificing the flexibility and versatility of the block editor.

---

When using block templates, I lose the ability to have a section of the editor continue to function as normal and be "free-form" (not to be confused with the classic editor block, core/freeform). For instance, say I want the top of an article to be locked to a paragraph block, an image block beneath that, then below the image I want the block editor to behave as normal.

Examples

Here's one option for how we might define that part of a post is locked with an image and paragraph, but then below that, the block editor is unimpeded:

$post_type_object->template = [
    [ 'core/subhead', [] ],
    [ 'core/image', [] ],
    'any',
];

I opted for 'any' in this example to indicate that any block can be used, which would be consistent with other areas of core, like WP_Query.

Here's another example, where I'm defining multiple free-form regions:

$post_type_object->template = [
    [ 'core/subhead', [] ],
    [ 'core/image', [] ],
    'any',
    [ 'some-plugin/ad-slot', [] ],
    'any',
    [ 'another-plugin/related-articles', [] ],
];

This relates to #5208 and #3588 (CC @jasonbahl who made a similar suggestion in that issue).

[alexsanford]

I think this could be solved with the "Section" block, when it is finally added: #4900

Note that Section block will likely not be finished in phase one. You may want to look at this plugin for now: https://github.com/marcusig/gutenberg-section-block (full disclosure: I haven't tried it myself)

[mboynes]

While this might be able to be solved with a section block, I think it's important that the developer experience be as simple as I outlined. As long as it can be, then 👍👍.

As a developer who has made countless meta boxes in WordPress over the past decade or so, this is the feature that is stopping me from building blocks instead of meta boxes for article metadata.

[youknowriad]

I'm going to close this as it's possible using a section block and implementing this "any" placeholder would require a big refactoring to the editor that's not worth it for this particular issue.

[mboynes]

@youknowriad can you please explain (with code, for posterity) how this can be accomplished using a section block?

[youknowriad]

@mboynes The section block is not built yet #4900 but this plugin https://github.com/youknowriad/gcf has a free form area field you can use while the whole template is locked. I think it gives a clear idea how this can be achieved.

See the usage of InnerBlocks here https://github.com/youknowriad/gcf/blob/master/scripts/fields/fields/free.js#L16-L29

[niaccurshi]

Looking onto this conversation and seeing that now that the section (now "group") block is built, that this functionality of a "free-form" region as per @mboynes suggestion isn't something that can be achieved. If the template lock value is set then no content can be added to a group block, and there appears (to my eyes, please let me know if I've missed something) to be no way to isolate groups or other containers to allow them to still be editable even when the rest of the post type's template layout is locked in place.

I have to reiterate the original point as a theme developer for clients needs that the ability to lock down a template while giving freedom to maintain specific areas in that template with any type of blocks the client wishes is vital for the kind of work I do. Having checked out the GCF plugin I can see that the "free-form" area actually means "Free HTML" in that plugin rather than "an editable section that can still have blocks added and moved around even if the template for the post type is locked"

Do we have any word on whether the ability to lock down a template whilst unlocking groups or container blocks to allow their contents to still be edited as normal is part of the plans for this tool? I've been searching through issues for the last hour and can't seem to find anything that definitively says that it's planned?

[mboynes]

As a custom theme developer, this continues to be a significant need for me, and one that I find very difficult to work around with the available solutions. I wish very much that this would be re-opened until a viable solution is offered.

Envision a scenario where there should be fixed block at the top of an article (e.g. a block for a byline), then a fixed block at the bottom of an article (e.g. a block with sharing features). It is quite difficult to accomplish this if everything between the two blocks should function as usual, and if the fixed blocks should not be able to be moved or removed, etc.

For me, this means I end up implementing these features as PluginSidebar or PluginDocumentSettingPanel components, which is a major downgrade compared to what it could be, and leaves users with a significantly less-than-ideal UX.

[jomurgel]

Currently, the best solution I've found is to handle the placement of blocks on output using parse_block looping through the array of blocks, selecting those that match the ones I'm looking for plucking those from the original array and then outputting them separately in the location required. Using the group block could help keep certain elements together, but the use is the same.

Additionally, I might need to restrict multiple uses of a block for, say, a header block or something. Making sure that the supports object has multiple set to false.

Another option would be to force a template for the post type and disable the ability to move or insert blocks, but the extensibility of the templateLock is not great #8112 so this really defeats the purpose of using a block editor over something like ACF.

The immediate downside here is that the editor view could (and probably would) not match the frontend view and there is no real way for the user to easily determine what elements go where without prior knowledge.

It would be fantastic if there was a way to lock certain blocks at a certain index. A header block at 0 and footer block at 99 for instance if they exist.

I envision a lockLocation option in the supports object that would enable this ability.