This extension does overwrite Mage_Core_Model_Layout and does reconfigure request_rewrite.
First of all, you need to identify all blocks in layout that contain or may contain customer specific data. These need to be replaced with an placeholder in the page-cache. Do this by adding an attribute named "fpc-cacheable" to the XML node in the layout XML-File.
You also want to do this with all blocks that are not specific to a page and reside in the block html cache (e.g. the top-navigation). This way you deduplicate the cache contents and you limit the number of events that will purge pages from the cache.
E.g.
<block type="page/template_links" name="top.links" as="topLinks" fpc-cacheable="0" />
<block type="core/profiler" output="toHtml" name="core_profiler" fpc-cacheable="0"/>Attributes are there to persists state of an block between requests. You may need that for custom modules. You define those attributes in the layout XML as comma separated list in the XML attribute fpc-attributes. Each defined attribute will be retrieved from the block with getData and the value will be cached. When the block is created in a cached request, the data will be set again with setData.
This feature is intended to be used with small amounts of data like integers, floats or short strings. Keep in mind that the data will be serialized as json and will be written directly into the placeholder of the page. So DO NOT add large string or objects.
E.g.
<block type="vendor/newByCategory" name="news" fpc-attributes="category_id" />The processed requests are defined via XML. You can add your own or change the defaults if you wish to.
<frontend>
<fpc>
<routes>
<catalog_product_view>pagecache_product_view</catalog_product_view>
<catalog_category_view>pagecache_category_view</catalog_category_view>
<catalogsearch_result_index>pagecache_searchresult_view</catalogsearch_result_index>
<cms_page_view>pagecache_cms_view</cms_page_view>
<cms_index_index>pagecache_cms_view</cms_index_index>
</routes>
</fpc>
</frontend>If you want to disable a default controller you can set its value to disabled. e.g.
<frontend>
<fpc>
<requests>
<catalogsearch_result_index>disabled</catalogsearch_result_index>
</requests>
</fpc>
</frontend>Ignoring parameters allows you to define parameter that are substitutions to avoid duplication.
<frontend>
<fpc>
<request>
<parameters>
<ignore>
<param>___SID</param>
</ignore>
</parameters>
</request>
</fpc>
</frontend>If you need to disable the FPC for certain parameters, you can block them
<frontend>
<fpc>
<request>
<parameters>
<block>
<param>___store</param>
</block>
</parameters>
</request>
</fpc>
</frontend>In the response configuration you can define parameters that will hinder the FPC from saving the page.
<frontend>
<fpc>
<response>
<parameters>
<block>
<param>___store</param>
</block>
</parameters>
</response>
</fpc>
</frontend>You can define parameters that should not be used to generate a cache key
<frontend>
<fpc>
<request>
<parameters>
<ignore>
<param>___SID</param>
</ignore>
</parameters>
</request>
</fpc>
</frontend>Max. Allowed Page Query-Paramerters
This is important if you have an high number of filterable attributes. As you, most likely, do not want to cache all possible combinations, you need to limit the number of cached GET-parameter combinations. The default of 10 will allow the following example:
Disable Cache By Customer Group
Customers of any chosen group will not save a page into page-cache while browsing
Modifiers are there to handel statefull requests in a customer session. The modifiers are generated at the end of every request and set as cookie. The cookie's value is then appended to the cache key at the beginning of every request. Do not activate any modifier that is actually not needed. Modifiers will increase the cache size and may slow down the request processing.
Currencies
Activate that if a customer can change the currency.
Customer Groups
Activate that if there is customer group specific data on a page that will be cached in the page-cache. E.g. Customer group prices.
Tax
Activate that if you use multiple tax rates and the rate changes the price or you display the rate to the customer.
Store
Activate that if you use multiple store views and the storeview is not in a separate folder or on a separate domain.
Notifies you when the cache is going to be invalidated
Lets you act on a cache entry before it is saved. E.g. adding cache tags or adding meta data
$event->getResponseProcessor()->addCacheTags(['mytag1', 'mytag2']);
$event->getResponseProcessor()->addMetaData(
['something' => 'i_need_again']
);Lets you disable caching for the page
$event->getFlag()->setCanCache(false);Lets you add an request id modifier. Keep in mind that keys are not used
$modifiers = $event->getModifiers();
$modifiers = array_merge($modifiers, ['newModifier']);
$event->setMyModifier($modifiers);1. Register your request
<frontend>
<fpc>
<routes>
<mymodule_index_view>mymodule_cache_view</mymodule_index_view>
</routes>
</fpc>
</frontend>2. Create a controller for your request
class Vendor_MyModule_CacheController
extends RockSolid_PageCache_Controller_Action
{
public function viewAction()
{
$this->prepareLayout();
$this->renderLayout();
}
}3. Add model proxies
class Vendor_MyModule_Model_Proxy_SomeModel
extends Vendor_MyModule_Model_SomeModel_Interceptor
{
}4. Configure interceptor for model proxies
Add a pagecache.xml to your module to do that
Proxies can alter the behavior of an model in fpc- context. This is especially helpful to:
In order to use proxies you have to create a proxy model and an interceptor configuration.
You can retreive an instance like that:
$instance = Mage::getSingleton('fpc/proxy_factory')->getInstance(
'my_module/proxy_mymodel', 'my_module/mymodel', $data
);This will create and cache the interceptor o-t-f.
You need to add a method configuration for every class in the hirachy. Configuration for core-models is already included in the module.
The following options are available:
passthru: Just add the method name to the config. Use that for calls that are forwarded to the resource model
before: Lets you define a method that musst be called before the invoked method.
after: Lets you define a method that musst be called after the invoked method.
around: This is actually different to "aourund" as you might know it from AOP. It means: call this method and if it returns true, call the invoked method
If you encounter any problems or bugs, please create an issue on GitHub.
There is, however, commercial support available. Inquiries: rocksolid.at
GNU General Public License, version 3 (GPLv3)
(c) 2020 Jan F. Kousek (rocksolid.at)