Full Page Caching - Configuration Full (Optional)

Configuration Full (Optional)

Back to User Guides

So you want more, do you? Well, Full Page Caching is ready to give. To take advantage of this power, it has to be customized to your site. You have dynamic content here or there. Well, that’s great, but the next 5 people put that dynamic content in a completely different place. For that reason, full configuration is meant only for full customization. Here we go!

Warning: Programmers Only

“Full customization” is code “not intended for non-programmers.” If you’re not a programmer, or not interested in becoming one, this configuration option may not be for you. And if you are, let me tell you from experience that it may be an easier task for programmers familiar with the inner workings of Magento. Not saying that you won’t figure it out, but our experience has been that Full Page Caching full configuration can take an experienced magento programmer a few hours to accomplish. It would be better for you to make the right decision about which configuration to use NOW, instead of hours and headaches later.On the other hand, don’t let me scare you. If you have some time to burn and want give it a try, feel free. Just don’t say I didn’t warn you if you can’t figure it out.

Pages

The first thing you need to do to configure Full Page Caching is determine which pages you would like to be cached. Literally any page can be cached. Setting a page to be cached is a matter of calling the cachePage() method of the root block, which is added during installation (an instance of Cminds_Warp_Block_Page_Html). cachePage() accepts three optional arguments:

1. The first is an integer argument that represents the time in seconds before the cached page should expire. If no expire time is set, the cached page will never expire unless memcache is restarted or needs to make room for newer data.
2. The second argument is a comma-separated list of disqualifiers. These disqualifiers will disqualify users that match the listed criteria from receiving cached pages.
3. The third argument is a path that will retrieve the content to fill the holes punched in the cached page. This allows disqualified users to still get a cached page, but with fresh dynamic content only where necessary.

cachePage() may be called either from a layout or from a block. It is recommended that it be called from a layout.

As Magento loads the various blocks and layouts that make up a page, every block gets an opportunity to indicate that the page being loaded should be cached. If any block on the page calls cachePage() on the root block, that entire page will be cached. For that reason, you should call cachePage() as high up in the layout / block hierarchy as possible to avoid any accidental caching.

Pages Adding Caching to a Layout

<reference name="root">
    <action method="cachePage">
        <!-- Expire time (seconds) -->
        <expires></expires>
        <!-- Turns off LS under these conditions -->
        <disqualifiers>cart,loggedin,compare</disqualifiers>
        <!-- Path to dynamic content for page -->
        <holecontent>module/controller/action</holecontent>
    </action>
</reference>

The <expires> tag can be left empty (<expires></expires>) to indicate that the page should only be expired when one of its tags is flushed from the cache. In this example, this page will be served entirely from the cache if the visitor does not have items in their shopping cart and if they are not logged in. In the event that a user has items in their shopping cart or is logged in, they will still get served a cached page, but certain pieces of the page will be replaced with fresh content. In this event, the request into Magento to get the fresh content can be minimal, allowing the response to be very fast and very light on the application.

Good to know...

<expires>, <holecontent> and <disqualifiers> are optional arguments. 

Hole punching

Hole punching is used by Full Page Caching to retrieve pieces of dynamic content on a cached page. For example, most sites have a top bar that may have the visitor’s name if they are logged in and the number of items in their shopping cart. A lot of sites will also have a “Recently Viewed” section that is different for every visitor.

Hole punches are triggered from template files (.phtml) by implementing the following snippets, in the form of HTML comment blocks:

HTML Punching A Hole

<!-- NOCACHE key="unique_key" -->
<div>
    Your display code replaced after a page cache hit.
</div>
<!-- ENDNOCACHE -->

As declared previously, the third argument to the cachePage() function declares a route where the content for the NOCACHE holes can be requested. This route is expected to have content for all of the holes for that page. The route is just like any other route within Magento. The route: module/controller/action would expect a Magento module, a Controller, and an Action method that you specify. You’ll have to create this path. If you need help with this, then you’ll need to study up on how to create a module according to magento standards or add an action to an already existing controller.

Here’s an example of one such controller:

PHP An Example Controller Action (For Filling a Punch)

class Namespace_Module_TestController extends Mage_Core_Controller_Front_Action {
    public function HoleContentAction() {
        $content = array( 
            'hole1' => 'html content',
            'hole2' => 'more html content',
            'hole3' => $this->getLayout()->createBlock('core/template')->setTemplate('template.phtml')->toHtml()
        );
        echo Zend_Json::encode($content);
    }
}

As shown in the previous example, there are a couple of conventions:

1. The response to be echoed must be an array encoded in JSON.
2. The array is a key value registry, where the key will match the key declared in the NOCACHE punch, and the value is the html content that will fill NOCACHE punch with content.

Your primary task here, is to make this request as light as possible. The lighter and smaller you can make this request, the better your application will scale as the heaviest pieces of the page will be cached already.

Is All This Hole-Punching Business Confusing?

You’re not alone. Full Page Caching (and especially Hole-Punching) is complicated. However, it overcomes a major performance issue in Magneto. That doesn’t come without some work and as such, full configuration like this can require some experience to leverage well. quick configuration works well for many happy Full Page Caching customers out there.

Disqualifiers

Disqualifiers represent visitor states that disqualify a user from getting an entire cached page or prevents Full Page Caching from creating a cached page in the event that no page cache exists yet.

There are only four disqualifiers at the time of this writing: *, cart, loggedin, and compare.

• “*” – Signifies that every visitor is disqualified for a completely cached page. This could be useful on pages with recently viewed products, that needs to be unique for each visitor.
• “cart” – Represents a state where a visitor has at least one item in their shopping cart.
• “loggedin” – Represents a state where the visitor has logged in.
• “compare” – Represents a state where the visitor has add a product to the compare. (Added in Lightspeed Version 2.10)

Tagging

Tagging within Full Page Caching is extremely simple. Full Page Caching will aggregate all of the tags for every block used within that page, and associate them with the cached page. An expired tag on any block on that page will also clear the cached page. A tutorial on how to implement block level cache tagging is out of the scope of this documentation, but more information can be found  here.

That’s the tour. Enjoy Full Page Caching page performance!

	Get more information about the Full Page Caching Extension for Magento®. Find other Magento products at the CreativeMinds Magento Store.
	Let us know how we can Improve this Product Documentation Page. To open a Support Ticket visit our support center.