Developer Resources

For more heavily developed stores it's possible that you may need to customise the functionality of some of the dynamic caching exclusions options. If you are encountering problems with JS functionality and have observers attached to elements which are excluded from caching, you may also need to make some minor JS changes. Although only requiring basic Magento development knowledge, these kinds of modifications are probably best handled by your store developer.

This page also discusses the three URL helper arguments Evolved Caching uses which allow you to setup the extension, and also debug any issues you may be experiencing with serving cached content. Finally the forcecache URL argument forces requests to pass through the caching logic when normally they would not.

Customising dynamic caching exclusion options

If you are finding that some of the dynamic options under the Caching Exclusions section of the settings are not functioning correctly it probably means that the HTML structure for the relevant area of the page has been modified when compared to the the original, or the rendered dynamic content may need customising to match template modifications. Evolved Caching normally works by excluding page content by block only, but there are some areas of the category and products pages which do need to be dynamic, but do not appear in their own block. Evolved Caching uses regex to match these areas of the page so that they can be updated with dynamic content. For this reason having an unmodified HTML structure around these areas of the page is important as it will break the regex matching.

To enable these options to work even if the HTML structure has been modified, Evolved Caching fires various events which can be observed to allow you to modify the regex used to match page content.

You are able to customise behaviour for the following dynamic options:

  • Dynamic Category Stock Status
  • Dynamic Product Tier Pricing
  • Dynamic Welcome Message

Due to the way the other options render content on the page their behaviour should never need customising.

Dynamic Category Stock Status

The dynamic category stock status setting makes dynamic the add to cart button area of category pages in both list and grid mode. It fires the following events:

evolved_caching_block_product_list_list_cart_regex
evolved_caching_block_product_list_grid_cart_regex
evolved_caching_block_product_list_list_cart_render
evolved_caching_block_product_list_grid_cart_render
evolved_caching_block_product_list_outofstock_cart_render

Dynamic Product Tier Pricing

The dynamic product tier pricing setting makes dynamic the tier pricing area of product pages. it fires the following events:

evolved_caching_block_product_info_tier_regex

Dynamic Welcome Message

The dynamic welcome message makes dynamic the header welcome message. It fires the following events:

evolved_caching_block_welcome_regex
evolved_caching_block_welcome_render

Modifying behaviour

The Dynamic Product Tier Pricing setting only dispatches an event relating to the regex used to match content on the page. Rendering the dynamic content uses a dedicated method and so does not need an event. The Dynamic Category Stock Status and Dynamic Welcome Message settings dispatch events related to both the regex used to match content on the page, and the HTML used to render dynamic content in these areas.

To modify behaviour you can either observe the above events in your own module, or use our free support module which observes all of the events Evolved Caching fires with example code for modifying behaviour. Just install the lightweight module like any other and then edit the model observer class with your changes.

The events ending in _regex contain the regex used to match the relevant dynamic areas of the page. The current regex can be pulled and altered in the observer method using the following PHP:

$regex = $observer->getRegex();
$pattern = $regex->getPattern(); // pull the current regex
$regex->setPattern($somenewregex); // set your own regex

The events ending in _render contain the HTML used to render out dynamic content. The observer object will contain three customisable HTML strings, before, middle and after. The middle string will contain any user/block specific HTML in the dynamic content (for instance the welcome message text, or the add to cart URL) - you are less likely to want to change this. In the case of your templates having been customised you probably are however going to want to customise the before and after strings which contain any non user/block specific HTML used to render dynamic content (for instance the welcome message element opening and closing tags). The current dynamic content can be pulled and altered in the observer method using the following PHP:

$data = $observer->getData();
$before = $data->getBefore(); // pull the before string
$data->setBefore($somenewbeforestring); // set your own before string
$middle = $data->getMiddle(); // pull the middle string
$after = $data->getAfter(); // pull the after string
$data->setAfter($somenewafterstring); // set your own after string

You can also pull the complete string being a combination of before, middle and after strings, but any changes made to this string will be ignored:

$complete = $data->getComplete(); // pull the complete string

Fixing dynamic block JS event observers

If you are having issues with JS functionality, it could be where observers are attached to elements on the page which have been excluded from caching. If this is the case then you have a few options to resolve these problems.

The first option is that Evolved Caching fires a JS event, evolved:loaded, when it has finished updating all dynamic content on the page. It's likely that observers are trying to be attached to elements before the dynamic content has been updated. This means that when this dynamic content is updated the code to attach the observers to these elements has already run and so nothing is actually being observed. You need instead to add the observers after the dynamic content has loaded and you can do this by observing the evolved:loaded event and attaching the observers here.

The second option is to switch to BigPipe dynamic content strategy. While BigPipe performance is not quite as fast as AJAX (so we recommend sticking with AJAX wherever possible), using it may resolve the JS issues you are seeing, but this does depend on how the JS has been coded so it's not guaranteed. Using BigPipe means that JS events such as dom:loaded are fired after all dynamic content has loaded which is not the case with AJAX. If your JS observers are being attached using an on load event like this then using BigPipe should resolve any issues, but if not then it may not.

JS class best practice

While the above can both be used to resolve JS issues, overall it would be better to use the best practice described here to instantiate your problematic JS classes. Using this method removes any dependency on the evolved:loaded event but still allows the JS to function correctly with excluded blocks.

This method involves adding a block to before_body_end as follows in your layout:

<?xml version="1.0"?>
<layout version="0.1.0">
    ...
    <default> <!-- or some other layout handle -->
        ...
        <block type="core/template" name="unique_block_name" template="some/template.phtml" parent="before_body_end" />
    </default>
    ...
</layout>

Inside the template you define you simply instantiate your JS class, with the initialize method from this class being the one which attaches the observers. The template just needs to be:

<script type="text/javascript">
    //<![CDATA[
        new jsclass();
    //]]>
</script>

With this setup you then just exclude your new block from caching in the Evolved Caching settings, in this example you would enter block name unique_block_name. Your previously problematic JS will now work both with and without caching enabled.

Frontend URL helper arguments

Evolved Caching uses three different helper URL arguments, ?shownames, ?disabled and ?evolved.

  • ?shownames - displays block names you can add into the excluded blocks settings section of admin
  • ?evolved - displays error messages if the cached page cannot be loaded, or if cached contents loads correctly it will show you which areas of the page are dynamic
  • ?disabled - disables full page caching for the request
Frontend forcecache helper argument

Evolved Caching uses the URL argument ?forcecache to bypass URL parameter checks to force requests through the cache creation and serving logic. One application where this could be useful might for instance be where you have infinite scroll functionality on your category pages and want to cache the AJAX requests for this extra category page content. Normally AJAX requests completely bypass caching but by appending ?forcecache as a $_GET argument to the request, it will then pass through cache creation and serving logic.

Note that using ?forcecache does not bypass checks for page exclusions by URL.