You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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".
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.
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.The text was updated successfully, but these errors were encountered: