Problem/Motivation

Steps to reproduce

To use reusable, non-reusable custom blocks

Proposed resolution

Add additional check if such block exists.

We have reusable and non-reusable custom blocks. In /layout_builder_restrictions/src/Plugin/LayoutBuilderRestriction/EntityViewModeRestriction.php file function alterBlockDefinitions () there is a code $delta = $content_block_types_by_uuid[$uuid]; '$uuid' takes value from $definitions whole list of block without reusable restriction, and '$content_block_types_uuid' is taken from $this->getBlockTypeByUuid() where there is a restriction by 'block_content_field_data' reusable value. So we get underfined array key error.

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:

Comments

yugro created an issue. See original summary.

shreya_th’s picture

Assigned: Unassigned » shreya_th
shiv_yadav’s picture

Assigned: shreya_th » Unassigned
Status: Active » Needs review

Hello yugro, I have followed given reproduced step but not got any error so please provide proper reproduced step as well.
my configuration drupal -9.5.10

yugro’s picture

Hello shiv_yadav, I think I found the issue, it was that we had reusable value == 0 in block_content_field_data table and such blocks were cropped by getBlockTypeByUuid() function in EntityViewModeRestriction.php. Though in the same file there is an expression $delta = $content_block_types_by_uuid[$uuid]; , where $uuid includes all blocks in DB and $content_block_types_by_uuid includes only those with reusable==1. I have updated DB for the value and it works. But perhaps it would be good to have check if $uuid is in_array();

shiv_yadav’s picture

Hello @yugro,
As i have made changes as per your requirements in the code in file EntityViewModeRestriction.php . Also created MR for this . Kindly review the changes .

Thank you.

yugro’s picture

Hi @shiv_yadav,
Unfortunately I am not a maintainer or the module to review MR.

shiv_yadav’s picture

Thanks for responding, take clone this MR on local. verify your issue.it's fixed or not.

mark_fullmer’s picture

Title: Underfined array key for non-reusable blocks » Undefined array key for non-reusable blocks
Priority: Critical » Normal
daddison’s picture

I might have been unclear on the steps to reproduce. I enabled layout builder and layout builder restrictions for basic page on vanilla Drupal 10.1.5. I added one reusable and one inline Basic block to a node. Then I created a custom block type and added one reusable and one inline instance of the custom block to the node. I could not reproduce the error.

mark_fullmer’s picture

Status: Needs review » Postponed (maintainer needs more info)

Based on the comment in #10 above, I'm going to mark this as "Postponed (Maintainer needs more info)." We need specific steps to reproduce. Thanks!

mark_fullmer’s picture

Version: 8.x-2.19 » 3.x-dev
jjchinquist’s picture

We can confirm this issue on Drupal 11.3.3 with layout_builder_restrictions 3.0.4 and layout_builder_browser 2.1.0.

**Steps to reproduce:**

1. Install Drupal with `layout_builder_restrictions` and `layout_builder_browser` modules enabled
2. Create a content type with Layout Builder enabled and per-entity overrides allowed
3. In the Layout Builder restrictions for that content type's default display, configure "Allowed blocks" for at least one category (this triggers the `third_party_settings` check at line 96 to not return early)
4. Create a node of that content type
5. Use Layout Builder on that node and add an **inline block** (non-reusable custom block) to the layout, then save the layout
6. Go back to the Layout Builder for the same node and click "Add block" to browse available blocks

**Result:** PHP warning is logged:
```
Warning: Undefined array key "{uuid}" in Drupal\layout_builder_restrictions\Plugin\LayoutBuilderRestriction\EntityViewModeRestriction->alterBlockDefinitions() (line 118)
```

**Root cause:**
`getBlockTypeByUuid()` queries `block_content_field_data` with `reusable = 1`, so it only returns reusable blocks. But the `foreach` loop at line 104 iterates over all `block_content` provider definitions, including inline (non-reusable) blocks. When it hits an inline block's UUID at line 118, the key doesn't exist in `$content_block_types_by_uuid`.

This appears to be the same issue as #3463518.

The fix in issue 3463518 MR !34 appears to work best.

jjchinquist’s picture

Status: Postponed (maintainer needs more info) » Reviewed & tested by the community

Our project now includes the patch #9 from ticket 3463518 which fixes this issue as well.

We have verified that it works via playwright tests that execute now without the warning.

reviews & tested by the community.

benjifisher’s picture

Status: Reviewed & tested by the community » Postponed (maintainer needs more info)

@jjchinquist:

Thanks for describing your steps to reproduce. Unfortunately, even when I follow your steps, I do not see the problem.

I installed Drupal 11.3.3 with the Standard profile, layout_builder_restrictions 3.0.4, and layout_builder_browser 8.x-1.8. That is the latest release of layout_builder_browser. You mentioned Version 2.1.0, but that is not listed on https://www.drupal.org/project/layout_builder_browser/releases.

I think your steps to reproduce leave out at least two steps:

  1. Create a reusable block (from /block/add/basic).
  2. Configure layout_builder_browser.

I do not think (1) needs any more detail. Without (2), I was not able to add any block to the layout on my test node.

On /admin/config/content/layout-builder-browser, I added a block category and then added two blocks to the category: my test block and all inline blocks of type Basic block.

mark_fullmer’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

Closing as a duplicate of #3463518: [Layout Builder Browser compatibility] PHP Warning: Undefined array key "id" in EntityViewModeRestriction.php. Noting that jjchinquist, yugro, shiv_yadav and daddison should be credited if/when that issue is fixed.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

benjifisher’s picture

@mark_fullmer:

I gave them credit on this issue.

Note the automatic comment (#17) after you closed this issue: it asks you to review the contribution record.