Customized Experience Manager website extension
For dynamic or MVC-based websites, you need to customize the default Experience website extension setup.
For any number of reasons, HTTP requests to your website may not be requests for an actual file in the actual location specified in the request:
- You may support 'pretty URLs' for your visitors, which are transformed into different URLs under the hood.
- You may store the resources you wish to serve outside your website's web application context altogether
- You may map the incoming request to some other location and/or resource name for another reason.
The reasons an out-of-the-box Experience Manager website extension does not work are:
- Your transformation is unaware of redirection to a session-specific resource by the website extension
- The website extension is unaware of your transformation
- The transformation logic is never invoked
To resolve this problem, do the following:
- Build a custom Claim Processor
-
Your custom Claim Processor should apply the same transformation that your actual website filter applies. It should specify the locations where the page and its Component Presentation are actually located. And it may disable request forwarding for the Experience Manager website extension's Page content and binary content filters. Disabling the request may be required if the Experience Manager website extension bypasses the execution of your custom transformation. For example, in a Java website, the Page content filter will bypass the execution of any subsequent filters by default. In this case, disable request forwarding to ensure that your custom filter will be called.
- Bypass application-level caching
-
If your web application applies caching of its own in addition to the caching provided by SDL Tridion Sites, you should disable caching for session-specific content. You can find out if the content being retrieved is session-specific by checking for the presence of the Claim with the URI taf:session:preview:preview_session. If this Claim is present, disable caching so that you will neither add items to it, nor retrieve items from it.
- Use the session-specific content in your custom filter
-
Chain your custom filter to fetch the output of the Page content filter and binary content filter. These session-aware filters will check for fresher content in the session database, and if such content exists, create a temporary file in the web application that takes the session into account. Requests for the original resource from Experience Manager should now return this temporary file as a response.
- Forward a token to the Content Delivery web service
-
If your application architecture encompasses a front-end that interacts with the Content Delivery web service, you must make the Content Delivery web service aware of Preview context. To do so, forward the Preview token by doing one of the following:
- You can forward the received custom HTTP header named
X-Preview-Session-Token - You can forward the received cookie named
preview-session-token.
- You can forward the received custom HTTP header named