Using Rhythmyx 6.50 we have two sites.
A content item in Site1 (id 305) links to a content item in Site2 (id 315) via EPhox as a Rhythmyx inline link.
The content item in Site1 has in fact two inline links to the content item in Site2 - one that is displayed in a page template (using the body field) and one that is displayed as part of a snippet (using the callout field). The HTML for both is identical:
<a sys_dependentvariantid="678" rxinlineslot="103" href="http://uslcms01:49992/Rhythmyx/assembler/render?sys_revision=2&sys_siteid=315&sys_authtype=0&sys_context=0&sys_contentid=5398&sys_variantid=678" sys_dependentid="5398" title="" sys_variantid="678" sys_relationshipid="19514" sys_contentid="5398" sys_siteid="315" inlinetype="rxhyperlink" sys_folderid="">
If we preview the page in Site 1, the link in the body text navigates to the content item in site 2 correctly.
In Site2 there is another content item that has a manual slot. in this slot a link to the content item in Site1 is made. The slot template renders a link to the content item and the callout (which is a link to the content item on Site2). However the link in the callout is using Site1’s id:
<a href="http://uslcms01:49992/Rhythmyx/assembler/render?sys_revision=2&sys_siteid=305&sys_authtype=0&sys_contentid=5398&sys_variantid=678&sys_folderid=5346&sys_context=0" title="">
Why is the site id being changed? Is the use of a slot interfering with the site id?
For a Cross site link (which is what we call this), it depends on how the link was created (and which Display Format was used in the search where the link was added).
When a link is added, if the Display Format of the search contains columns for the Site Id and Folder Id, these values will be added as “relationship properties”.
The presence or absence of the relationship properties is what makes a link point to the same site or to a different site.
In your case, you need to examine the 2 relationships (the inline one, and slot one), and see if in fact they have relationship properties named “sys_siteid”.
We added the sys_folderid to the Related_Content_By_Type and Related_Content_By_Template display formats and the urls in the lists are now correct and navigate to the second sites content.
We then tried setting the nav_landing_page of a navon in Site1 to point to a content item in Site2 but the page renders in Site1. The sys_folderid in the nav:url pointed to the folder that is in Site2 but the sys_siteid in the nav:url was Site1.
Is something else needed?
You never said it was a Nav Landing page. Nav links work very differently from normal links.
That said, cross site links are supposed to work in Nav links, but it would not surprise me if they don’t.
It wasn’t originally a navon link problem it was a snippet used in a slot for a page template.
That said we have now seen this problem in another piece of content. In this example we have a page template that renders the body text (which included a Rhythmyx inline link) and an embeded movie.
The cross-site link in the body content had the wrong sys_siteid but the correct sys_folderid. Investigating this a bit further I removed the binding $rx.location.generate($sys.assemblyItem, “tcsBnMovieAndAudio”) and the sys_siteid in the link was correct.
Does the navon use $rx.location.generate to get the url?
All of the location generation functions call the same underlying code.
I’m curious about 1 thing: instead of removing the binding, change the name of the variable that it binds to: $pageXlink = $rx.location.generate(…).
If that produces the correct site link, then the issue is the variable names, not the location scheme generator. If the site id is wrong, then there’s something going on inside the link generation code.
Let us know what happens
Renaming the variable or calling the generateLocation function directly rather than using the binding variable resulted in the same problem.
We did try another workaround which is to add a link copy of the content from Site1 to Site2 and when adding this to our manual list slot in Site 2 we selected the linked content item in Site 2. The link url in the slot template then used Site 2’s id. With a change to the location schema the links were ok. Not ideal and we still have the problem with the navon.
We need to look at this issue a bit further. It’s likely that this is a bug. One of our developers has been assigned to examine these link issues (there have been a couple of other related ones reported in other threads lately). We need to decide which of these things we can fix, and which ones we cannot.
Linking a navon nav_landing_page to content in another site was resolved with fix RX-13545 - “Cross site links are not handled properly from managed nav.”