Server Side Includes (SDI) Not Working on AEM 6.5.15 | Community
Skip to main content
J
jonathanRad
Level 2
November 15, 2023
Solved

Server Side Includes (SDI) Not Working on AEM 6.5.15

  • November 15, 2023
  • 3 replies
  • 1623 views

Hello, we have a Dev env where after we upgraded from 6.5.4 to 6.5.15, our SSI/SDI includes started failing.

 

The include is called on the Publisher directly with a suffix of user UUID:

/content/<path to page>/<page>.html/<user UUID> --header "Server-Agent: Communique-Dispatcher"

 

When include works correctly, the rendered include looks like:

 

<!-- SDI include (path: /content/<path to component>/_jcr_content/root/responsivegrid/orgchart.nocache.html/<user UUID>, resourceType:, <component resource type>) -->

 

However, after the upgrade, our SDIs are failing and render as:

 

<!-- SDI include (path: /content/<path to component>/_jcr_content/root/responsivegrid/orgchart.nocache.html/<component resource type>.html, resourceType:, <component resource type>) -->

 

Note that instead of having a suffix of the user UUID, the SDI has the <component resource type>.html.

 

Any ideas about what is going here would be most helpful! TIA! 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by kautuk_sahni

Answer shared by @jonathanrad 

 

We found the issue and came to a resolution on this. Basically our issue is this https://www.mail-archive.com/dev@sling.apache.org/msg129314.html. Somewhere between SP11 and 15 the behavior of Synthetic Resources changed to remove the URL suffix and replace it with the component resource type. This behavior is in UrlBuilder in the Sling API. So if you're using a suffix to pass information to your component, it will no longer work. We worked around the issue by using a URL selector instead of the suffix. The SSI feature then creates an include with the selector intact and the component can get it from the URL using the RequestPathInfo.getSelectorString(). Hope this helps! 

3 replies

arunpatidar
Community Advisor
arunpatidarCommunity Advisor
Community Advisor
November 16, 2023

Hi @jonathanrad 
Can you try to put a debugger/logger and check , what is contributing to this unexpected behaviour?

Arun Patidar
    G
    GiuseppeTorrisi
    December 21, 2023

    Hello @arunpatidar 

    Just to verify if the SDI is functioning properly, in the log which class should I include? thank you

      arunpatidar
      Community Advisor
      arunpatidarCommunity Advisor
      Community Advisor
      December 21, 2023

      Hi @giuseppetorrisi 
      You can enable logs for the following bundle https://sling.apache.org/documentation/bundles/dynamic-includes.html#installation-1

      Arun Patidar
        kautuk_sahni
        Community Manager
        kautuk_sahniCommunity Manager
        Community Manager
        November 20, 2023

        @jonathanrad Did you find the suggestions from users helpful? Please let us know if more information is required. Otherwise, please mark the answer as correct for posterity. If you have found out solution yourself, please share it with the community.

         

        Kautuk Sahni
        kautuk_sahni
        Community Manager
        kautuk_sahniCommunity ManagerAccepted solution
        Community Manager
        January 2, 2024

        Answer shared by @jonathanrad 

         

        We found the issue and came to a resolution on this. Basically our issue is this https://www.mail-archive.com/dev@sling.apache.org/msg129314.html. Somewhere between SP11 and 15 the behavior of Synthetic Resources changed to remove the URL suffix and replace it with the component resource type. This behavior is in UrlBuilder in the Sling API. So if you're using a suffix to pass information to your component, it will no longer work. We worked around the issue by using a URL selector instead of the suffix. The SSI feature then creates an include with the selector intact and the component can get it from the URL using the RequestPathInfo.getSelectorString(). Hope this helps! 

        Kautuk Sahni
        Terms & ConditionsAccessibility statement

        Loading footer...