Hi,
we have a certain sitemap configuration that does not work with the experience manager preview functionality and are wondering whether customization options are available so we can make this work. Or what other advice we can get on the matter.
What I’m talking about is the following button:
It seems that the content path of the document cannot be properly translated to a sitemap item. As an example, this is a possible value of the hst:relativecontentpath property: acties-claims/acties/acties/${1}-content/_artikelen/${2}. I looked around with debugging tools to find out what is happening and noticed this is converted to LocationMapTreeItem objects. ${1}-content converts to key value _default_-content and ${2} to _default_. The latter receives the flag isWildCard, but the first does not. I suspect this is where the problem lies and why the content path cannot be mapped to a sitemap item. I suppose the wildcard elements are meant to be used as entire path segments, both for site urls and for content paths, and not as partial path segments. Still, we would like to know whether there are any customizations we can perform to make this work.
The other way works fine. When navigating to the url directly, the document located at the relative content path is found.
Thanks in advance!
Kind regards,
Maarten
1 Like
Can you share your sitemap configuration that serves this?
Hi Jasper,
Here is a little screenshot with the information that I think is relevant:
And some yaml:
/hst:hst/hst:configurations/cbhippowebsite/hst:workspace/hst:sitemap/acties-claims:
jcr:primaryType: hst:sitemapitem
hst:componentconfigurationid: hst:pages/acties-claims-home
hst:refId: acties-claims
hst:relativecontentpath: acties-claims/homepage/acties-claims-homepage
/acties:
jcr:primaryType: hst:sitemapitem
hst:componentconfigurationid: hst:pages/acties-claims-acties-home
hst:refId: acties-claims-acties
hst:relativecontentpath: acties-claims/acties/homepage/acties-homepage
/_artikelen:
jcr:primaryType: hst:sitemapitem
hst:componentconfigurationid: hst:pages/errorpage
hst:hiddeninchannelmanager: true
hst:statuscode: 404
/_default_:
jcr:primaryType: hst:sitemapitem
hst:componentconfigurationid: hst:pages/errorpage
hst:statuscode: 404
/_default_:
jcr:primaryType: hst:sitemapitem
hst:componentconfigurationid: hst:pages/acties-claims-acties-content
hst:relativecontentpath: acties-claims/acties/acties/${1}-content/_artikelen/${2}
HI,
That looks correct, so you may have found a bug. I have had a look through the code, and in one code path the default is checked with contains and in another it is an exact match. Now these code paths serve different purposes and I haven’t traced all the interactions so I have not confirmed there is a bug, but your sitemap looks ok. I’ll try and do some testing today to see if I can confirm.
Thanks for your help! I look forward to hearing your conclusions.
In case it helps, this is a screenshot I took while debugging.
I haven’t had a lot of time to look at this, but I have tried to recreate your situation. I don’t think I quite got there, so I don’t have a conclusion for you. I do have some followup questions. What version are you running? How did you create that sitemap? Why is it in the workspace?
I did somewhat reproduce your situation though, so I do think your are correct that it doesn’t work. It is specifically the {1}-content it doesn’t like. I will create a bug report so it can be looked at more thoroughly than I can do right now.
Hi Jasper,
Thanks for creating the bug report! Can it be viewed publicly in the Jira issue tracker? Or was it only created somewhere internally?
As for your questions, we are running Bloomreach enterprise version 15.2.3. Interesting comment about the sitemap being in the workspace. As it is entirely developer maintained it should probably not be there. It was created by adding it to the repository-data bootstrap configuration. We’ll look into moving it outside of the workspace.
I was thinking if there was a workaround for your issue. You could possibly do something with link processors. Then you reduce your sitemap to using pure wildcards, but do the processing to add the -content in the link processor. Not 100% sure if that will work, but I think so.
We do use custom link processors in the site application. I wasn’t aware they could be used in the cms application. Are you sure this could work? In that case, we will give it a try.
Thanks for the link to the issue!
In the experience manager the site still has to go through hst processing. I’m fairly certain this will work, but it’s been some years since I implemented a link processor myself. I would suggest to do a simple test to verify this is a possible solution, but I can’t right now think of another.
