Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
This is a followup issue for #1535868: Convert all blocks into plugins.
- Currently, the block instance creation form requires that users specify a new machine name for each configured block instance.
- This is frustrating UX because most users will not care what the block's machine name is.
Proposed resolution
- Put the block title field first in the form.
- Hide the machine name field by default and automatically generate block machine names, like in the field UI.
- The block title is probably the best source for the default machine name.
Remaining tasks
This issue is postponed on two prerequisite issues:
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | Blockdots.png | 38.49 KB | Gábor Hojtsy |
| #4 | Blockname.png | 126.39 KB | Gábor Hojtsy |
| #4 | Vocabularyname.png | 24.7 KB | Gábor Hojtsy |
| block_machine_name.png | 9.17 KB | xjm |
Comments
Comment #1
xjmBojhan suggested just making the block title required, and instead adding a checkbox to hide it when the block is rendered. Then we get machine names for free. I think this is a good idea.
Comment #2
xjmIssue for the solution in #1: #1875260: Make the block title required and allow it to be hidden
Comment #3
xjmComment #4
Gábor HojtsyThis machine name field is confusing in various ways:
1. As stated in the issue opener, I need to enter a name, but it does not tell me what is the significance of providing a correct one. Unlike most other places (eg. vocabulary, etc.) the machine name is not automatically generated from the title of the block.
2. Although the issue opener suggests to generate the machine name based on "based on the plugin ID with a theme name and/or numerical index appended as needed", when the block is saved, it comes back with those pieces prefixed to the provided machine name. Not sure why would you want to replicate it in the machine name itself.
3. Also on that, when the machine name comes back, the value contains a prefix such as "plugin.core.block.bartik." before the value that I entered. This looks very puzzling given the description for the field stating the value *should not possibly have dots in it*: A unique name to save this block configuration. Must be alpha-numeric and be underscore separated. So the value I entered gets transformed, is not editable anymore and does not follow the rules of how it should be (vs. user docs):
4. The field is prominently placed high above in the form and is always visible (even after specified, even though not editable). Non-editable values are displayed elsewhere (such as in the field config forms) as regular form #item values, not disabled fields. Also, the prominence of the machine name tells me the value of it is significant to know for me, but I cannot figure out any reason why it would be:
Compare this with machine names on a vocabulary which gives the name the visual important it actually has (even though it actually lets people edit the machine name):
Comment #5
Gábor HojtsyAdditional image for previous comment.
Comment #6
xjmSee #1. We're now planning to make the title required and add a checkbox to show or hide it #1875260: Make the block title required and allow it to be hidden. Then, the title can be used as the basis for the machine name, and we can replace it with a machine name field like we use for taxonomy, fields, etc. Marking postponed on that issue for clarity.
Comment #7
Gábor HojtsyI assume we'll still need to resolve not displaying the full CMI name back, but keeping it as-is it was entered or calculated earlier to conform with the machine name guidelines.
Comment #8
xjmRe: #7: Yeah, I agree. I also repeatedly found myself wanting a separate property or method to get the machine name out of the config ID when I was developing. This isn't precisely the same as #1760358: Provide a way to extract the ID from a config object name because as far as config is concerned,
plugin.core.blockis the base of the name and theme.machine_name is the unique ID (though actually @timplunkett and @EclipseGc implied yesterday that the theme will be going away from the name eventually because the display will store the instances it wants, removing the need to load by theme name.)Comment #9
xjmThis patch will also be simpler with #1884762: Block forms should use #type => machine_name going in first. As @tim.plunkett points out in that issue, that part of this issue's scope is non-controversial. So let's postpone on that as well as the title visibility issue.
Comment #10
xjmComment #11
webchickThis is really, really terrible UX. Escalating to major.
Comment #12
Gábor HojtsyNow that #1884762: Block forms should use #type => machine_name landed, what should be done here?
Comment #13
webchickI don't actually know. It seems like it's doing this already? What am I missing?
Comment #14
tim.plunkettAh! In #1820834: Change #type machine_name default 'source' element to 'label', the default was switched from 'name' to 'label'. So we didn't need anything more than #1884762: Block forms should use #type => machine_name after all.
Comment #14.0
tim.plunkettUpdated issue summary.