If you can only answer part of the question set below, I still thank you in advance.

Here is a list of tables in my site's database with "cache" in the name:

  • core:
    • cache
    • cache_filter
    • cache_menu
    • cache_page
  • contrib:
    • cache_content
    • cache_views
    • imagecache_action
    • imagecache_preset


  • Q1 Can all of these safely be emptied directly (e.g. via MySQL command) (implied if Yes - don't need backing up)
  • Q2 Are of these emptied by devel's module clear cache function?
  • Q3 I have multi-site set up sharing all data except theming/layout/navigation (see http://groups.drupal.org /node/11795). Should the contrib cache tables be site-specific even if CCK fields, Views and Imagecache are set up to be shared?
  • Q4 Is it safe to assume the answers to the above would also hold true for other contrib module tables containing cache in the name, or do these questions need to be asked of each module developer separately?

Side note for context: I'm tracking all changes to my whole Drupal stack via SVN and am consistently getting "checksum mismatch" errors on commit regarding the cache_content table.


Michael Hofmockel’s picture

1 You can safely empty all but imagecache_* tables. They are not holding temp data but configurations related to imagacache.
2. Yes, devel empties the cache tables. Imagecache tables are storing configuration settings not cached data and is not emptied by devel.
3. Some yes, some no. For instance, I think the cache and cache_content contain theme specific encoding. To be on the safe side I would let each site have their own cache* tables.
4. Assume nothing and you can't lose. But in general the ones starting with cache* can be emptied. Imagecache is a different beast and the cache it creates is not stored in a database but as actual files. The imagecache files can be flushed at anytime but this would not be a database query.

Sharing the cache tables with sites with different themes may be the source of your errors.

*I personally avoid sharing content across sites at all costs. It is problematic to say the least. Sharing users is difficult but do-able. Sharing content is full of pitfalls and is the bulk of the questions generated around the topic of Multisite.

Michael Hofmockel
iMed Studios

Open Source | Open Access | Open Mind

HansBKK’s picture

Thanks very much Michael for your very detailed and helpful response.

Regarding the pitfalls on sharing content, I'm taking the approach of sharing ALL the content, and only making the more superficial elements (theming, layout and navigation) site-specific. I'm hoping this will avoid the obvious problems of trying to share only particular types of content.

If you could have a look at my SETTINGS.PHP and point out any potential problems I'd be even more grateful than I am for the time you've already taken; looks like the link got munged in the main message: