Joomla 1.6. caching implemented #jab11

Preview:

DESCRIPTION

Slides from Joomla 1.6. Caching workshop at Jandbeyond conference 2011

Citation preview

JOOMLA! 1.6. CACHE//implemented //

JOOMLA! CACHING TYPOLOGY

page cache componentview cache

progressive cache

module cache

function/callback cache

output cacheraw cache

smallerunits

modules

module

functions

component

template

lim

ited

to

com

pone

nt

lim

ited

to

mod

ules

lim

ited

to

mod

ule

// Cache types coverage //

page cache

// Cache types coverage //

component view cache

// Cache types coverage //

progressive cache

// Cache types coverage //

module cachee.g. mod_latestnews

// Cache types coverage //

function cacheoutputraw cache

// Cache types coverage //

Caching smaller units insideframework and extensions (not directly visible)

multiple caches = multiple layers

// Cache types coverage //

multiple caches = multiple layers

// Cache types coverage //

PAGE CACHE

Takes snapshots of entire pages including everything - component, modules, plugins and a template.

The widest and the least flexible approach of all caching options.

// enabled by core system plugin -> site administrators choice //

PROGRESSIVECACHE

Takes snapshot of each unique modules set (typicaly each page)

Affects all modules - works as layer above module cache.

// enabled by setting cache level to progressive -> site administrators choice. For fine grained control over each module cache use conservative caching level. //

MODULE & COMPONENT VIEW CACHE

Most widespread cache type, sometimes equaled with J caching in general.

Performs well in the speed terms

Disables any user<->extension<->framework

interaction until a cached copy has expired

Not suitable for any components or modules that react to user actions or render frequently changing content.

COMPONENT VIEW CACHE

Takes an array of url parameters and their types to create

Cacheid.

A replacement for a previous unsafe way which took the whole URL and so opened the doors for DOS attacks via random parameters/values added to request

// Old cacheid created from URL retained for backwards compatibility if there are no $safeurlparams (to be removed in 1.7) //

Com_contact controler usage example:

$safeurlparams = array('id'=>'INT', 'catid'=>'INT', 'limit'=>'INT', 'limitstart'=>'INT', 'filter_order'=>'CMD', 'filter_order_Dir'=>'CMD’, 'lang'=>'CMD');

parent::display($cachable,$safeurlparams);

MODULE CACHE

5 different modes of operation, 3 of them are to be set from module XML file, while 2 are meant to be used from within the module itself.

Default is backwards compatible oldstatic mode that requires no changes to a module.

MODES TO BE SET IN XML

Static - one cache file for all pages with the same module parameters. Recommended for modules that don't change.

Oldstatic - 1.5. definition of module caching, one cache file for all pages with the same module id and user aid. Default for backwards compatibility

MODES TO BE SET IN XML

Itemid - changes on itemid change.

Suitable for most dynamic modules that change per page - like menus, breadcrumbs, content images etc

In addition to cache field that was required in 1.5 there is

now new hidden field in module XML called cachemode that sets any of the above modes.

<field name="cachemode" type="hidden" default="static"><option value="static"></option></field>

MODES TO BE CALLED FROM INSIDE THE MODULE:

Safeuri - id is created from URL params array, as in component view cache

Use this mode if you module depends on url parameters other than Itemid to display content (e.g. module that display different image for each content category).

Modeparams property is an array of url parameters and their filter types

MODES TO BE CALLED FROM INSIDE THE MODULE:

Id - module sets own cache id's according to it's own formula.

Most flexible, but not needed often.

Modeparams property is calculated id.

To use this modes rename 'cache' field in xml to

'owncache' field and call from within the module's main php file.

JModuleHelper::ModuleCache

// actually a shortcut to cache callback to avoid code duplication in every module //

An example that uses safeuri mode

$list = modRelatedItemsHelper::getList($params) :

$cacheparams->modeparams = array('id'=>'int','Itemid'=>'int');$cacheparams->methodparams = $params;$cacheparams->method = 'getList';$cacheparams->class = 'modRelatedItemsHelper';$cacheparams->cachemode = 'safeuri';$cacheparams = new stdClass;

$list = JModuleHelper::ModuleCache ($module, $params, $cacheparams);

FUNCTION / CALLBACK CACHE

The first of flexible caching types that enable us to differentiate between various parts of the extension and cache only those parts that are cacheable, while keeping dynamic parts uncached.

Caches results of function calls

Records (cacheID) based on the arguments passed to the function

Often useful to cache model methods and keep views uncached.

Example useModel performing expensive queries or similar operations is run only once to create a larger pool of data which is then further manipulated inside the view (sorting, pagination, calculations etc.)

OUTPUT CACHE

Caches output of some part od the script

Records based on id passed

Basically output buffering with caching

RAW CACHE

Caches any data units

Records based on id passed

Fully controlled by the coder – what, when to store, how to classify stored units (cache id).

Highly useful when we are dealing with finite number of reusable data units

Example useHigh number of possible combinations of relatively small number of units – e.g. products in online store. No point to cache multiple parameter searches, cache each product separately.

Other examplesExpensive queries, remote XML, thumbnails, reusable texts or any reusable data set.

Also useful to pass large amounts of data between different parts of application (e.g. steps in click flow)

Used in Joomla core: list of components, list of modules, menu tree, available languages, user groups, html renderers etc.

Raw cache get and store are easily accesed by passing '' (empty string) as cache controller to

Data is auto serialized / deserialized

Locking & unlocking are performed automaticaly

JFactory::getCache

Recommended