Caching Pages and Partials

LemonStand includes a flexible caching system integrated with the CMS, which allows you to cache partials and whole pages, significantly increasing the website performance and response times. This page explains how you can use these features on your store. Please read the caching API article to learn how to configure the caching system and choose a suitable caching provider - file-based, APC or Memcached.

How the caching works

You can enable caching for any page or partial. When LemonStand renders a page, it first checks whether there this CMS object is cached. If it is cached, it checks whether the cache item it is not expired. If the object is not expired, the cached content displayed. Otherwise LemonStand generates the content and caches it. You can manage the page and partial expiration parameters. They can expire depending on the time-to-live interval, or when the store catalog updates, or when CMS or blog content updates. Also, you can create different cache versions for different customer groups, customers and page URLs.

Which content to cache

Although you can cache any page and partial, there is no point in caching all the website content. Cache pages or page elements which require much computing on the server side, update rarely and do not depend on the current user behavior. Good candidates for caching: 

• Category page
• Featured products partial
• Category menu partial
• Partials which perform complex queries: best selling products, "customers also buy" partials, etc.

Bad candidates for caching:

• Cart page
• Customer profile page
• Customer order list

Caching partials

To cache partials, pass the caching parameters to the third parameter of the controller's render_partial() method. Example:

<?
  $this->render_partial('my_partial', 
     array(), // No partial-specific parameters (to simplify the example)
     array(
        'cache'=>true,// Enable caching
        'cache_vary_by'=>array('url'), // We are going to reuse this partial on different pages, but its content can be different for different pages so we want to create different partial cache versions for different pages
        'cache_versions'=>array('catalog'), // The partial should be recached then the catalog updates
        'cache_ttl'=>1800 // Recache each 30 minutes
    )
  ) ?>

{{ render_partial('my_partial', 
     {},
     {
        'cache': true,
        'cache_vary_by': ['url'],
        'cache_versions': ['catalog'],
        'cache_ttl': 1800
    }
) }}

There are 4 parameters which manage the partial caching:

• cache - enables the caching.
• cache_vary_by - array or string (for a single value parameter). Specifies parameters the cache should depend on. For example, you can create different versions of a partial cache for different pages (if you reuse a partial on different pages), or for different customers, customer groups, and other parameters. See detailed description below.
• cache_versions - array or string (for a single value parameter). Allows to specify names of content types which versions the partial cache should depend on. You can use the following values in this parameter: cms, catalog, blog. If you specify the catalog content type, the partial will be automatically recached if you update the catalog (add/update/delete products, apply catalog price rules, update categories, etc). The cms and blog parameters work in the same way. but watch updates of the CMS and blog content.
• cache_ttl - cache item time-to-live, in seconds. Please note, that file-based caching does not support per-item TTL setting and always use the global TTL value specified in the caching configuration parameters.

The cache_vary_by parameter can accept system-level parameters and custom parameters. LemonStand creates different cache items for each parameter sets. You can use the following system-level vary by parameters:

• url - generates different keys for different page URLs
• customer - generates different keys for different customers
• customer_group - generates different keys for different customer group
• customer_presence - generates different keys depending on whether a customer is logged in or not

The system-level parameters should be specified as strings. Some examples of cache_vary_by system-level parameters:

...
  // Create different cache versions for different URLs and for customer logged/non logged in conditions
  'cache_vary_by'=>array('url', 'customer_presence'), 
...
  
...
  // Simplified syntax for a single parameter - use a string instead of array
  'cache_vary_by'=>'url', 
...

...
  // Create different cache versions for different URLs and for customer logged/non logged in conditions
  'cache_vary_by': ['url', 'customer_presence'], 
...
  
...
  // Simplified syntax for a single parameter - use a string instead of array
  'cache_vary_by': 'url', 
...

You can also use any custom parameters, if you want to create different partial cache versions depending on them. For example, if you have a product list partial on the category page, and you have a product sorting option drop-down list, you can cache product list for each sorting option. Example: 

// Create different cache versions for different URLs and different values of the $sort_order variable
'cache_vary_by'=>array('url', 'sort_order'=>$sort_order), 

// Create different cache versions for different URLs and different values of the $sort_order variable
'cache_vary_by': {'url': 'url', 'sort_order': sort_order}, 

Caching partials and AJAX

When LemonStand updates partials via AJAX, it does not applies any caching by default, because AJAX request does not contain any caching configuration (and it would be wrong to pass such information through AJAX requests). If you want to use display cached partial content through AJAX, the only way to do it is to wrap the render_partial() call with caching parameters into another partial, and then render it with an AJAX request.

Caching pages

To cache pages you should declare the get_page_caching_params() function on the Pre Action Code field of the Action tab of the Create/Edit Page form. The function should have 3 reference parameters: $vary_by, $versions and $ttl. The function should return TRUE if the page should be cached. Function example:

// Cache the page, with no parameters. The page will be re-cached when the cache 
// expires (basing on the TTL parameter specified in the caching configuration)
function get_page_caching_params(&$vary_by, &$versions, &$ttl)
{
  return true;  
}

// The cache should be updated on CMS content update
function get_page_caching_params(&$vary_by, &$versions, &$ttl)
{
  $versions = array('cms');
  
  return true;  
}

// The cache should be updated on CMS content update, and there should be different
// cache versions for different customer groups
function get_page_caching_params(&$vary_by, &$versions, &$ttl)
{
  $vary_by = array('customer_group');
  $versions = array('cms');
  
  return true;  
}

The $vary_by, $versions and $ttl parameters are similar to the cache_vary_by, cache_versions and cache_ttl parameters in the partial caching. The only difference is that the url parameter is already included to the page $vary_by list, because page cache always depends on the page URL. Please note, that page caching does not cache the page template/layout content. In most of the cases caching the full page does not make much sense, because templates often contain elements, which depend on the customer behavior, for example the cart content indicator, the compare products list, and so on. However you can use partial caching in the templates to cache specific template areas.

Manual resetting a page cache

If you edit your CMS content in file-based mode, LemonStand may not be aware of content updates. Thus, if you use the cms vary-by parameter, it will not work. There are two ways to reset the cache in this case. The first option is going to the CMS area in the Administration Area and updating any page, partial or template, Another option allows to update cache of a specific page and all partials used on the page, using a special URL key. To use this option you should specify the key name in the caching configuration, in the config.php file with the RESET_PAGE_CACHE_KEY parameter:

  $CONFIG['CACHING'] = array(
    'CLASS_NAME'=>'Core_ApcCache',
     ... 
    'RESET_PAGE_CACHE_KEY'=>'reset_cache', // The reset cache key name
     ...
  );

You can use any value for the key name. When the reset key is configured, you can reset a page cache by specifying the key in the page URL, for example: http://example.com/page/?reset_cache=1

Previous: Manufacturer Details page
Return to Advanced Features for your Online Store