scope used in sitemap behaves erratically when used in conjunction with common sitemap

[Martijn van der Vorst]

Hello,

A bit of setup before I get to the question, please bear with me.

Let's say our hst:configuration looks something like this:

• common
• sitemap
• commonurl
• hst:parametername : someparam
• hst:parametervalue : ${scope}
• dutch (inherits from common)
• sitemap
• dutchurl
• hst:parametername : someparam
• hst:parametervalue : ${scope}
• germany (inherits from common)
• sitemap
• germanyurl
• hst:parametername : someparam
• hst:parametervalue : ${scope}

we've set our sites up with hst:parametername: "scope" and values "dutch" and "germany" respectively.

When we go to the dutchurl when in the dutch site, the "someparam" is as expected "dutch"

Similarly when going to the germanyurl in the german site, the "someparam" is "germany".

However when we go to the commonurl within the dutch site, the "someparam" is "germany", same when we visit that url via the german site.

Is there a reason for this behaviour? I would have expected it to use the scope parameter from the site it entered, or nothing at all. but somehow it seems to pick one site at random, and runs with it.

Regards,

Martijn van der Vorst

[Ard Schrijvers]

Hey Martijn,

The behavior you describe is unexpected and would imply a bug. Is it
possible that you reproduce the setup with a simple archetype project
and that you share that one with me? Then I can dig into the problem
and if it turns out a bug in the HST, fix it right away. Would that be
an option for you?

Apologies for the inconvenience and thanks for your clear description

Regards Ard

>
> Regards,
> Martijn van der Vorst
>

> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hippo-communi...@googlegroups.com.
> Visit this group at https://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.



--
Hippo Netherlands, Oosteinde 11, 1017 WT Amsterdam, Netherlands
Hippo USA, Inc. 71 Summer Street, 2nd Floor Boston, MA 02110, United
states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

[Martijn van der Vorst]

Hello Ard,

here https://drive.google.com/file/d/0BxdqZi8NoUa4Q2tLLTRsVlV0TlE/view?usp=sharing you'll find a Hippo 11.1.0 project that works as I described.

it'll use 2 URLS: de.localhost:8080/site and nl.localhost:8080/site.

So make sure your hosts file (system) is configured to route those to 127.0.0.1.

then you have 3 URLs that you can test:

1. http://de.localhost:8080/site/commonurl
   
1. will show Dutch content (we want german content)
2. http://nl.localhost:8080/site/commonurl
1. Will show Dutch content
3. http://de.localhost:8080/site/germanurl
   
1. will show German content
4. http://nl.localhost:8080/site/dutchurl
   
1. will show Dutch content

Of course the homepage (/site) is also in the common, and also displays the unwanted behaviour.

Kind Regards,

Martijn van der Vorst

After more testing, the common urls show the content of the site that was first accessed using that URL.

[Ard Schrijvers]

Hey Martijn,

On Tue, May 9, 2017 at 2:02 PM, Martijn van der Vorst
<martijn.v...@hybrit.org> wrote:
> Hello Ard,
>
> here
> https://drive.google.com/file/d/0BxdqZi8NoUa4Q2tLLTRsVlV0TlE/view?usp=sharing
> you'll find a Hippo 11.1.0 project that works as I described.
>
> it'll use 2 URLS: de.localhost:8080/site and nl.localhost:8080/site.
>
> So make sure your hosts file (system) is configured to route those to
> 127.0.0.1.
>
> then you have 3 URLs that you can test:
>
> http://de.localhost:8080/site/commonurl
>
> will show Dutch content (we want german content)
>
> http://nl.localhost:8080/site/commonurl
>
> Will show Dutch content
>
> http://de.localhost:8080/site/germanurl
>
> will show German content
>
> http://nl.localhost:8080/site/dutchurl
>
> will show Dutch content
>
> Of course the homepage (/site) is also in the common, and also displays the
> unwanted behaviour.
>
> Kind Regards,
> Martijn van der Vorst
>
>
> After more testing, the common urls show the content of the site that was
> first accessed using that URL.

I suspect a lazy loading caching issue from what you describe: Most
likely some inherited configuration is incorrectly shared in cache.
Since it is lazy loaded, the first one 'wins'. Thanks a lot for your
setup, I'll investigate it and if it is what I suspect I'll fix it
(and otherwise find out what goes wrong)

Regards Ard

[Martijn van der Vorst]

Hi Ard,

Did you manage to track down the problem? We're now using a coded workaround (which is ugly, but it works), but it introduces a point of failure which we rather wouldn't have.

Regards,

Martijn van der Vorst

[Ard Schrijvers]

Hey Martijn,

I am so sorry, I didn't have time and then forgot about it. Will try
to investigate it this week!

Regards Ard

On Tue, May 16, 2017 at 11:35 AM, Martijn van der Vorst

[Martijn van der Vorst]

Hi Ard,

It looks like when the variable is used in the hst:relativecontentpath it works as it should, it's only when used in other properties that it behaves as I described earlier.

This is anecdotal, I haven't completely tested if this is the case, but first impressions look like it.

Regards,

Martijn van der Vorst

[Martijn van der Vorst]

I've added it to the onehippo issues list: HSTTWO-4023

On Tuesday, 2 May 2017 11:22:39 UTC+2, Martijn van der Vorst wrote:

[Ard Schrijvers]

Hey Martijn,

I've confirmed the odd behavior. I am investigating it now further.
Apologies that it took some time

Regards Ard

[Ard Schrijvers]

Hey Martijn,

I've fixed [1] and backported the fix to 11.2 and 11.1. It was indeed
correct that when using the variable in hst:relativecontentpath it
works as it should but not for parameternames/values. The problem was
that for parameternames/values I modified when resolving the variables
the backing property arrays in the backing HstNode (detached JCR node)
and this HstNode can be shared when configuration is inherited. The
hst:relativecontentpath is not an array but just a string value hence
manipulating that one didn't change the backing value in the (shared)
HstNode object. Either way, nice catch and thank you very much for
your clear reproduction. Apologies that it took some time before I had
time to look into it.

Regards Ard

[1] https://issues.onehippo.com/browse/HSTTWO-4023
[2] https://issues.onehippo.com/browse/HSTTWO-4036
[3] https://issues.onehippo.com/browse/HSTTWO-4037