The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Hi there, we are using this module on our website that has some long paths that require different metatag titles/content.
I've noticed that the function metatag_cache_default_cid_parts() can generate the same cache key for different paths, which we are finding is causing incorrect metatags to be generated for some pages:
Eg. for the page:
http://www.visitnsw.com/destinations/snowy-mountains/kosciuszko-national...
metatag_cache_default_cid_parts returns "output:global:en:200:http:www.visitnsw.com:/:destinations/snowy-mountains/kosciuszko-national..."
And for
http://www.visitnsw.com/destinations/snowy-mountains/kosciuszko-national...
metatag_cache_default_cid_parts also returns "output:global:en:200:http:www.visitnsw.com:/:destinations/snowy-mountains/kosciuszko-national..."
It's this conflict that's causing them to "share" the metatag data, whichever page gets hit first gets the correct data cached, but any other pages that share this cache key use the incorrect data.
Is there a way around this? Is there a reason the return value of metatag_cache_default_cid_parts cannot just be a MD5 or SHA1 hash generated from the string before it is truncated?
Am happy to roll a patch for this tomorrow, but just wanted to log this as an issue.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | metatag-n2487179-5.patch | 532 bytes | damienmckenna |
Comments
Comment #1
thomwilhelm commentedAdding patch of proposed solution.
Comment #2
thomwilhelm commentedComment #3
thomwilhelm commentedActually on inspection of the database table cache_metatag could this value instead be trimmed to 255 chars rather than 128 chars?
Comment #4
damienmckennaCould you please take a look at #2474427: Drop the output cache and let me know if it's an acceptable temporary solution?
Comment #5
damienmckennaDoes this help? It changes the truncated cache $cid to 255 chars instead of 128.
Comment #6
damienmckennaI committed the small string truncation patch.
Comment #8
thomwilhelm commentedYep no worries I'll test out your changes hopefully later this week. Thanks for your help.
Comment #9
thomwilhelm commentedHi again Damien. Yes, both patches fix the issue for entities.
However the pages that generate the long URL's in our application are not Drupal entities, it's a custom module that wildcard matches anything in the URL after "/destinations/" and then does some processing to return the correct content from an external database (it's a wonderful system... not). I hope I've explained that clearly :)
Anyway changing the limit to 255 is fine for our case, it's a bit of a unusual case I know...
I was wondering if a better solution that handles all cases could be just check inside metatag_cache_get() if 'metatag_cache_output" is TRUE, and if it's not then just return NULL. I might experiment with this further myself.