Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

CQ5/AEM - Certain links are not rewriting

Avatar

Level 2

We're experiencing some inconsistency with URLs on our publish instance. Some links are having the /content/project/ removed whilst others are not.

The /etc/map has been created and seems to be working as expected, except for these links.

An example of where the rewriting is links in the OOTB Text component. Just highlighted the text and used the hyperlink in the RTE. The output HTML on publish comes through as the desired

<a adhocenable="false" href="https://forums.adobe.com/path/support.html">My Link</a>

A link that's not being rewritten is from a component, in it's dialog we have a richtext xtype that is referenced in the jsp

<cq:text property="description">

This however is output on the publish as:

<a adhocenable="false" href="https://forums.adobe.com/content/project/path/support.html">Other Link</a>

I've had a look in /system/console/configMgr and the Day CQ Link Transformer Checker and this has a:href, area:href, from:action, input:value. So I thought this would pick up the links under anchors.

If anyone can suggest where I should be looking to resolve this, any help would be appreciated.

1 Accepted Solution

Avatar

Correct answer by
Level 10

It should work because rewriter called after html is generated. Just that your custom implementation causing not closing tags properly causing the issue.  Here are the steps to debug

1)   Access components directly <path of component>.html   ex:-  /content/geometrixx/en/jcr:content/par/text_1.html

2)    Verify it is well formed and is closing all html tags properly.

3)     If no issue in step2. Tail error.log and request for "<path of component>.html" see if there is xss warning.

4)     If no issue in step3 in component where ever you have href written add additional attribute x-cq-linkchecker= skip and update the forum with output of "<path of component>.html"

OR

1)     Disable link checker, After the change all rewrite does not happen.

2)      Access the page & go to view source of page

3)     Verify it is well formed and links in valid url in terms of syntax also.

View solution in original post

11 Replies

Avatar

Correct answer by
Level 10

It should work because rewriter called after html is generated. Just that your custom implementation causing not closing tags properly causing the issue.  Here are the steps to debug

1)   Access components directly <path of component>.html   ex:-  /content/geometrixx/en/jcr:content/par/text_1.html

2)    Verify it is well formed and is closing all html tags properly.

3)     If no issue in step2. Tail error.log and request for "<path of component>.html" see if there is xss warning.

4)     If no issue in step3 in component where ever you have href written add additional attribute x-cq-linkchecker= skip and update the forum with output of "<path of component>.html"

OR

1)     Disable link checker, After the change all rewrite does not happen.

2)      Access the page & go to view source of page

3)     Verify it is well formed and links in valid url in terms of syntax also.

Avatar

Level 2

Thanks for the info.

Step 2: The HTML looks to be well formed. And just to confirm this I edited the code to be very basic, with just one link from a path field and another from the rte in the dialog.

<%@page session="false" import="org.apache.sling.commons.json.JSONException, org.apache.sling.commons.json.JSONObject"%> <%@include file="/apps/charlotte/global.jsp"%> <c:set var="currentMode" value="<%= WCMMode.fromRequest(request)%>"/> <c:set var="editmode" value="<%= WCMMode.EDIT%>"/> <c:if test="${(currentMode == editmode)}"> <div class="comp-edit-msg">Edit Message</div> </c:if> <div id="getgot-charlotte-placeholder" class="ajax-hdlebar-placeholder"></div> <div> <a x-cq-linkchecker="skip" href="${properties.gotactionUrl}.html">This is the test text</a> <cq:text property="gotdescription"></cq:text> </div>

Step 3 - there didn't seem to be any errors in the logs

Step 4 - I added in the attribute as requested HTML output is :

<div id="getgot-charlotte-placeholder" class="ajax-hdlebar-placeholder"></div> <div> <a href="https://forums.adobe.com/content/charlotte/got/my-account/profile-settings/link-account.html">This is the test text</a> <p><a adhocenable="false" href="https://forums.adobe.com/content/charlotte/got/my-account/profile-settings/link-account.html">Link</a> from a rte in the dialog.</p> </div>

 

I did notice that from the component that was working - the path from the dialog was being passed through resourceResolver.map(), before being output. This explains why this is working. (so currently any links not being passed through the resourceResolver isn't rewriting) 

Could this point to the rewriter after the HTML generator not being set-up correctly? (although I thought that this was just using the same config that the resourceResolver was using?)

EDIT: Also to note. I've been running with the content on my localhost, and the links are being mapped correctly for the same components. That could be pointing towards an issue with the mapping config - I'll keep looking into that.

Avatar

Level 2

Thanks for the links. I was expecting the OOTB to be able to handle the rewriting without having to define my own

I did notice that from the component that was working - the path from the dialog was being passed through resourceResolver.map(), before being output. This explains why this is working. (so currently any links not being passed through the resourceResolver isn't rewriting) .

I tried to update the config as mentioned in the second link, but that didn't seem to do anything.

I added: /content/<my-project-name>/-/

Avatar

Level 10

Stenix wrote...

Thanks for the info.

Step 2: The HTML looks to be well formed. And just to confirm this I edited the code to be very basic, with just one link from a path field and another from the rte in the dialog.

  1. <%@page session="false"
  2. import="org.apache.sling.commons.json.JSONException,
  3. org.apache.sling.commons.json.JSONObject"%>
  4.  
  5. <%@include file="/apps/charlotte/global.jsp"%>
  6. <c:set var="currentMode" value="<%= WCMMode.fromRequest(request)%>"/>
  7. <c:set var="editmode" value="<%= WCMMode.EDIT%>"/>
  8. <c:if test="${(currentMode == editmode)}">
  9. <div class="comp-edit-msg">Edit Message</div>
  10. </c:if>
  11.  
  12. <div id="getgot-charlotte-placeholder" class="ajax-hdlebar-placeholder"></div>
  13.  
  14. <div>
  15. <a x-cq-linkchecker="skip" href="${properties.gotactionUrl}.html">This is the test text</a>
  16. <cq:text property="gotdescription"></cq:text>
  17. </div>

Step 3 - there didn't seem to be any errors in the logs

Step 4 - I added in the attribute as requested HTML output is :

 
  1. <div id="getgot-charlotte-placeholder" class="ajax-hdlebar-placeholder"></div>
  2.  
  3. <div>
  4. <a href="/content/charlotte/got/my-account/profile-settings/link-account.html">This is the test text</a>
  5. <p><a adhocenable="false" href="/content/charlotte/got/my-account/profile-settings/link-account.html">Link</a> from a rte in the dialog.</p>
  6. </div>

 

I did notice that from the component that was working - the path from the dialog was being passed through resourceResolver.map(), before being output. This explains why this is working. (so currently any links not being passed through the resourceResolver isn't rewriting) 

Could this point to the rewriter after the HTML generator not being set-up correctly? (although I thought that this was just using the same config that the resourceResolver was using?)

EDIT: Also to note. I've been running with the content on my localhost, and the links are being mapped correctly for the same components. That could be pointing towards an issue with the mapping config - I'll keep looking into that.

 

Everything looks fine to me. Mapping might be issue. To go systematically can you

*    also add x-cq-linkchecker="skip" inside the rte hyperlink also?  Also delete /var/linkchecker/http/* & /var/linkchecker/https/ and verify. 

*    If aem 5.6 make sure to install recommended hotfix because i know if you have broken vanity path it breaks the rewriting in some cases. 

*    Is it happening on all publish instance ? 

Avatar

Employee

Based on this description, I wonder if link rewriting is disabled entirely. It sounds like it is never happening at that some of your components are working around this by manually calling resourceResolver.map(). It should never be necessary to do that for rewritten attribute (a:href in this case). You do need to call resourceResolver.map() if you are, for example, embedding links in JavaScript.

Avatar

Level 1

Hello

Needed some help with similar issue and hope you guys can help.

With reference to issue related to links, should image tags be also handled using resourceResolver.map() ?  I have configured URL mappings under  'Apacge Sling Resource Resolver Factory' in OSGi config and all a:href are getting transformed but not img src. (URL mapping:  /content/myproj/-/ )

I added img:src to 'Rewrite Elements' under 'Day CQ Link Checker Transformer' settings but that also does not help.

My image ref is 
<img src="/content/myproj/us/en/disclaimer/_jcr_content/centerPar/image.img.jpg/1429637916075.jpg" alt="int-devtest" title="Intdevtest" data-emptytext="Image">

and I like to remove "/content/myproj/" from it as incoming URL rewrite will take care of adding this to requests.

I tried this on a HTML control on a sample page but I get a nasty error:
<img src="<%=resourceResolver.map("/content/myproj/us/en/disclaimer/_jcr_content/centerPar/image.img.jpg/1429637916075.jpg")%>" >

Any help would be appreciated.

PS: Using AEM6 + SP1

Thanks

Avatar

Level 2

OK - further progress.

It turns out that in the environment where I've been investigating this, the rewriting is not happening at all. Moving to another environment and also a local environment, then running through previous test I've been able to recreate the issue and identify the issue.

Justin was right - the links that are not rewriting are those that are contained in <script>, so we'll have to manually call the resourceResolver.map() for these links.

Avatar

Level 1

Sham HC wrote...

write own transformer for image https://helpx.adobe.com/experience-manager/using/creating-link-rewrite.html

 

Thanks Sham.

But does that mean there is no configuration way to rewriting asset links? And shouldn't explicit resourceResolver.map() call take care of this?

This seems too common a requirements to me and shouldn't have to write code for this.

Avatar

Level 10

D-Kay wrote...

Sham HC wrote...

write own transformer for image https://helpx.adobe.com/experience-manager/using/creating-link-rewrite.html

 

Thanks Sham.

But does that mean there is no configuration way to rewriting asset links? And shouldn't explicit resourceResolver.map() call take care of this?

This seems too common a requirements to me and shouldn't have to write code for this.

 


We filled enhancement require way back in 5.3 & did not see much demand. As of know not out of the box option and you need write own transformer.