We have Craft CMS v3 using multi-sites.

We are using cache to cache whole pages based on the absolute URL as some URLs have query parameters which seem to be ignored when not using a key. So the absoluteUrl is working. Our cache code is:

{% cache using key craft.app.request.absoluteUrl unless craft.app.request.getSegment(1) == 'members' or craft.app.request.getSegment(1) == 'data-summary' %}

One of the sites, Korean, has a few pages that result in an Internal Server Error as follows.

Next Twig\Error\RuntimeError: An exception has been thrown during the rendering of a template ("SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'cacheKey' at row 1

This leads me to believe the URL is longer than 255 characters as the database column templatecaches.cacheKey is varchar(255).

The SQL is:

The SQL being executed was: INSERT INTO `templatecaches` (`cacheKey`, `siteId`, `path`, `expiryDate`, `body`) VALUES ('https://www.mydomain.com/ko/%C3%AC%C2%86%C2%8C%C3%AA%C2%B0%C2%9C/%C3%AC%C2%9D%C2%B8%C3%AC%C2%A6%C2%9D-%C3%AB%C2%B0%C2%8F-%C3%AC%C2%88%C2%98%C3%AC%C2%83%C2%81-%C3%AB%C2%82%C2%B4%C3%AC%C2%97%C2%AD/%C3%AC%C2%B5%C2%9C%C3%AA%C2%B3%C2%A0-%C3%AA%C2%B8%C2%B0%C3%AC%C2%97%C2%85-%C3%AC%C2%88%C2%98%C3%AC%C2%83%C2%81?__geom=%E2%9C%AA', 26, 'site:ìê°/ì¸ì¦-ë°-ìì-ë´ì­/ìµê³ -기ì-ìì', '2020-11-16 18:41:26', '[all the page content here]')"). in /home/mydomain/craftcms/templates/_layout.twig:84

The page URL in the browser has Korean symbols of course, so I guess its too many characters once converted to ascii.

I tried changing it to a Longtext as per another similar issue with a different column, but MySQL will not allow it due to the cacheKey being in the index.

Recommended solutions were to remove the column from the index but to be honest I dont want to start messing with things like this without guidance from Craft.

Is there a Craft recommended approach to this issue please?


1 Answer 1


Is there a Craft recommended approach to this issue please?

The simplest solution would be to update to Craft 3.5+

Template cache data went from being stored in the database to the file system, so this won't be an issue for you anymore.

  • Oh right, good. Had not updated yet as its a troublesome task due to composer problems every time we want to update. I’ll give it a go as I get other issues relating to the database size from template caches. Commented Nov 16, 2020 at 21:42
  • This solved the problem. Thanks a lot! The update went OK too... its just previously and on a cloned site we have issues with Composer errors so I am often reluctant to update. But was OK this time and all seems to work. Hope this also reduces the DB size from from 10Gb! Commented Nov 21, 2020 at 13:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.