We will discuss several of Magnolia’s advanced caching modules, and we will install Magnolia’s Advanced Cache for Personalization module to allow us to cache pages that contain personalized content.
We don't cache personalized content by default.
The ACP allows for automatic caching of personalized content (as low as the component level). Requires EE Pro.
Without the ACP module, cache is bypassed for any content that has variants. The Personalization module changes cache configuration during installation.
Caching of a page containing component variants means that a separate version of the page is cached for each component variant when the component variant is requested. For example, if a page contains two personalized components (A and B), each component has two variants (A1, A2, B1, B2), and if the combination A1 + B2 is valid for a visitor, this combination will be stored in the cache:
If you want to use a personalization engine of an external system, see how it was done for Customer segments in IBM WebSphere Commerce Integration module or the example how to retrieve traits from SugarCRM Connector.
Visitor: Allows you to detect if a visitor is new, returning or logged in. For example, greet a logged-in visitor by their name.
By default, you may personalize Pages or Components on those Pages, but you may not personalize Components on personalized Pages unless you allow this by setting the property here Component personalization#Enablingpersonalizedcomponentsinpersonalizedpages.
Advanced Cache Dynamic Page Caching
cache static content on an otherwise dynamic page ... we do this by adding to component definitions:
<module> <templates> <components> <myComponent> <fragmentDefinition> * class info.magnolia.module.advancedcache.rendering.DynamicFragmentDefinition * ttl 0 * mechanism sitemesh * dynamic true
the goal here is obviously to improve performance. But think about some gotchas:
remember, "caching" refers to the calculated HTML streamed back to the request ... since every component in magnolia has its own render cycle ... so every dynamic component must be rendered separately, instead of just coming from cache (pre-calculated) ... beyond a certain number of dynamic components (~20-30), it becomes faster to not even use the cache!
you can nest dynamic components, but does this make sense? again, think of rendering engine and how much work it must carry out to calculate a component - and - what if you have a a dynamic component inside of a non-dynamic component, etc.?
if you need to have several dynamic components, think about grouping them into a dynamic area to improve processing time. I.e., make one big dynamic area with N components, rather than one big static area with N dynamic components.