Problem/Motivation

The "Block description" "field" renders at the top of the modal form within the content area. In my experience it displays the block type of the block being created/edited. My issue with this is that it's not really a field because it isn't something the user can edit. In reality it's only there to give the user context.

Proposed resolution

I think it would be much more appropriate for it to appear as part of the modal title. This would save room in the content area and avoid user confusion.

proposed change

I've done some digging and found that the current title "Configure block" comes directly from web/core/modules/layout_builder/layout_builder.routing.yml.

I realize that this request may be beyond the scope of this module because it touches on core Layout Builder and Block configuration form issues. However, I don't think these user interface issues with block configuration will ever be addressed in core. There's just too many other more pressing issues. The way I see it, the purpose of this module is already to improve the usability of Layout Builder by replacing core functionality, so maybe it could improve the actual block configuration form as well? Maybe there's a chance to replace the title before the jQuery UI Dialog is initialized?

Thanks for considering and thanks for this module. Layout Builder would be unusable without it. I'll do some more digging into this.

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#9 block-title-in-modal-title-3196147-9.patch5.91 KBmaskedjellybean
#8 interdiff_2-8.txt697 byteslasseitorp
#8 block-title-in-modal-title-3196147-8.patch5.75 KBlasseitorp
#5 block-title-in-modal-title-3196147-3.patch5.75 KBlasseitorp
#2 block-title-in-modal-title-3196147-2.patch5.72 KBmaskedjellybean
#2 Screen Shot 2021-02-03 at 11.29.59 AM.png63 KBmaskedjellybean
Screen Shot 2021-02-02 at 10.41.06 AM.png60.2 KBmaskedjellybean

Issue fork layout_builder_modal-3196147

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

maskedjellybean created an issue. See original summary.

maskedjellybean’s picture

maskedjellybean
Location Portland, OR
commented
StatusFileSize
new Screen Shot 2021-02-03 at 11.29.59 AM.png63 KB
new block-title-in-modal-title-3196147-2.patch5.72 KB

Here's a patch for this.

The reason I created _layout_builder_modal_dialog_options() was because the code to set the dialog options was duplicated in layout_builder_modal_link_alter() and in layout_builder_modal_contextual_links_alter(). I figured it makes sense to move it all to a function to avoid duplication.

I hope I'm correct in assuming that if $plugin_base_id is "inline_block" we can assume the entity_type is block_content.

The code to determine the title is more opinionated than I would've liked. The label for views_bock blocks are apparently not set in the Layout Builder SectionComponent configuration, so I had to dig into the view to construct the title.

Steps to test:

  1. Apply patch.
  2. Go to the Layout tab of of a node which contains several blocks.
  3. If using Chrome, open inspector and go to Application tab. Under Storage > Session Storage, click on your domain. In right pane, search for "contextual". Click the Clear All button.
  4. Refresh the page.
  5. Click the "Configure" contextual link for a block.
  6. The modal window should open. The modal title should contain either the block type or the block label (similar to what would've appeared in the Block description field).
  7. You should not see the "Block description" field.

expected result

lasseitorp made their first commit to this issue’s fork.

lasseitorp opened merge request !2

lasseitorp’s picture

lasseitorp commented
StatusFileSize
new block-title-in-modal-title-3196147-3.patch5.75 KB

I ran into the issue Notice: Undefined index: uuid in /web/modules/contrib/layout_builder_modal/layout_builder_modal.module on line 107 as the UUID in the $route_parameters isn't always set, so I added a guard on line 107.

lasseitorp’s picture

lasseitorp commented
edurenye’s picture

edurenye commented

@lasseitorp When you publish a new patch, if is not a rebase, always publish an interdiff, makes it easy to review the changes. Could you please provide the interdiff file?

Thank you!

lasseitorp’s picture

lasseitorp commented
StatusFileSize
new block-title-in-modal-title-3196147-8.patch5.75 KB
new interdiff_2-8.txt697 bytes

@edurenye Sorry here is a new patch with a interdiff.

maskedjellybean’s picture

maskedjellybean
Location Portland, OR
commented
StatusFileSize
new block-title-in-modal-title-3196147-9.patch5.91 KB

I'm sorry for uploading another patch without an interdiff. I really did try to generate one using https://github.com/mglaman/drupalorg-cli. However when I run drupalorg issue:patch 3196147 I get NID from argument is different from NID in issue branch name.. What's your preferred method of generating an interdiff?

I realized that the previous patches were causing contextual links to not render when editing the default layout for a content type. My latest patch doesn't truly fix this, because it simply doesn't move the block description into the modal title when editing the default layout. This avoids the error that causes the contextual links not to render, but ideally we'd want the block description as the modal title in all situations. The problem is that if the current page is not a node (which is the case when editing the default layout), I don't know how to get the layout.

edurenye’s picture

edurenye commented

Hi @maskedjellybean, I never used this tool that you mention.
I just use normal git diff command.
I create a branch apply the previous patch, commit make my changes on top, then a diff to previous commit will give you the interdiff and a diff with dev branch will give you the patch.

johnwebdev’s picture

johnwebdev commented

Thanks for the work so far. I'm wondering if this should be a configurable behavior?

+    $nid = str_replace('node.', '', $route_parameters['section_storage']);
+    $node = Node::load($nid);

Any fieldable entity can have Layout Builder so we shouldn't assume that it always will be a node here, but can be any entity.

+    $layout = $node->get('layout_builder__layout');

Does this target the override section storage? (If the node has been overriden), what happens if you try open Layout Builder Modal now on the default layout for the content type?
I think we can also use OverridesSectionStorage::FIELD_NAME instead. But is there any way we can determine the actual section storage here?

jayhuskins’s picture

jayhuskins
he/they
commented

This approach does not work for newly created blocks, because they do not exist in the database. So if you create a block and then edit it before saving, then it won't match any of the components in the database and will get ignored.