Drupal Cache Form

To totally unlock this section you need to Log-in

There is well-known issue with fast-growing table cacheform. This table stores Drupal form cache and it isn’t cleared when you flush all cache or run cron. Also you can struggle with problem of fragmentation with InnoDB tables on active delete/insert operations. This module provide functionality to solve this problem. Drupal stores its external and internal data structures efficiently to enhance repeated users’ access when performing application-level caching. This isn’t the information that a site visitor sees in itself but forms a critical factor in constructing any page.

To create a page Drupal needs to make several database queries. This can slow down websites with a lot of traffic. To make websites faster Drupal stores web pages in a cache.

Drupal Cache Form Template

It is a good practice to clear caches when moving a site from one host to another.

Clearing the caches can also useful when installing new modules or themes, and as a first step in troubleshooting. Clearing caches is relatively harmless. Sites might slow down for a bit afterwards while the cache fills back up.

Note that there are sometimes caches other than the Drupal cache that can affect website performance. For example, some hosting services use a cache called 'Varnish' to improve performance. Also, individual web browsers maintain their own caches on a user's computer or device.

Clearing the cache

  • The easiest way to clear the Drupal cache is to go to Administration > Configuration > Development > Performance;
  • Click the button 'Clear all caches';

Other ways of clearing the cache


Run drush cc all.

To clear the cache, even if Drupal is broken, you can run the following command:

drush sql-query 'DELETE FROM cache'

sql-query executes sql queries in the database where Drupal is installed.

Run update.php

Running update.php (http://example.com/update.php) is another way of clearing the cache. If you cannot login or have no user 1 rights you will need to set $update_free_access = TRUE; first in /sites/default/settings.php. Do not forget to set this back to FALSE afterwards.

A PHP snippet

Use the following code to clear specific cache type from within a module. If you want to clear all the caches similar to the functionality of the button on the 'Performance' page, call this snippet for all tables beginning with the word 'cache'.

db_query('DELETE FROM {cache};');

In the database

Use phpmyadmin or another tool to access the database tables and TRUNCATE (empty, not remove) all tables that start with cache_.

A PHP-file to clear caches and rebuild the routing tables

Be careful not to leave this on the server as anyone can clear caches if they know the file name. Create a file named clear.php with the code below. Place the file in the Drupal base directory and run it by browsing to http://example.com/clear.php.

Drupal 6

include_once './includes/bootstrap.inc';

Drupal 7 version

// define static var
define('DRUPAL_ROOT', getcwd());
// include bootstrap
// initialize stuff
// clear cache

Clearing specific entries in cache tables

The Drupal cache API can be used to clear specific items. Caching back ends can be switched (to memcache, to flat files, etc.) without having to rewrite any code.

cache_clear_all('content:' . $MYNID, 'cache_content', TRUE);

The example above clears all items from cache that start with 'content:$MYNID*'. To ONLY remove one specific row, drop the $wildcard parameter (the 'TRUE' statement in the function call) and change the format of the first parameter to omit the asterisk, which functions as a wildcard.

cache_clear_all('content:' . $MYNID . ':' . $MYNID, 'cache_content');

How to clear main cache tables through mySQL query

We can delete the Drupal cache through mysql also. For that you need to use following mysql commands in phpmyAdmin or through mysql command line.

The main cache tables are the following:

DELETE FROM cache_filters;
DELETE FROM cache_menu;
DELETE FROM cache_page;
DELETE FROM watchdog;

NOTE: the watchdog module monitors your system and records system events in a log (in the watchdog table) you can review. This helps you get a quick overview of activity on your site. Since the log records events in sequence, it can also be useful for debugging site errors. It can grows over 300MB periodically if Drupal is configured to log all info.

Note that starting with Drupal 6.x, Watchdog has been replaced by the dblog and syslog modules. Dblog is similar to watchdog; Syslog allows Drupal's logging to be integrated with the server's syslog facility.

Clear cache from phpMyAdmin

To clear the Drupal's cache from phpMyadmin select all tabels those begin with cache as image below:

After you've sent the deletion command you will be directed to a confirmation page with sql statements like this:

Do you really want to :

TRUNCATE `cache`;
TRUNCATE `cache_apachesolr`;
TRUNCATE `cache_block`;
TRUNCATE `cache_content`;
TRUNCATE `cache_filter`;
TRUNCATE `cache_form`;
TRUNCATE `cache_menu`;
TRUNCATE `cache_page`;
TRUNCATE `cache_path`;
TRUNCATE `cache_rules`;
TRUNCATE `cache_update`;
TRUNCATE `cache_views`;
TRUNCATE `cache_views_data`;

Confirm clicking OK and the DB cache will be cleared.

  1. 4.6.x includes/bootstrap.inc cache_set()
  2. 4.7.x includes/bootstrap.inc cache_set()
  3. 5.x includes/cache.inc cache_set()
  4. 6.x includes/cache.inc cache_set()
  5. 6.x includes/cache-install.inc cache_set()

Stores data in the persistent cache.

Drupal Cache Form Template

The persistent cache is split up into several cache bins. In the defaultcache implementation, each cache bin corresponds to a database table by thesame name. Other implementations might want to store several bins in datastructures that get flushed together. While it is not a problem for mostcache bins if the entries in them are flushed before their expire time, somemight break functionality or are extremely expensive to recalculate. Theother bins are expired automatically by core. Contributed modules can addadditional bins and get them expired automatically by implementinghook_flush_caches().

The reasons for having several bins are as follows:

  • Smaller bins mean smaller database tables and allow for faster selects andinserts.
  • We try to put fast changing cache items and rather static ones intodifferent bins. The effect is that only the fast changing bins will need alot of writes to disk. The more static bins will also be better cacheablewith MySQL's query cache.


$cid:The cache ID of the data to store.

$data:The data to store in the cache. Complex data types will be automaticallyserialized before insertion. Strings will be stored as plain text and arenot serialized. Some storage engines only allow objects up to a maximum of1MB in size to be stored by default. When caching large arrays or similar,take care to ensure $data does not exceed this size.

$bin:(optional) The cache bin to store the data in. Valid core values are:

  • cache: (default) Generic cache storage bin (used for theme registry,locale date, list of simpletest tests, etc.).
  • cache_block: Stores the content of various blocks.
  • cache_bootstrap: Stores the class registry, the system list of modules,the list of which modules implement which hooks, and the Drupal variablelist.
  • cache_field: Stores the field data belonging to a given object.
  • cache_filter: Stores filtered pieces of content.
  • cache_form: Stores multistep forms. Flushing this bin means that someforms displayed to users lose their state and the data already submittedto them. This bin should not be flushed before its expired time.
  • cache_menu: Stores the structure of visible navigation menus per page.
  • cache_page: Stores generated pages for anonymous users. It is flushedvery often, whenever a page changes, at least for every node and commentsubmission. This is the only bin affected by the page cache setting onthe administrator panel.
  • cache_path: Stores the system paths that have an alias.

$expire:(optional) Controls the maximum lifetime of this cache entry. Note thatcaches might be subject to clearing at any time, so this setting does notguarantee a minimum lifetime. With this in mind, the cache should not beused for data that must be kept during a cache clear, like sessions.

Use one of the following values:

  • CACHE_PERMANENT: Indicates that the item should never be removed unlessexplicitly told to using cache_clear_all() with a cache ID.
  • CACHE_TEMPORARY: Indicates that the item should be removed at the nextgeneral cache wipe.
  • A Unix timestamp: Indicates that the item should be kept at least untilthe given time, after which it behaves like CACHE_TEMPORARY.

See also



archiver_get_infoin includes/common.inc
Retrieves a list of all available archivers.
book_menu_subtree_datain modules/book/book.module
Gets the data representing a subtree of the book hierarchy.
CacheClearCase::testClearArrayin modules/simpletest/tests/cache.test
Test clearing using an array.
CacheClearCase::testClearCidin modules/simpletest/tests/cache.test
Test clearing using a cid.
CacheClearCase::testClearWildcardin modules/simpletest/tests/cache.test
Test clearing using wildcard.


includes/cache.inc, line 141
Functions and interfaces for cache handling.



To clear a specific cache item..

alanom commented

..pass $cid and $bin to the misleadingly named cache_clear_all()

Update Link

spuppett commented

Example of using cache in function

alandarev commented

Wrong expire time?

chrisroane commented

Shouldn't the expire time be added to the current time?

Like this:

Logic error

RogerB commented

cache_set() is being called on every invokation. It should only be called when the data is rebuilt.

Use REQUEST_TIME rather than

drewish commented

Use REQUEST_TIME rather than time().. but yeah you'd need to treat it as a timestamp so 360 would be some time in 1970.

Edit: this was supposed to be a reply to chrisroane's comment but I guess I clicked the wrong reply link.

Good catch!

chrisroane commented

Couldn't Get This to Work

chrisroane commented

The only way I could get the caching to work as expected in a custom function was to also use &drupal_static(__FUNCTION__) ..Below is a simplified version of what I got working:

General Cache Wipe Details

technicalknockout commented

The $expire option CACHE_TEMPORARY says

Indicates that the item should be removed at the next general cache wipe.

How is the next general cache wipe triggered? Is it triggered by cron jobs? Is it triggered every hour or every day?


forestmars commented

Drupal Cache Form Pdf

@technicalknockout Yes, it happens on cron run by default, so how often depends on what you have cron set to. Alienware windows 10 drivers.

General Cache wipe

xeeshangulzar commented

Is there any way that i can wipe cache after some minutes?

Drupal Clear Cache_form Table

Try the Elysia cron module

bfr commented

Try the Elysia cron module for more fine grained control of the cron service. If that is not enough, implement cache_clear_all() or take a look at the code of drupal_flush_all_caches() for more ideas.

Not 100% sure but i think Rules could also do this.

Expire cache with Unix timestamp using strtotime()

sebas5384 commented

Example with strtotime(), maybe for a more clean and easy way for getting a cache to expire in 6 hours:

This way I can have a select form element with values like '+1 hour', '+6 hour', '+1 day', etc..


Very nice and clean example.

cbiggins commented

Poor Documentation

rvelhote commented

This is very lame but the $expire parameter, when set in a form of a Unix timestamp, is ignored if the parameter cache_lifetime set in admin/config/development/performance is not set to X minutes.

This will cause cache_get to return expired entries!

Sadly, the description for the cache_lifetime parameter is incorrect because it mentions 'cached pages' so one would assume that it's applicable to whole pages and not specific cache entries.

This is not documented and should not even happen otherwise it destroys the purpose of setting an expire parameter.

Expire does nothing

rcls commented
Drupal 8 template cache

I can confirm there is an issue with the $expire parameter. I spent last night testing this issue out with a simple retrieval of data and storing it to the cache and setting the $expire to time() + 300 (5 minutes). I then printed out the time, the time the cache was set and expiration. The time the cache was set and expiration worked fine, but I noticed that even after 30 minutes this cache would still persist.

A simple way to go around this was to check if time() was bigger than the $cache->expire and then clearing out the cid with cache_clear_all(). An example code is below.

if ($cached = cache_get('db

rakesh.gectcr commented

if ($cached = cache_get('db_index', 'cache')) {
$tables = $cached->data;
else {
$tables = drupal_get_schema();
// Setting the data to drupal cache.
cache_set('db_index', $tables, 'cache', CACHE_TEMPORARY);