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

 manage fields, manage display, edit and delete

List of operations on a Block type

 edit, manage fields, manage display and delete

Proposed resolution

Rearrange the operations into the following order:

  1. manage fields
  2. manage display
  3. edit
  4. delete

Remaining tasks

do it.

User interface changes

Operation list order will be changed.

API changes


#1875252: [META] Make the block plugin UI shippable

Members fund testing for the Drupal project. Drupal Association Learn more


paravibe’s picture

Assigned: Unassigned » paravibe
Status: Active » Needs review
1.53 KB
PASSED: [[SimpleTest]]: [MySQL] 57,261 pass(es). View

Please review.

Status: Needs review » Needs work
Issue tags: -blocks admin page, -Spark, -scotch, -php-novice

The last submitted patch, 2027131-1-block-type-operations.patch, failed testing.

paravibe’s picture

Status: Needs work » Needs review
Issue tags: +blocks admin page, +Spark, +scotch, +php-novice
webchick’s picture

Issue tags: -Spark, -scotch +Blocks-Layouts

This seems like a good idea, but don't think it is related to Spark.

Tagging with the "Blocks-Layouts" tag that SCOTCH uses.

benjy’s picture

Status: Needs review » Reviewed & tested by the community

Yeah this looks good. These kind of UI issues are super annoying!

webchick’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Usability

Ok, 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.

webchick’s picture

Status: Needs review » Fixed

Wait, 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! :)

Berdir’s picture

This 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.

Automatically closed -- issue fixed for 2 weeks with no activity.