When working with complicated page layouts that contain many different sections, it can sometimes be a little difficult to know which layout you're currently configuring when you're modifying a section, especially if you have a lot of similar, but slightly different, layouts in your theme.
In my opinion, it would be helpful from a UX perspective to provide basic information about the active layout at the top of the configure section form. I also think it would be helpful if individual themes could override and style that however they saw fit, but obviously provide a sensible default in core.
For example, something like this (although certainly, not all three pieces of information would be necessary to display out of the box):
For what it's worth, I have found a temporary solution until we can come up with something more permanent:
/**
* Implements hook_theme().
*/
function rs_theme($existing, $type, $theme, $path) {
return [
'rs_layout_details' => [
'variables' => [
'label' => NULL,
'icon' => NULL,
],
],
];
}
<h2>{{ label }}</h2>
{{ icon }}
<hr>
/**
* Implements hook_form_FORM_ID_alter().
*/
function rs_form_layout_builder_configure_section_alter(&$form, FormStateInterface $form_state, $form_id) {
$label = $form_state->getFormObject()->getCurrentLayout()->getPluginDefinition()->getLabel();
$icon = $form_state->getFormObject()->getCurrentLayout()->getPluginDefinition()->getIcon(60, 80);
$form['layout_details'] = [
'#theme' => 'rs_layout_details',
'#label' => $label,
'#icon' => $icon,
'#weight' => -9999,
];
}
Note: Obviously I'm manually setting a weight here to force it to go to the top. I'm sure there's a better alternative in a core-based solution.
I think the above could be accomplished with the following, but I'm not married to this process if someone has a better idea:
'#theme' => 'layout_builder_configure_section_form_header' field to the render array (probably need to ensure it's at the top). Unlike my form_alter approach above, we shouldn't need the patch from
#3044117: Add getter for layout object in Layout Builder's ConfigureSectionForm →
to accomplish this, as we'll have access to that protected data.TBD
TBD
TBD
TBD
Active
11.0 🔥
Last updated
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This has been inactive for 3+ years with no updates or further requests. I don't mind this idea though. Most layouts I use are distinct enough to not need this but I can see how it could be useful. I'm not sure if it should live in Core or be a contrib module though.
This is pretty easy to set up in ConfigureSectionForm if we go for the core route, screenshot attached of a few options
Bumping this for visiblity so others can give opinions.