Problem
When you expose let's say a menu as a block, you have an "Edit menu" and a "Configure block" contextual action on the block. Now if you go to either, you can edit the name/title/label of the object. They are the same textual value. If you edit the menu title/label, it will not change the block, if you edit the block label, it will not change the menu. Although the block is initialised with the object's title, they are disconnected afterwards.
David Rothstein posts in #663946: Merge "List links" page into "Edit menu" page that he sees this is a major usability issue. I'm opening this issue to make sure this is tracked, but not sure how how a Drupal 7-like solution would work in the Drupal 8 system. Quoting David:
I think it's probably a pre-existing problem in Drupal 8 (not introduced here), but a pretty major one. In Drupal 7 this would only happen if you deliberately configured the block to have a different title than the menu to begin with. By default, though, it would work as expected. In Drupal 8, there doesn't seem to be any way to have the block title automatically linked to the menu title any more?
Same holds true for custom block instances, etc.
Proposal
Discuss and figure out if we have any good ideas for this.
Beta phase evaluation
Issue category | Bug because it is a feature regression from Drupal 7 |
---|---|
Issue priority | Major because it is a significant usability issue |
Prioritized changes | The main goal of this issue is usability. |
Comments
Comment #1
Gábor HojtsyTrack for usability.
Comment #2
David_Rothstein CreditAttribution: David_Rothstein commentedI think this is a major regression; it would be a pretty fundamental feature to lose.
To create a menu block and have its title automatically be the same as the menu (even when someone goes back and edits the menu later) is the default behavior in Drupal 7 and seems like a basic expectation to me.
Comment #3
Bojhan CreditAttribution: Bojhan commentedIs this a regression? I am a little afraid of saying "just title" there surely are other properties that will influence this.
Comment #4
Gábor HojtsyI believe it is only the title. Drupal 7 had this weird feature where the block title inherited the object title IF you put an empty string in the title and otherwise you could override it. If you *really* wanted an empty block title, you needed to put in
<none>
I think.Comment #5
Dave ReidCould this be fixed by having some kind of token replacement used in these types of block titles by default? If it's provided with a menu context, replace title with [menu:title] by default?
Comment #6
sun#5 sounds like a stellar idea to me. Potentially allows us to get rid of quite some custom code and one-off hacks for various special conditions.
Comment #7
Gábor HojtsyWell, if we'd go with tokens, it would be [menu:title], [author:name], [view:display:title], etc. depending on where the block comes from. I'm not sure that is very discoverable as-is, but if implementing modules would inject their suggested token at least into the description then that can be a stop-gap, if we have no better ideas.
Comment #8
Bojhan CreditAttribution: Bojhan commentedThis does make sense, I am worried without a browser though people will have no clue what that is? We can probably add it in the description.
Comment #9
klonosI'm not sure this is a bug. I see it as a feature in certain use cases. If we tie these back together, can we make it the default option but still have a way for it to be customized?...
I was thinking that perhaps the block title should be pre-populated with the menu title (or what have you) and be disabled/grayed-out by default. There'd be a link to the menu edit form in order to hop and edit the actual object, then save/cancel and return back to the block edit form (that would be now updated with the new title). There'd also be some description text stating that this value is kept in sync with the menu/object title, but there'd be a "override" link (similar to the edit machine name) that would allow the sync to be broken and a custom block name to be used. If the title is overridden, this "override" link would become a "reset" link that would restore sync between the block title and the object title.
Sounds sane?
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedMaybe not a bug per se, but an important feature that disappeared. The disappearance of a feature is not itself a feature :)
But yes, we should definitely retain the ability to override the default and customize the title (same as Drupal 7).
Unfortunately doesn't seem like there's an easy way to go back to how this used to work (since titles are now used to generate machine names)... but as mentioned above the old UI wasn't great anyway. Some kind of greyed out default plus auto-generated machine name makes sense to me too for a new UI.
Comment #11
yoroy CreditAttribution: yoroy commentedJust tested this and the situation is still the same indeed. Edit the menu title and the block title is not updated. Edit the block title and the menu title is not updated. (Additionally, I don't see 'Edit menu' contextual links on any menu either, probably a different issue)
Comment #12
metzlerd CreditAttribution: metzlerd as a volunteer and commentedTriage Comments:
Comment #13
tstoecklerNote that Views Blocks already allow re-using the view title or optionally overriding, which is exactly the pattern we want here. We just need to make the functionality a bit more generic and use it for menu blocks.
Comment #14
xjm(Saving proposed issue credit for discussion and triage participants at LA.)
Comment #15
tim.plunkettLet's get some tests for that menu block example.
Comment #17
heddnIt seems like we are trying to do something in this space already. See
template_preprocess_block()
. But the title doesn't exist at #title, rather in $variables['elements']['content']['#block_content']->info->value;It would also be nice to have a config option on the block to allow override of the block content label directly from the block config.
Comment #28
catchRe-categorising this as a feature request, the old feature has been gone for eleven+ years now, also doesn't seem to be blocking contributed modules or similar.