Allow to configure max path parts and relevant menus to optimize performance

1. +++ b/menu_trail_by_path.module
   @@ -3,3 +3,26 @@
   +  ];
   +  $form['third_party_settings']['menu_trail_by_path']['menu_trail'] = [
   +    '#type' => 'select',
   +    '#title' => t('Menu Trail Status'),
   +    '#options' => $options,
   +    '#default_value' => $menu->getThirdPartySetting('menu_trail_by_path', 'menu_trail'),
   

   we need config schema for this.

   not 100% sure about making this third party settings, makes it a bit complicated to have an overview/do initial configuration as you have to visit every menu. but ok for now I guess, we could also have a separate default setting and switch to "use default" in the future, but then we need a settings form and so on.

   Can we use a more descriptive name for this, maybe trail_source or trail_status? In case we add more options later.

2. +++ b/src/MenuTrailByPathActiveTrail.php
   @@ -77,6 +78,22 @@ class MenuTrailByPathActiveTrail extends MenuActiveTrail {
   +        case 'off':
   

   not sure if we want to make the options constants as we refer them in a few places.

   Also seems like the switch is actually a bit overkill and weird as two of three cases return. an if/elseif would be a lot shorter in this case. And the if ($status) actually doesn't need an if, as it will simply not match the condition if it is empty. And you can even provide an explicit default as third argument if you'd want.

1. +++ b/src/Form/MenuTrailByPathSettingsForm.php
   @@ -0,0 +1,80 @@
   +      '#size' => 30,
   +      '#title' => $this->t('Maximum path parts'),
   +      '#default_value' => $config->get('max_path_parts'),
   +      '#description' => $this->t('Configures how deep the module should go when resolving active trail links. Setting this value to zero will not limit the number of the path parts.'),
   +    ];
   +
   +    $form['trail_source'] = [
   +      '#type' => 'select',
   +      '#title' => $this->t('Trail Source'),
   +      '#description' => $this->t('Configures the default behavior for the trail source.'),
   +      '#options' => static::getTrailSourceOptions(),
   +      '#default_value' => $config->get('trail_source'),
   

   we probably need a bit more descriptions/help for this page.

   a) explain that it is recommended to configure the path parts and enabled menu to only those that require it, to avoid unnecessary performance overhead.

   b) that the trail source default can be overriden for each menu in the menu settings.

   c) that the path setting only applies when using the by path option.

   The more complicated options could be done with hook_help(), or we could use type radios, then you can put a description in [$key]['#description'] that describes each option a bit:

   off: no active trail at all. No performance overhead, useful for special/footer menus.

   default: active trail only for pages that have a menu link pointing to them, same as when not using this module.

   by path: Attempt to find a matching parent menu link based on the path structure. Slower, especially with a large amount of paths parts to consider.

   also, lets add this to the info.yml file as configure link.

2. +++ b/src/Path/CurrentPathHelper.php
   @@ -63,7 +72,14 @@ class CurrentPathHelper implements PathHelperInterface {
   +
   +    // Limit the maximum number of path parts.
   +    if ($max_path_parts = $this->config->get('max_path_parts')) {
   +      $path_elements = explode('/', $path, $max_path_parts);
   +    }
   

   can we also respect this in the getCid() method? And cut of the parts that we don't need from the path?

I've been testing this a bit, both functionality and specifically also performance.

* The default is actually not considered yet, which shows nicely that we need tests. You need to pass the default config as third argument to the getThirdPartySetting() call.

* On my site, with a lot of different menu blocks, this is a nice performance improvement when configured to be active only for a single of those 9 menu. However, the config get calls for all those menus aren't free. One option to improve that would be store the per-menu settings in the global config file as well, as a list keyed by menu. third party settings are nice when the config is loaded already and makes it easier to export and put things in default config, but I think we're OK with that not working and we don't have the config loaded yet. Another advantage would be that it gets much easier to have an overview of all your menus and how you configured them if it's on a single page.

* To provide some numbers, on my site, the relative part of doGetActiveTrails() goes down from 13% to 3.3%. Obviously this will vary a lot depending on how many menu blocks you have and for how many menus you actually need trail by path.

* The getCid() override doesn't actually help because we call the parent, which adds the route + arguments. I think it would make more sense to not call the parent at all. Both this implementation and the parent are also strange as they check for $this->cid but never set it? The CID that I used for testing looked like this: "active-trail:path:langcode:{$this->languageManager->getCurrentLanguage()->getId()}:maxpathparts:$max_path_parts:pathinfo:$path_info". The problem is that this might break the parent/default implementation that works on the route, so not sure about all this. Lets not touch getCid() here, we can open a separate issue if necessary.

* The remaining time is spent on \Drupal\menu_trail_by_path\Menu\MenuTreeStorageMenuHelper::getMenuLinks() and then the toUrl() calls. I'm not really sure how to improve that further, due to various different ways of generating a url, so filtering out before seems very hard.

Working a bit on this myself.

Ok, those tests aren't very clean but they should assert the basic functionality here. Existing tests are a bit strange because doing a single assert like that is bad for web test performance, as we set up a new environment for them all. Instead, something like that is usually done with a testAll() which calls doTestX() methods. Would make it immediately 5x faster or so.

No tests yet for the path lengths.

Found a problem in my patch, we currently save an empty string when menus are saved as third party setting, then this broke the default.

Fixed for now by doing the fallback differently, so it is also used when an empty string is stored. We might also want to change the entity builder to explicitly delete the key if empty instead.

Committing this. We've been using this for years on many sites without any issues, and the default behavior should remain unchanged.

Configured correctly, this can massively improve performance, e.g. if you have long paths and show menus where you don't need an active trail.