10.4+: Cache issue (BreadcrumbBuilderInterface::applies() now takes a second $cacheable_metadata argument)

The interface language and the content language are not the same cache contexts unless something has changed in 10.4 the interface language can change per user and the content language can change per URL.

Also, why is url needed if url.path is already in the context? Here are the core contexts for reference:

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/syste...

I currently have the same issue on 10.3.10 and patch #2 solved it. The bug on my website was fixed by adding the "url" in addition to the "url.path" that was already included in the context.

I have a breadcrumb block, displayed within a hero block, which is in turn rendered inside the view template.
- I created 2 views A and B and enabled ajax for both of them.
- I added an exposed filter "Category" for view A and an exposed filter "Theme" for view B .
- I have a custom hero block created in a separate module that renders both the page title and the breadcrumb.

block template :

 {{ hero_heading }}
 {{ drupal_block('system_breadcrumb_block') }}

- In the view template, I call this hero block using:

{%
  set classes = [
    dom_id ? 'js-view-dom-id-' ~ dom_id,
  ]
%}
<div{{ attributes.addClass(classes) }}>
  {{ title_prefix }}
  {{ title }}
  {{ title_suffix }}
  
  {{ drupal_entity('block', 'test_heroblock', check_access=false) }}

- When I navigate to the path of view A, I get the correct page title in the breadcrumb which is Page A.
- I then filter using the exposed filter "Category". This is where ajax is being triggered and the hero block is rendered again and this time the breadcrumb also displays the right title which is "Page A".
- I then visit the path of view B, and initially, I get the correct page title which is Page B. However, when I filter using the exposed filter "Theme", ajax is triggered and the breadcrumb is rendered again but this time it displays the wrong title: "Page A" instead of "Page B", as if whenever views/ajax is detected, the cached title will always be "Page A".

Adding "url" solved it.

Added a link to the change record that is causing this. I am also experiencing this issue on 11.1.

Need to test further, but https://git.drupalcode.org/project/easy_breadcrumb/-/merge_requests/146 seems to work, based on similar changes in other modules, e.g. https://git.drupalcode.org/project/menu_breadcrumb/-/merge_requests/27/d... for #3495164: Missing route cachability metadata

Updated the IS. This is definitely caused by the CR I linked to earlier, and MR146 fixes the issue, so I'm marking RTBC.

I can see that that pattern used in MR146 is what is used for core modules that implement BreadcrumbBuilderInterface::applies since #3459274 was implemented. However, the cache contexts do not need to be added in the build step anymore ( https://git.drupalcode.org/project/drupal/-/commit/a75df83c57ed6269e0408... and https://www.drupal.org/node/2719721). I will create a new MR.

I've created a new MR and changed this back to Needs review.

@loopduplicate You wrote that "This has been fixed by a new argument for the ::applies() method that allows you to set cacheable metadata there. As a quality of life improvement, your ::build() code does not need to repeat whatever cacheable metadata you specify in ::applies().", but the change record in the linked issue (https://www.drupal.org/node/3459274) states that the change was made in 10.4. easy_breadcrumb currently supports 9.2+, so are you sure that it is safe to remove the call in :build()?

@ptmkenny OMG, I'm so rusty with contrib work. I'm sorry for not thinking of that; what a mistake on my part. I'll take a look at this later today with a fresh perspective and make sure to test against the old and newly supported core versions.

OK, thanks everyone. Sorry for the confusion. The code in MR !146 looks good to me. I've hidden the branch for the merge request I made.

Side note: I finally have a solid setup for xdebug with contrib projects and switching between core version to test, thanks to the great work from the DDev team. The ddev contrib addon is amazing and the docs for using xdebug in DDev worked great. I remember how much of a pain it was back in the days of WAMP/MAMP/LAMP stacks.

@loopduplicate No worries, it's hard to keep track of what needs to be compatible with what.

Yes, ddev is great and makes life a lot easier.

I'm adding CacheableMetadata and cacheable_metadata in a comment so it will come up in a search; I was about to create a patch because I couldn't find this issue at first.

Code looks good and almost ready to merge. Should have merged it a while ago. It looks like the Merge Request needs a rebase before we can merge.

Hi Greg. OK, there's a new merge request based off the current 2.x branch. The code is identical to the code in MR146. Cheers.

Based on the comments in #5, I think we should also add "url" to the cacheable meta data. What do you think? Code looks good tho!

OMG, it's so confusing reading the docs on cache contexts. I think it makes sense to have url but do we also need url.path too? At first my intuition was telling me no. But, when I read through https://www.drupal.org/docs/develop/drupal-apis/cache-api/cache-contexts , it's just not that clear. I think I might try tomorrow to write a test for this bug, which will be a challenge in an of itself, but I'll get there. Then, we can see if that helps us understand what to do. Perhaps enabling render cache debugging would help too.

also, it might make sense to have a separate bug for #5 instead of addressing it here

In #28, I wrote, "I think it makes sense to have url but do we also need url.path too? At first my intuition was telling me no."

I think my intuition was correct. Based on the text below from the Cache Contexts documentation (https://www.drupal.org/docs/develop/drupal-apis/cache-api/cache-contexts), we only need to have url, not both url and url.path. When url.path changes, then url will always change, so there's no need to specify both.

comparing (and folding) cache contexts becomes simpler: if both a.b.c and a.b are present, it's obvious that a.b encompasses a.b.c, and thus it's clear why the a.b.c can be omitted, why it can be "folded" into the parent

I think url makes sense. There will be cases where AJAX is used outside of views as well. I could imagine there being a need for the page title to change based on query parameters on some site. If we don't use url, then there would be no way for a site like that to use Easy Breadcrumb without custom code to override it.

So, I'll update the code here in the next comment.

Thanks to all who helped, including:
@escuriola, @rchallita, @ptmkenny, @malcomio, @greg boggs, @tolstoydotcom, @priti197, @joegraduate, and @csakiistvan