aem-core-wcm-components: [Image] Does not call resourceResolver.map() - /content// paths used on publish
When the image component is used on a page, resourceResolver.map() is not being called when determining the smart images.
Result:
<noscript data-cmp-image="{"smartImages":["/content/project/nl/jcr%3acontent/banner.img.320.jpg","/content/project/nl/jcr%3acontent/banner.img.480.jpg","/content/project/nl/jcr%3acontent/banner.img.640.jpg","/content/project/nl/jcr%3acontent/banner.img.768.jpg","/content/project/nl/jcr%3acontent/banner.img.1024.jpg","/content/project/nl/jcr%3acontent/banner.img.1152.jpg","/content/project/nl/jcr%3acontent/banner.img.1440.jpg","/content/project/nl/jcr%3acontent/banner.img.1600.jpg"],"smartSizes":[320,480,640,768,1024,1152,1440,1600],"lazyEnabled":true}"> <img src="/content/project/nl/_jcr_content/banner.img.jpg" alt/> </noscript>
It seems to me that the resource resolved map’d URLs should be used, i.e. in this case: /nl/_jcr_content/banner.img.320.jpg
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 2
- Comments: 19 (13 by maintainers)
I think at that point we viewed it as fixing a bug (for v1) and not adding a change/improvement.
@richardhand Can you adjust the fix version then? Seems this was fixed with 2.0.4.
Looks like this was added in 9cb5ffb1335777c482ca0b66db762f6fe41f734d
Which is way after this ticket was created, for a different issue. So this can be closed now.
Given the known could-be-slings-fault issue with double encoding when calling
ResourceResolver.map()I would say it’s the responsibility of such a rewriter to handle decoding as ACS do. If it’s known that the image component rewrites its attribute, there would be no need to register our attribute with a rewriter in any case.So I would recommend we go ahead and do the mapping here.
I’m not sure I agree anymore. 😃
I just ran into an issue where someone had configured a sling:alias with spaces inside. The path that had this sling:alias configured was used in an href-attribute on an a-tag…
Now the issue was that we were calling resourceResolver.map() on it twice: Once via the ootb LinkChecker, and the second time via the ResourceResolverMapTransformerFactory from ACS AEM Commons.
This caused the URL to get rewritten from ‘/content/my/page.html’ to ‘/content/my/aliassed%20page.html’, which is fine. But then when the second map() call was done, it was rewritten to ‘/content/my/aliassed%2520page.html’.
So the question that we should raise here is: Who is responsible for calling resourceResolver.map()?
What is the recommendation from Adobe?
And how do you handle the case with spaces I explained above here? Apparently calling resourceResolver.map() multiple times can have side-effects that are not wanted.