General

How Does It Work?

The first time a customer visits a website that uses our Full Page Cache extension, a cached page is created for any parts of the site they have yet to access. All of the pages the customer visits get stored in the cache. Each time a new customer accesses the website, the system retrieves a copy of the page from the cache instead of generating a new return. This process reduces the load on your servers and increases the speed of your site.

0 people did not find this helpful

Back To Top

Description

Numerous studies have shown that faster load times can substantially decrease bounce rate while increasing total sales. Even delays lasting as little as 100 milliseconds can cause customers to abandon their shopping cart. Brim’s Full Page Cache extension speeds up your website so that you can see a rise in traffic and a surge in sales.

0 people did not find this helpful

Back To Top

Background

Brim’s Full Page Cache extension is a two-level caching engine. The first level is fast, but it cannot be used for all purposes. It also does not support any dynamic block updates. The second level is the general-purpose cache that can be applied to nearly all requests and customers, and it fully supports dynamic block updates.

While matching requests, our extension will automatically move on to the second level cache if it finds that the first level is not suitable.

The first level cache will be bypassed if the following conditions are met:

  • There are items in the shopping cart
  • A user is logged in
  • Messages are on the page
  • The request has POST parameters

Note: Any product block that was recently viewed will not be displayed, and product views will not be tracked when using the first level cache.

0 people did not find this helpful

Back To Top

Installation & Setup

Enable

To enable the Full Page Cache extension, follow these steps:

  1. Go to System>Cache Management.
  2. Check the Full Page Cache checkbox.
  3. Use the drop-down in the top right corner of the screen, and select Enable.
  4. Click Submit.

Cache Management

0 people did not find this helpful

Back To Top

Uninstall

To uninstall the Full Page Cache extension, follow these steps:

  1. Go to Set System>Configuration>Full Page Cache>Settings>Enabled, and select No.
  2. Delete the following files and directories from your server:
    • app/etc/brim_pagecache.xml
    • app/code/community/Brim/PageCache/
    • app/design/frontend/base/default/layout/brim-page-cache.xml
    • app/etc/modules/Brim_PageCache.xml
    • lib/Brim/Cache/Backend/File/Scalable.php
    • lib/Brim/Cache/Backend/Database.php
    • shell/brim-fpc.php
  3. Flush your cache.

0 people did not find this helpful

Back To Top

Install

To download the latest version of our Full Page Cache (FPC) extension, follow these steps:

  1. Go to ecommerce.brimllc.com and log in to your account.
  2. Click My Account, and then click My Products in the left menu.
  3. On your Magento installation, disable the compilation if it is currently in use.
  4. Unpack the contents of the extension in the root of your Magento installation root.
  5. Run the compilation process if it was previously in use.
  6. Go to System >Cache Management, and then click Flush Cache Storage.
  7. Go to System >Configuration, and click on the Brim Extensions tab. Full Page Cache is now listed on this tab, letting you know that the extension has been installed successfully.
    • If a 404 message is displayed, log out of your account, and then log back in.
  8. Enable the compilation if it was previously in use.

0 people did not find this helpful

Back To Top

Configuration Settings

Brim’s FPC has a handful of configurable settings to control how pages are cached. All settings are located in "System -> Configuration -> Brim Extensions -> Full Page Cache"

Config File Settings

Config File Settings
Config File Settings
Setting Explanation
Auto Write XML Config to Disk When set to “Yes” required XML configuration will be written directly to app/etc/brim_pagecache.xml. This can be set to “No” if for some reason the web server is not able to write to the file or if additional customization is required.
XML If empty, no additional configuration needs to be written to disk. If not empty, this configuration must be present in app/etc/brim_pagecache.xml

0 people did not find this helpful

Back To Top

Cache Conditions Settings

Cache Conditions
Cache Conditions
Setting Explanation
Use Customer Group In Cache Key When the customer group is used in the cache key, pages are NOT shared between users in different customer groups.  This is safe to turn off when a site does not use any of the customer group features like different product prices based on customer group.  This can increase your hit rate.
Share pages between NOT LOGGED IN AND General Customers Treats visitors and general customers as if they were the same group.  This is useful if you use customer group product pricing except for visitors and general customers.  This can increase your hit rate.
Maximum Query Parameters to Cache If a request contains more than the set number of parameters, the request will NOT be cached. -1 allows unlimited parameters, but is not recommended. It is recommended to keep this value small.
Session Variables List of session variables to included in the cache key.  This is an advanced feature and should not be used by most users.

  • Session Variable : The variable name to use when searching the session model or $_SESSION.
  • Session Model : The model to load which contains the session variable ie “customer/session”.  If empty the super global $_SESSION variable is used.
Ignored Url Parameters  List of url parameters to remove from the cache key if found. Parameters that do NOT affect the page output can be listed here.

0 people did not find this helpful

Back To Top

Mobile Settings

Mobile Settings
Mobile Settings
Setting Explanation
Enable User Agent Detection Set to yes if you would like to include mobile in the cache key when a mobile device views a page. This is useful for cases where there is a theme change for mobile devices based on user agent detection. This is not needed for responsive themes or if there is a separate Magento store for mobile devices.
User Agent Pattern The pattern to determine if the reported user agent is mobile.

0 people did not find this helpful

Back To Top

Storage Setttings

Storage Settings
Storage Settings
 

Setting Explanation
Use System Cache
  • Yes – Store cached pages in the default Magento cache store.
  • No – Store cached pages in a separate cache store.
Use Scalable File Setting is available when using the system cache.  This will override the existing backend with Scalable File.  Scalable File is a cache backed that handles a large number of objects in a file based cache where the normal file cache slows down.
Type The cache store type when not using the system cache.

Supported Types:

  • File
  • Scalable File
  • Database
  • APC
  • Memcached
  • Optimized File (Magento CE 1.8+)
  • Redis (Magento CE 1.8+)
Slow Type The slow cache type used, only applicable when type is set to “Apc” or “Memcached”.

Supported Types:

  • File
  • Database
Path The directory to store cached objects for file based backends like File or Scalable File. This should NOT be the same as the default Magento cache path. ex: “cache-fpc”
Memcached Servers XML Listing of memcached servers to use. Only applicable when the backend type is set to “Memcached”.

Example:

<server1>
    <host><![CDATA[10.0.0.1]]></host>
    <port><![CDATA[11211]]></port>
    <status><![CDATA[1]]></status>
</server1>
<server2>
    <host><![CDATA[10.0.0.2]]></host>
    <port><![CDATA[11211]]></port>
    <status><![CDATA[1]]></status>
</server2>
Redis Server XML Redis connection parameters are set in xml. Only applicable when the backend type is set to “Redis”.

Example:

<backend_options>
    <server>127.0.0.1</server> 
    <port>6379</port>
    <database>0</database>
    <password></password>
    <force_standalone>0</force_standalone> 
    <connect_retries>1</connect_retries> 
    <automatic_cleaning_factor>0</automatic_cleaning_factor> 
    <compress_data>1</compress_data>
    <compress_tags>1</compress_tags> 
    <compress_threshold>20480</compress_threshold> 
    <compression_lib>gzip</compression_lib> 
    <persistent>1</persistent>
</backend_options>

0 people did not find this helpful

Back To Top

Layout Settings

Layout Settings
Layout Settings
Settings Explanation
Custom Block Updates A list of custom block names that should be updated when serving pages with the standard full page cache. Example:

  • Block Name : top_cart
  • Container : brim_pagecache/container_cart

NOTE: The Level 1 cache does not support this feature.

Cache Additional Page Types Specify additional page types that should be cached. Can be used to cache pages generated by 3rd party extensions.
Custom Layout XML ADVANCED: Additional layout xml to be applied to each page. Can be used to cache additional pages or specify other instructions.

0 people did not find this helpful

Back To Top

General Settings

General Settings
General Settings
Setting Explanation
Version Version of the FPC currently running.
Enabled Turn the FPC on/off at the store scope.
Enable Level 1 Cache Turn the Level 1 cache on/off. The Level 1 cache does not support multiple currencies, stores, languages unless the url indicates the currency, store, or language.
Cache Block Updates Dynamic block update fragments will be cached and re-used when possible. Page load times can be further reduced, however more cache storage space will be required depending on traffic. 
Enable HTML Minification Removes extra whitespace from your page’s HTML source before caching. Enabling on Magento’s default theme results in a 15-18% smaller page.
Invalidate Action “Clean” will refresh the cache after the certain changes are made. ie: product saves or stock status changes.  “Notify” will display a message to the Magento admin that the cache needs to be refreshed before changes will be displayed.  Clean is the recommended setting for most instances.
Page Expires Maximum time a page is cached before being regenerated. Expires time is specified in seconds and defaults to 7200 or 2 hours.  Setting this value too large ( > 1 day) may have adverse effects on your site.
Debug Defaults to off. If enabled additional debug messages will be written to \[magento root\]/var/log/brim-fpc-debug.log
Response Debugging Defaults to off. If enabled additional HTTP headers will be set on HTTP responses.

0 people did not find this helpful

Back To Top

FAQ

Why does saving a product take so long?

This FAQ applies to any function that appears to be slower, like a cart or checkout page as some other extensions actually save products on those pages as well.

This is generally do to the cache backend being used, likely being File.  The File backend is known for having scaling issues when the number of files grows large, cleaning operations slow down as it needs to read each and every file in the cache.  Since you are now using an FPC you are storing more and more files in the cache.

There are a couple things that can be done to work around this.

1) Split the FPC into it’s own backend.  See our recommended settings for more details. This helps limit the number of files that need to be read when performing a cleaning operation.

2) Don’t use the file backend for Magento or the FPC. If you are on Magento CE 1.8+ use Mage_Cache_Backend_File instead. This backend is also referred to as Optimized File in the FPC settings.

To make Magento use this backend you need to modify your app/etc/local.xml configuration file. Example below.

<config>
    <global>
        <cache>
            <backend>Mage_Cache_Backend_File</backend>
        </cache>
        ...
    </global>
    ...
</config>

See our recommended settings for more details on how to setup the FPC.

0 people did not find this helpful

Back To Top

I’m getting this error after installing! “Fatal error: Brim_ModuleName_Helper_Data’ not found in /home/xxxxxxx/public_html/app/Mage.php on line 547″

This error is often the result of the cache not properly being flushed or the Magento compiler running while files are still uploading. The order of the installation should look like this: Disable Compiler -> Upload Files -> Flush Cache -> Recompile.

It is important to note that all files must finish uploading before you run the Magento compiler.

0 people did not find this helpful

Back To Top

Is your extension compatible with Manadev’s Layered Navigation Plus?

Yes. However, if you are using its ajax features, you will need to do a slight modification to the Manadev extension as they modify ajax urls in a way that is not compatible.

Version: 12.09.18.17

Comment out line 27 & 28 of app/code/local/Mana/Ajax/Model/Observer.php

//Mage::helper('mana_core')->updateRequestParameter('m-ajax', '', $ajaxAction);
//Mage::helper('mana_core')->updateRequestParameter('no_cache', '', '1');

0 people did not find this helpful

Back To Top

Why is my blog not being cached?

First make sure your blog is being generated and served by Magento.  If it is, great! Brim’s FPC will work with it as it can cache any page served by Magento. If the blog is being generated by some other application it won’t work.

If you are using Brim’s FPC 3.1 or above goto System > Configuration > Full Page Cache > Layout Settings > Cache Additional Page Types. Click the “Add New Page Type” button, then find and select the page type in the drop down.  If the page you are trying to find is not in the drop down, then it has not defined a label for itself and it will need to be entered manually.

To manually cache additional pages you need to know what handle is being used.  Handle names are normally named after the router, controller, action.  You will want to check your extensions layout file to verify the exact and best handle to use.  Enter the following into System > Configuration > Full Page Cache > Layout Settings > Custom Layout XML

<router_controller_action>
    <update handle="brim_pagecache_default" />
</router_controller_action>

If you happen to be using Fishpig’s wordpress integration you can use the following xml. The extension defines a common handle inherited by all page types.

<wordpress_default>
    <update handle="brim_pagecache_default" />
</wordpress_default>

Then save the configuration and you should be all set.

0 people did not find this helpful

Back To Top

What are your recommended settings for the cache backend?

Most stores will benefit from splitting the full page cache backend from the standard Magento cache backend.  This can be done via System > Configuration > Full Page Cache > Storage Settings.

  • Use System Cache = “No”
  • Type = “File”
  • Path = “cache-fpc”

Based on the number of products, categories, and CMS pages you have in your store, File may not be a suitable backend choice, as it does have issues flushing the cache when it’s very large.  Or, if you have multiple web servers, you will want to choose a backend designed to handle that configuration.  Here are our basic guidelines:

  • If you have one web server
    • If you have limited number of products use
      • APC, File or Database as the slow type
      • Optimized File (Magento CE 1.8+)
      • File
    • If you have many products use
      • Optimized File (Magento CE 1.8+)
      • Scalable File
  • If you have multiple web servers use
    • Memcached, Database as the slow type
    • Redis (Magento CE 1.8+ required & Brim’s FPC 3.1+)

0 people did not find this helpful

Back To Top

Why is my header cart not updating when adding products to my cart?

Magento does not ship with a top or header cart, a 3rd party extension has likely been installed if you have this functionality.  Since it’s not default Magento functionality you just need to tell the Full Page Cache about it so it knows to update it when rendering the page.

This is where our dynamic block functionality comes into play.  You just need to know the name of the block as defined in its layout file.  If you do not know what the layout name is or how to find it, please contact the vendor of the extension.  Once you have the name of the block enter it in  System > Configuration > Full Page Cache > Layout Settings > Custom Block Updates.  

For top header carts the “brim_pagecache/container_cart” container is the best option out of the box.

Version 3.1+
Example:

  • Block Name: header_cart
  • Container: brim_pagecache/container_cart

Version 3.0+
Block names should be entered one per line.

Example:

header_cart,brim_pagecache/container_cart

0 people did not find this helpful

Back To Top

How can I remove a CMS page from the cache?

A command line script, shell/brim-fpc.php, is shipped with all recent versions of our Full Page Cache.  The script can remove by tag, expired pages, or everything.  Running the script without options will display the usage help.

However to remove a CMS page from the cache you just need to know the page’s id and run the following command where “1” is the page’s id:

php -f brim-fpc.php –clean –tags BRIM_FPC_CMS_PAGE_1

0 people did not find this helpful

Back To Top

Can I disable Full Page Caching for a single CMS page?

Yes!  This can be done by adding the following XML to the page’s “Layout Update XML” field:

<reference name="root"> 
    <action method="setCachePageFlag"><cache>0</cache></action> 
</reference>

0 people did not find this helpful

Back To Top

Does Your Full Page Cache Support Custom Blocks?

Yes, our Full Page Cache can support your custom blocks with a little php code and layout xml.  Below is a simple example that will work in most cases.

First create the following file: app/code/local/Brim/PageCache/Model/Container/Default.php

NOTE: As of version 2.1.4 the container is included with the extension.

<?php
class Brim_PageCache_Model_Container_Default 
    extends Brim_PageCache_Model_Container_Abstract {

    protected function _getCacheId() {
        return false;
    }
}

Then using layout xml you can associate this container with a custom block.  A single container maybe used with multiple blocks.

<reference name="#BLOCK-KNAME-HERE#"> 
    <action method="setDynamicBlockContainer"
        <container>brim_pagecache/container_default</container>
    </action> 
</reference>

0 people did not find this helpful

Back To Top

What Is Brim’s Full Page Cache?

Brim’s Full Page Cache decreases the time it takes to generate Magento pages.  By default, it caches product, category, and CMS pages, however additional pages may also be cached.  This means pages will be delivered to your customers faster and with much less load on your servers.

0 people did not find this helpful

Back To Top

How Does It Work?

The first time a customer visits a website that uses our Full Page Cache extension, a cached page is created for any parts of the site they have yet to access. All of the pages the customer visits get stored in the cache. Each time a new customer accesses the website, the system retrieves a copy of the page from the cache instead of generating a new return. This process reduces the load on your servers and increases the speed of your site.

0 people did not find this helpful

Back To Top

Support

What are your customer support hours?

Our support team is located in the United States with official hours weekdays (Monday-Friday) from 8am to 5pm Eastern Standard Time. US federal holidays are observed. Support is managed through our ticketing system. Tickets can be opened by emailing us at support@brimllc.com or via our web portal.

0 people did not find this helpful

Back To Top

Change Log

Full Page Cache Version 3.1.5 (1/21/2015)

  • Ships with Mage_Cache_Backend_File containing additional bug fixes.
  • Improved formkey pattern matching.
  • Added support for Manadev’s layered navigation extension.

0 people did not find this helpful

Back To Top

Full Page Cache Version 3.1.4 (8/25/2014)

  • Improved HTML Detection.
  • Improved recently viewed products block update.

0 people did not find this helpful

Back To Top

Full Page Cache Version 3.1.3 (6/24/2014)

  • Added formkey replacement support for the level1 cache.
  • Added formkey replacement support for json encoded requests.
  • Added helper method to disable the page cache.
  • Fixed breadcrumbs container where the path was not correct based on last visited category.
  • Fixed use case where blocks without names could be hole punched.
  • Improved HTML response detection to prevent minification on non-html responses.

0 people did not find this helpful

Back To Top

Full Page Cache Version 3.1.1 (5/19/2014)

  • Improved form key compatibility with Magento 1.8.1. Removed checkout overrides. Now compatible with any extension using form keys.
  • Improved breadcrumb and navigation block updates when category path are not included in product urls.

0 people did not find this helpful

Back To Top

Full Page Cache Version 3.1.0 (3/17/2014)

  • Added Redis support (CE 1.8+ / EE 1.13+)
  • Added optimized file support (CE 1.8+ / EE 1.13+)
  • Added support to perform dynamic block updates by block type
  • Added support for removing category paths from product urls
  • Added support for sharing cached pages between visitors and logged in customers
  • Added maximum parameters setting
  • Improved controls for Session Variables, Ignored Url Parameters, and Custom Block Updates
  • Prevent expires from being set too small or large
  • Improved HTML minification checks
  • Added category flushing control

0 people did not find this helpful

Back To Top

Version 1.0.0

  • Initial Version

0 people did not find this helpful

Back To Top

Version 2.0.0 (11/28/2011)

  • Added block update support, ie recently view products, shopping cart, etc
  • Added support for full page caching for logged in users
  • Improved debug functionality

0 people did not find this helpful

Back To Top

Version 2.1.0 (2/21/2012)

  • Greatly improved block update compatibility with custom themes
  • Decreased size of block update placeholders
  • Product, Categories, and CMS pages are removed from the cache when changed. Keeps content fresh!
  • Product pages are removed from the cache when the stock status changes
  • Added HTML minify setting for cached pages
  • Moved configuration settings to their own section

0 people did not find this helpful

Back To Top

Version 2.1.1 (3/05/2012)

  • Location header is now transfered to response
  • Fixed compatibility issue with the Magento Compiler

0 people did not find this helpful

Back To Top

Version 2.1.2 (3/20/2012)

  • Refactored recently viewed products block updates

0 people did not find this helpful

Back To Top

Version 2.1.3 (6/27/2012)

  • Added package and layout names to cache key
  • Added Magento shell script to flush the Full Page Cache by tags
  • Added option to cache block updates
  • Fixed possible issue with the recently viewed products block
  • Fixed a 5.2 compatibility issue

0 people did not find this helpful

Back To Top

Version 2.1.4 (10/01/2012)

  • Improved layout processing to handle remove instructions
  • Added the Default container to the package
  • 404 pages are no longer cached by default

0 people did not find this helpful

Back To Top

Version 3.0.0 (11/26/2012)

  • Introduced multi-level cache engine.
  • Added admin interface to specify blocks to dynamically update.
  • Added an improved File backend called Scalable File. Scalable File performance does not degrade as the size of the cache increases.
  • Added ability to split the cache backend from the default Magento backend. File, Scalable File, APC, Memcached, Database are supported.

0 people did not find this helpful

Back To Top

Version 3.0.1 (2/18/2013)

  • Added a configuration setting to ignore certain parameters when matching cache keys
  • Added a mobile helper to allow custom mobile detection logic
  • Improved the file backend defaults when used as a slow backend
  • Upgraded to the latest scalable file backend
  • Cache is cleaned of expired pages every 5 mintes
  • Added logged in cached condition
  • Full page cache can be flushed even when disabled
  • Dynamic block update matches more conservatively
  • Level 1 cache forces past expires header to be set

0 people did not find this helpful

Back To Top

Version 3.0.3 (11/15/2013)

  • Added Magento 1.8 CE support
  • Added new welcome block container

0 people did not find this helpful

Back To Top

Version 3.0.4 (1/6/2014)

  • Added currency support to the level 1 cache
  • Updated to latest version of the scalable file backend
  • Improved compatibility with extensions that rewrite the original request url ie. Manadev Layered Navigation Plus
  • Fixed issue with scalable file when using table prefixes

0 people did not find this helpful

Back To Top

Full Page Cache Version 3.0.5 (2/25/2014)

  • Added multi store support via cookies to the level 1 cache
  • Improved cached response checks
  • Fixed exception when session variables are not encoded properly

0 people did not find this helpful

Back To Top