CHAPTER 16 ■ CACHING

How Caching Is Used Within Drupal Core

Drupal ships with ten cache tables by default: cache stores a copy of the variables table and the database schema and theme registry; cache_block stores cached copies of blocks; cache_bootstrap stores information that is used during the bootstrap process; cache_field stores information about fields; cache_image stores information about images; cache_menu stores cached copies of the navigational menus; cache_filter stores cached copies of each node’s content after it has been parsed by the filter system; cache_form is used by the form API to avoid form building when possible; cache_page stores cached copies of pages for anonymous users; cache_path stores cached URL aliases; and cache_update stores information related to the current version of Drupal and modules used on your site. It should be noted that the “Page cache” and “Block cache” settings at Configuration -> Performance affect only the page cache and block cache tables, not the other cache components within Drupal. In other words, filters, menus, and module settings are always cached.

Menu System

The menu system caches the router information that connects Drupal paths to callbacks. Any menu created by the menu module is cached, regardless of whether Drupal’s page caching is enabled. So to clear the menu cache, use the “Clear cached data” button on the Configuration -> Performance page, or call menu_cache_clear_all(). If you’ve made changes to the menus that will affect blocks, you might want to call the more aggressive menu_rebuild() function instead; the menu cache is cleared when menus are rebuilt. Examples of menus include Drupal’s Main and Secondary menus as well as the user navigation menu. Menus are cached on a per-user, per-locale basis. See Chapter 4 for more information on the menu system.

Caching Filtered Text

When a node is created or edited, its content is run through the various filters associated with its input format. For example, the HTML Filter format converts line breaks to HTML <p> and <br /> tags, and also strips out malicious HTML. It would be an expensive operation to do this for every single view of a node. Therefore, the filters are applied to the node just after it has been created or edited, and that content is cached to the cache_filter database table, regardless of whether Drupal’s page caching is enabled. See Chapter 12 for more information on input formats.

■ Tip The filter cache is the reason that changes to the default length of node teasers within the administrative interface take effect only after you resave each node. A quick workaround for this problem is to empty the cache_filter table so all node content is parsed and teasers built again. Or, if you are willing to have all caches cleared (including the filter cache), click the “Clear cached data” button on the Configuration -> Performance page.

368

CHAPTER 16 ■ CACHING

Administration Variables and Module Settings

Drupal stores most administrative settings in the variables table, and caches that data to speed the lookup of configuration data. Examples of such variables include the name of your site, settings for comments and users, and the location of the files directory. These variables are cached to a single row in the cache_bootstrap table, so they can be quickly retrieved, rather than making a database query for each variable value as it is needed. They are stored as a PHP array, so the cache value is serialized to preserve its structure. Any variable that uses variable_set() and variable_get() as its setter and getter functions will be stored and cached in this manner.

We have been discussing the bits and pieces that Drupal caches to optimize the more resourceheavy components of a site, but the biggest optimization Drupal makes is to cache an entire page view. For anonymous users, this is easily accomplished, since all pages look the same to all anonymous users. For logged-in users, however, every page is different and customized to each of their profiles. A different caching strategy is needed to cope with this situation.

For anonymous users, Drupal can retrieve the cached page content in a single query, although it takes a couple of other queries to load Drupal itself. Settings are found in the Drupal administration interface at Configuration -> Performance. The interface is shown in Figure 16-1. Let’s look at each setting in the following sections.

Figure 16-1. The administrative interface for the control of page-caching behavior

369

370

CHAPTER 16 ■ CACHING

Figure 16-2. This chart shows the request life cycle of an anonymous user visiting a site and the Drupal bootstrap process used to load the first page the visitor sees. Drupal attempts to load the requested page from cache as the second step in the bootstrap process.

371