Cache clear on menu edit

I am going to reuse this issue for the feature request for clearing the cache based on menu edits if and only if the menu is used for config.

Here's a link to the capitalize port issue https://www.drupal.org/project/easy_breadcrumb/issues/2917195.

Hey,
I have looked a bit into this issue and for me this is not generally true. When I change the title also the breadcrumb changes if the url path has changed. If url path doesn't change (if you change a character or word in title that gets excluded from the path then breadcrumb stays the same).

    // Because this breadcrumb builder is path and config based, vary cache
    // by the 'url.path' cache context and config changes.
    $breadcrumb->addCacheContexts(['url.path']);
    $breadcrumb->addCacheableDependency($this->config);

One possibility would be to check whether current path is from some kind of entity and add a cacheTag.

This patch adds a cacheTag to breadcrumbs of nodes and taxonomy terms.

Would you mind adding a code comment for this one?

With route parameters it is very easy to check entity type. And if the type is node or taxonomy term I add Cache Tags to the breadcrumb object that invalidates cache when this particular entity is updated.

Is this what you meant or did you mean that I put a comment into code?

I understand now. Should we add User? Will this then not work on content entities such as a Comment or Groups page?

~G

drupal debug:entity gives you list of entities (which can be then added as cacheTags to breadcumb object) and their types. So for comments we should also add comment (and user for user - that would work if user changes username). For group page I am not sure since I am not familiar with this module.

Yea, what if someone updates the title of a view that's being used in the crumb without changing the url... same problem yes?

There's gotta be a way to easily expire whenever the current page changes.

Yeah views are another issue here. But the problem is a bit more persistent. If you change for example the view title in view settings and you don't change the page link where this view is shown then, whenever you visit this page you will see the old view title in crumb (until the cache is cleared). I investigated the issue and I did not find a way how to solve this problem globally. We can find some solutions for users, comments and views (and so on) but the obstacle I can not overcome is how to check whether the internal path corresponds to existing entity type and what are its cache tags then.

I see! Thank you! I'll follow up with some folks who know for some advice and see what we can do to fix this. Ideally, I need this to work for any generated custom entity type. My employer, ThinkShout, uses a lot of custom entities. Can't have breadcrumbs breaking for my team!

There used to be a setting in Drupal 7 that did this for blocks... I'm sure there's a way.
~G

https://twitter.com/wimleers/status/984823835479429120

#7 kinda fixes it, and does work, but it's of course not a generic solution. Manually constructing cache tags is something you should avoid whenever possible.

The "proper" way would be Entity::getCacheTags(). If you could, then you could do something that's even better:

$breadcrumb->addCacheableDependency($entity);

We can get the parameters by calling $route_match->getParameters(). And we can then check if they're instanceof EntityInterface. Better yet … we can do this generically, not just for entities, but for any route parameter that is a cacheable dependency, entity or otherwise!

Here's a patch to get you started :) It already implements a superset of the patch in #7.

This still doesn't work for views. At first I though it doesn't work for config entities but it works for webforms by adding "config:webform.webform.<webform_id>", "config:webform.settings", "webform:<webform_id>" cache tags. It also works for taxonomy_vocabularies and node_types (I checked those 4).

For views we would need to add "config:views.view.<view_id>. You can get this cache tag if you load a view manually and call getCacheTags() method, but you don't get view entity through $route_match->getParameters(). You only get 'view_id' through which we could manually create cache tags. I wonder why is it, that it doesn't work for views? We also need to find out for which other content types this method doesn't work.

Mind adding custom logic to correct the views cache tag? We should follow up with a core issue like I did for delete form page titles, but it helps if we have a work around I can point the core developer to in Easy Breadcrumb.

Like this?

$parameters = $route_match->getParameters();
    foreach ($parameters as $key => $parameter) {
      if ($key === 'view_id') {
        $breadcrumb->addCacheTags(['config:views.view.' . $parameter]);
      }
      // TODO: only consider route parameters that actually are being used below!
      if ($parameter instanceof CacheableDependencyInterface) {
        $breadcrumb->addCacheableDependency($parameter);
      }
    }

This still doesn't work for views.

For e.g. the /taxonomy/term/{taxonomy_term} view, you mean?

You only get 'view_id' through which we could manually create cache tags

You could do View::load($view_id).

I wonder why is it, that it doesn't work for views? We also need to find out for which other content types this method doesn't work.

Views is special, because a view for e.g. the /taxonomy/term/{taxonomy_term} path does not result in a view route parameter being loaded, hence it's not detected automatically.

Well I looked into cache tags of vocabulary ( structure > taxonomy > List terms ), because I wondered whether breadcrumb will get cache tags - and it gets them. So If I change the label of vocabulary and the machine name stays the same the breadcrumb changes to the new label.

Do you think it is better to load view to get its cache tags rather than manual tag creation like I proposed?

Do you think it is better to load view to get its cache tags rather than manual tag creation like I proposed?

It's using the API, which means that it'll also work on sites with modules that alter Views' config entities. It is more expensive, so if profiling shows this is critical for performance, then go with your proposed approach specifically for Views!

I went with the lazy way to add a view cache tag. ;)

Well I am leaning more towards Wim's solution with loading a View and then addCacheableDependency, but I have no idea how much heavier this solution is.

It is much heavier. This is a sensible compromise for now. OTOH: premature optimization is the root of all evil…