Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Required blocks in templates #11273

Closed
jasperweyne opened this issue Oct 30, 2018 · 3 comments
Closed

Required blocks in templates #11273

jasperweyne opened this issue Oct 30, 2018 · 3 comments

Comments

@jasperweyne
Copy link

jasperweyne commented Oct 30, 2018

Is your feature request related to a problem? Please describe.
To provide you with some context, I'm building a plugin that provides a interface for organizing and participating in activities. An activity is a custom post type.

Describe the solution you'd like
Right now, the Gutenberg editor is designed to have "mandatory" input fields in the center, and optional input fields or content settings in the meta boxes, either on the side. or in the center below the main input field. Mandatory is, in the case of a default post or page, a title and some text. For custom post types however, this isn't necessarily the case. As an example, an activity in my plugin always(!) requires a price to be set.

Given the current state of affairs, the logical step for me would be to add a meta box where the user can set this and any other new properties. Designwise, however, a meta box suggests that those settings are optional, instead of mandatory. Thus, the experience becomes more cluttered than necessary.

Thus, the preference is to add fields to the main input area. With the classical editor, this can be achieved by adding actions to the edit_form_after_editor hook, whose callbacks render and handle extra input fields. Gutenberg doesn't use this hook, and as such, my code is not functioning.

As of this time, it is already possible to assign default templates to custom post types, through the template. A user may however remove these blocks, which would lead to incomplete data. My proposed solution is to add the option for blocks to be required in the template. From a user perspective, there is some form of precedence for this already, as titles could be viewed as a required block. (see #1914 , where the opposite of this issue is discussed). By adding this option, the usage of the Blocks API is encouraged.

Describe alternatives you've considered

  • Using meta boxes. As stated, it is a possible solution technically speaking. Designwise though, it is undesirable.

  • Hooking with the default edit_form_after_editor. Although I'm not familiar with the Gutenberg sourcecode, I suspect a high likelyhood of incompatible code, even if it were solely for design reasons.

  • Creating an additional hook, similar like edit_form_after_editor. In my perspective, this would lead to more cluttered code, which seems unnecessary given the flexibility of existing ways of interfacing with Gutenberg.

@jasperweyne
Copy link
Author

Somehow, I missed the concept of template locks. As such, this suggestion turns out to be redundant, therefore I will close it.

@paulkre
Copy link

paulkre commented May 1, 2019

I think the issue is still relevant. template_lock only prevents the user from deleting blocks and does not allow any other blocks. It would be nice if the blocks specified in the template array are required to save the post, while still allowing other blocks to be added.
This could easily be implemented with an additional value for template_lock like e.g. "required".

@pwkip
Copy link
Contributor

pwkip commented Apr 6, 2020

Related: #5208

There's a pretty lengthy discussion here. But to summarize: it looks like a lock will always be global. So locks cannot be added to individual blocks.

However, if I understand things correctly: it should be possible to create a template with 2 locked blocks. Where the first could be used for some custom settings, and the second block could be a container-block with nested blocks inside.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants