Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By kamal hasan on
Hello,
we had issue with a Drupal 10 multilingual site where all the blocks disappeared.
Environment
- Drupal 10
- Multilingual site (English + Arabic), `content_translation` module enabled
- Site had been running fine for an extended period (more than a year)
What happened
A DBA was preparing a routine production → preproduction database clone.
As part of shrinking the dump size, they ran `TRUNCATE cache_entity` on production before exporting (as cache tables are throwaway data and often the largest tables in a Drupal DB).
After that the site started rendering all the theme regions empty.
There was no deploy, no code change, no module install/uninstall, no CI/CD activity at the time only the `cache_entity` truncate.
Symptoms
1. Watchdog flooded with PHP warnings (thousands per minute):
Warning: Undefined array key "content_translation_status"
in Drupal\Core\Entity\Sql\SqlContentEntityStorage->loadFromSharedTables()
(line 599 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php)
Same warning for: `content_translation_uid`, `content_translation_created`,
`content_translation_changed`.
2. Views fail with:
InvalidArgumentException: A valid cache entry key is required
Drupal\views\ViewsData->get()
3. `/admin/structure/block` shows all regions empty in the UI, but `SELECT COUNT(*) FROM config WHERE name LIKE 'block.block.%'` returns 201 block configs — they exist, with correct `theme:` and `region:` values matching the active default theme.
4. `drush cr` completes successfully but emits the `Undefined array key` warning hundreds of times during the rebuild.
5. First affected URL in the logs is an Arabic-translated node, consistent with the hypothesis that translated content loads were first to hit the missing columns.
We tried to do drush cr, drush updb, nothing worked until the cach_entity content was restored.
The Question
- What could be the reason for this issue where the website blocks disappeared after the cache_entity truncating?
- Could it be a missing table but masked by the cache? if yes how come regular drush cr didn't reveal this issue earlier?
Comments
Are you using a caching
Are you using a caching mechanism like Redis or Memcache?
My initial thoughts are, seemingly like yours, that deleting a cache_* table shouldn't be a problem.
But then my next thought is, maybe it doesn't matter. I would do some tests and see if drush cr truncates that table - if it does, and it doesn't crash your site, then maybe don't truncate that table directly.
If you really need to determine the reason, maybe look for some custom code that requires a value in that table that it calls directly. That or a mismatch between Redis or mecache and the DB are the only ideas I have off the top of my head.
Contact me to contract me for D7 -> D10/11 migrations.
Do you have the same cache_*
Do you have the same cache_* tables as before? I've used MySQL to truncate cache_* tables lots of times without issue, but maybe one of the tables was deleted.
What I'd do is add code to loadFromSharedTables() to show what's in the variables it uses and what it's looking for. It looks like it could be related to translations. I'd probably do a db backup and then change the code to fake those keys existing. The warnings might be hiding the actual error message.
Once again: do a db backup before changing core code.
Available for paid support, module development, migrations, consulting...