- 1.15.x includes/common.inc block_caching
- 1.12.x includes/common.inc block_caching
- 1.14.x includes/common.inc block_caching
- 1.10.x includes/common.inc block_caching
- 1.11.x includes/common.inc block_caching
- 1.13.x includes/common.inc block_caching
- 1.7.x includes/common.inc block_caching
- 1.8.x includes/common.inc block_caching
- 1.9.x includes/common.inc block_caching
Constants that define each block's caching state.
Modules specify how their blocks can be cached in their hook_block_info() implementations. Caching can be turned off (BACKDROP_NO_CACHE), managed by the module declaring the block (BACKDROP_CACHE_CUSTOM), or managed by the core Block module. If the Block module is managing the cache, you can specify that the block is the same for every page and user (BACKDROP_CACHE_GLOBAL), or that it can change depending on the page (BACKDROP_CACHE_PER_PAGE) or by user (BACKDROP_CACHE_PER_ROLE or BACKDROP_CACHE_PER_USER). Page and user settings can be combined with a bitwise-binary or operator; for example, BACKDROP_CACHE_PER_ROLE | BACKDROP_CACHE_PER_PAGE means that the block can change depending on the user role or page it is on.
The block cache is cleared in cache_clear_all(), and uses the same clearing policy than page cache (node, comment, user, taxonomy added or updated...). Blocks requiring more fine-grained clearing might consider disabling the built-in block cache (BACKDROP_NO_CACHE) and roll their own.
Note that user 1 is excluded from block caching.
common.inc, line 98
- Common functions that many Backdrop modules will need to reference.
||The block is handling its own caching in its hook_block_view().|
||The block or element is the same for every user and page that it is visible.|
||The block or element can change depending on the page being viewed.|
||The block or element can change depending on the user's roles.|
||The block or element can change depending on the user.|
||The block should not get cached.|