Efficiently Caching : Localised XF with SDI for MSM

Even though we improved caching by introducing SDI in previous article, but SDI with XF don’t work in case of multilingual sites.

OOTB experience fragment(w/o SDI) works by rendering the localised XF on the fly for multilingual sites. However the XF component doesn’t have any provision for SDI. The ootb code is not able to pick up localised XF’s if we render XF’s using SDI.

Why Localised XF don’t work with SDI on the dispatcher?

If we use SDI the currentPage object points to template page(ie /conf) though the OOTB XF code expects current page to be pointing to the content page(ie /content) and not the template page and hence the code breaks in case of SDI XF for MSM and it is not able to deliver localized XF’s on the dispatcher.

Hence we need to tweak the OOTB XF component if we want to be able to extend it for SDI’s. Follow the steps below to extend the OOTB XF component for SDI’s. 

1)  Add suffix=current page

     Add rewrite rule to append suffic to the sdi call on page

# RewriteRule ^(.*)$ $1%{ENV:DOCUMENT_URI} [PT,QSD]
RewriteCond %{REQUEST_URI} .xf.html$
RewriteCond %{REQUEST_URI} ^/(content|conf)
RewriteRule ^(.*)$ $1%{ENV:DOCUMENT_URI} [PT]
	

2) Modify the OOTB XF code to read the current page from suffix.

    com.demo.web.core.models.impl.ExperienceFragmentImpl

3) All Sling models used for components on header/footer XF would also need to be    modified similarly  to read current page from suffix.

Efficiently Caching : Experience Fragments on dispatcher

Problem

Suppose you are using XF/Experience Fragments included in template for Header and footer. Header and Footer XF are included in the template structure. XF are not getting updated on the pages since the content pages are cached with header and footer html’s as part of the pages. So only updating the XF wont invalidate the pages. The entire content hierarchy would need to be invalidated to see the updated XF content on pages.

Approach

SDI can be used in this case. All pages would reference a single html file at a shared location. Once XF is activated the shared file will be invalidated and updated. Since the content pages are just referencing the shared file they would also show updated content.

SDI setup is Only required on Publish.

The XF html will be included as a server side includes in the template as a separate request to a XF with xf selector. This will be get cached on the dispatcher below /conf.

Cache will be invalidated using acs commons dispatcher cache flush osgi config, once the XF are published.

Enable commenting to see the below comments in page source.

Implementation

Sling dynamic include jar is NOT available in aem osgi ootb. So we need to deploy the jar to osgi.

Add dependency in parent pom and demo.all pom.

<!-- https://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.dynamic-include -->
<dependency>
    <groupId>org.apache.sling</groupId>
    <artifactId>org.apache.sling.dynamic-include</artifactId>
    <version>3.1.6</version>
</dependency>

Configure org.apache.sling.dynamicinclude.Configuration 

OOTB when a page is loaded a separate call(network tab) is made to get the structure of the template and render on the page. The call starts with /conf… We need to SDI this call for the XF component.

OSGI config attribute “include-filter.config.path” means repo will be searched below /conf/demo/settings/wcm/templates and resources have resourcetype = demo/component/experiencefragment will be sling dynamically included.

The included/cached XF’s will be created below /conf

SDI config - Only required on Publish

Please Note that the cache will be created below /conf

Update acs commons dispatcher cache flush

Cache below /conf should be cleared when experience fragment is activated.

Above was later renamed and updated to..

com.adobe.acs.commons.replication.dispatcher.impl.DispatcherFlushRulesImpl-template_xf.xml

  prop.rules.hierarchical="[/content/experience-fragments/demo/en-us/global/.*
  							=/conf/demo/settings/wcm/templates]"
  

Continue Reading: Efficiently Caching : Localised XF with SDI for MSM

Use 3rd party API or JAR or Dependency in AEM

A 3rd party jar is one which is not present as a bundle in AEM OSgI. If you want to use API’s from a 3rd party jar in AEM then it needs to be added to AEM OSGI. 

If you try to upload a 3rd party jar in osgi then it won’t, get uploaded. To upload it, Continue Reading

Localised Experience Fragments AEM

If you reference XF inside template structure and create XF structure exactly similar to site structure, the pages will pick the localised XF based on the current site page being accessed.This is especially useful for implementing localised header and footer configured via XF’s.

 

For example if /content/demo/us/en pages are referenced it will pick the /content/experience-fragments/demo/us/en XF on the fly.

 

Product code

com.adobe.cq.wcm.core.components.internal.models.v1.ExperienceFragmentImpl

For Localised XF header and footer to work the XF need to be included in the template structure. The XF path inside template should be for language master.

 

The XF structure should be exactly similar to that of site structure as shown below.

i.e. nodes names below /content and /content/experience-fragments should be same till language node.

Site - /content/demo/language-master/en

XF - /content/experience-fragments/demo/language-masters/en

 

 

After /content/experience-fragments/demo/language-masters/en XF can have any path/structure.

Continue Reading: Efficiently Caching : Localised XF with SDI for MSM