TypeError on latest dev

Can you give clear steps to reproduce?

I spent time on this and i could not reproduce the issue.

I am checking the issue on drupal: 8.9
Php: 7.4

Steps is did:
- I initailly configured a menu block using Alpha verison
- I configured a block so that we can have a block that folows clases alter done by the latest versions.
- I then moved to the latest dev version and properly clear caches and i could not see the error mentioned here: https://www.drupal.org/project/menu_multilingual/issues/3366412 🐛 TypeError on latest dev Postponed: needs info .
As i suspect its maily block definition being cached so we can include a hook to rebuild the block definfition in a hook_update_n attached , please review.

Hi @Jelle_S, @vakulrai.

I tried reproduce the issue without success. Here are cases that I've tried:

• fresh Drupal 9.5.10 + standard profile + menu_multilingual 8.x-1.x-dev. Works as expected w/o any errors.
• test case from @vakulrai, fresh Drupal 9.5.10 + standard profile + menu_multilingual 8.x-1.0-alpha3, then ugdate menu_multilingual to 2.x. Works as expected w/o any errors.

@Jelle_S. Could you provide more information about how to reproduce this issue?

Thank you @vakulrai.
I'm thinking too that this error might caused by caching. Let's try to get more reports and then include hook update?

Jelle_S and I did some research together on how to reproduce this on a clean Drupal install:

1. Install and enable the menu_multilingual and block_field modules
2. Create a field on a node or a paragraph with type 'Block (plugin)' and set display mode to 'block field'
3. Edit the field or paragraph and set the field value to a menu reference
4. View the node

I updated the issue summary and this issue also accurs on 2.0.0

@Jonasanne, @Jelle_S I followed described steps to reproduce the problem using DrupalPod with clean Drupal 10.2 and confirm getting this error too.

That's happens because block_field deals with block plugins, but menu_multilingual operates on block entities (normally created from block layout admin interface).
This means that other modules that use the same approach as we do are also do not work with block_field module. For example block_css.

I created here ✨ Provide a way to alter the block plugin configuration form Needs review initial patch to make it compatible with such module like this.

What we can do right now just to check block type and if it's not a block entity try to provide dummy block entity. Example:

  public static function setBlockProcessing(&$build) {
    /** @var \Drupal\block\BlockInterface $block */
    $block = $build['#block'];

    if (!$build['#block'] instanceof BlockInterface) {
      $block = Block::create($build['#block']->getConfiguration() + ['plugin' => $build['#block']->getPluginId()]);
    }
    // ...
  }

As proposed from @vlad.dancer I created a patch to check the block type.

Thanks @Jonasanne! Let's check if tests will be launched on status change.

Ok, looks like tests are not triggered for patches, https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... →
I assume it is better to use MRs.

Problem with that is that the dummy block entity doesn't have the third party settings. Before the change in 🐛 Settings no longer stored as third party settings Fixed was introduced, it worked with menu block (plugins) that were referenced by the block_field module. I added some extra lines to the patch that makes it work again, but I'm not sure this is the behavior we want by default? It seems to work for our use case tho.

This issue descibes only issue "TypeError: Drupal\menu_multilingual\Helpers::isMenuBlock(): Argument #1 ($block) must be of type Drupal\block\BlockInterface". And code guard if (!$build['#block'] instanceof BlockInterface) { just added to prevent operating on non-block entity instances, that we need to add anyway.

@Jelle_S I'm not sure why you hardcoded settings for all block plugins in your patch.

dummy block entity doesn't have the third party settings

That's fine, because modules that are managing blocks should be responsible for making them compatible with core block related modules.

Here is example how context module added such compatibility:

1. for adding 3rd party settings into block plugin edit form https://git.drupalcode.org/project/context/-/blob/5.x/src/Reaction/Block...
2. for rendering block plugin https://git.drupalcode.org/project/context/-/blob/5.x/src/Plugin/Context...

I suggested for block_plugin https://git.drupalcode.org/project/block_field/-/merge_requests/16/diffs... to use the same approach.

> it worked with menu block (plugins) that were referenced by the block_field module

I think 🐛 Settings no longer stored as third party settings Fixed issue has been created in 2018 and lot's of code were updated in drupal core, context, block_field modules since that time.