Ability to display "the menu selected by the page"

I'm using this patch besides the one in #26 to at least get this thing working descently. But this is by no means done.

Re. #27

I just ran into the same issue, I guess modifying MenuBlock::getDerivativeActiveTrailIds() should be enough.

  protected function getDerivativeActiveTrailIds() {
    $menu_id = $this->getDerivativeId();

    // => If menu_id = "multiple_menu_block", then do custom logic.

    return array_filter($this->menuActiveTrail->getActiveTrailIds($menu_id));
  }

In the meantime I'm using classic Menu blocks (from core) and not the multiple one.

Update the patch to support versions equal/greater than v1.8

Currently none of the patches above works: 1.11

lolgm → changed the visibility of the branch 8.x-1.x to hidden.

lolgm → changed the visibility of the branch 3089134-ability-to-display to hidden.

lolgm → changed the visibility of the branch 3089134-ability-to-display to active.

I created !MR22 for version 1.11, based on previous patches.
I also implemented a proposed solution to the block title, problem referred in #27 and #28.

mitechworld → changed the visibility of the branch 8.x-1.x to active.

MR22 works fine. (tried the patch from it against latest release)

Can we get feedback from the maintainers?

@weseze Thanks for the feedback.

Using this functionality I found two use cases where the implementation was incomplete.

1st - When a node is present in more than one menu, it is not possible to "prioritize" a menu to be the active one.

2nd - When the current node is not present in any menu, and if the option "Hide on pages not included in menu" is not activated, the expected behavior is to render the default menu, however the default menu in the multiple block is the first menu from the configuration list, may not be the intended default.

These two limitations occur due to the block configuration format being just a table with select, not sortable.

In this way, I converted the selection table into a table with the option of dragging, so that it is now possible to select the menus you want and classify them in order of "priority".
Therefore, the first menu selected will also be the default menu if there is no active menu on the current node.

Attention!!!
This is a breaking change.
To be able to make this change, the format in which the selected menus were being saved in the block configuration changed, according to my tests, the only problem is having to configure the multiple menu blocks again.

Patch of changes described in #41

Patch #42 is incomplete, this is the patch with changes #41.

Please don't make breaking changes that require manual work to fix... This is a hell when maintaining 100's of sites.
Can't we instead create an update/post_update/deploy hook to fix things?

I think I explained myself badly.

The breaking change I mentioned is in relation to the previous patches in this issue, that is, the block MultipleMenuBlock (multiple_menu_block) which is under development and will be added in this issue.

In this new patch that I suggested, the MultipleMenuBlock will undergo a change in its configuration, so if someone is going to test this new patch on the same instance that tested one of the previous ones, they will have to configure the block again to update its config.

That said, I don't think an update hook is applicable here as it only concerns changes to the component under development.

Doesn't work on latest 1.13

Reroll #43 to 1.13.

patch 47 works fine for us. (it did need manually updating the block settings from previous patch...)