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
Block types should be analogous to content types in terms of their UI. We don't want to introduce subtle anti-patterns.
The list of operations on a Block type should be presented in the same order as the list of operations on a Content type.
List of operations on a Content type
List of operations on a Block type
Proposed resolution
Rearrange the operations into the following order:
- manage fields
- manage display
- edit
- delete
Remaining tasks
do it.
User interface changes
Operation list order will be changed.
API changes
None.
Related Issues
Comments
Comment #1
paravibe CreditAttribution: paravibe commentedDone.
Please review.
Comment #3
paravibe CreditAttribution: paravibe commented#1: 2027131-1-block-type-operations.patch queued for re-testing.
Comment #4
webchickThis seems like a good idea, but don't think it is related to Spark.
Tagging with the "Blocks-Layouts" tag that SCOTCH uses.
Comment #5
benjy CreditAttribution: benjy commentedYeah this looks good. These kind of UI issues are super annoying!
Comment #6
webchickOk, now that I actually look at this, I'm wondering if we should get the UX team's input on this first.
Reason being is because the decision to make those lists in two different orders was done deliberately, afaik. By far the most common thing you want to do when building out a content type is go in and manage fields. Add some, tweak some, remove some, whatever. "Edit" is something you usually only visit once, to set your default publishing options or something.
Versus in blocks, I don't actually think "Manage fields" is the 99% case there; I think it actually is "Edit." Managing fields on blocks will be relatively rare, in my estimation.
So this basically comes down to which is the biggest UX problem: that the two of these are inconsistent (which the patch fixes) or that one or the other is going to require hitting the drop button for the most-accessed link in the list (which would be introduced by this patch).
I kind of lean towards them being inconsistent at this point, but let's see what folks say.
Comment #7
webchickWait, wait, wait. Sorry, I'm dumb. I get it. This is the place where you're setting up custom block types (not wrangling blocks themselves), so the two are totally analogous.
In that case!
Committed and pushed to 8.x. Thanks! :)
Comment #8
BerdirThis conflicted with #2021063: Use hook_entity_operation_alter() for manage fields and manage display links, which unifies the generation of these manage field * links and puts it in an alter hook. Re-rolled to take this into consideration.