Cross Site Linking Woes

We are currently on RX 6.5.2 patch RX-13307

The scenario is the following:
We have content X in Site A in which we want to link to content Y in Site B.

Edit content X, Insert RX Template (title link snippet of Content Y) in the body of content X, Save Content X

The Problem:
On Preview, the link works as expected, it goes of to Content Y in Site B. However, when we publish the items (both are public), the link points itself back to Site A (using a relative link)


  1. Having read we added the folder id (we had the site id) and re-created the steps, but the problem manifested itself again.
  2. When we publish out the $, $, $ in the title link, they are correct (they reference Site B)
  3. When checking Site Folder Assembly location scheme, $sys.crossSiteLink is false
  4. Adding the same template link (of Y) to a slot on the template for Content X worked (ie. RX added the correct host name of Site B)! which lead to
  5. Calling the inline slot (sys_inline_variant) directly in the template for Content X publishes a correct link to Y (ie. using macro slot_simple). Clearly this is not a solution.

The Questions:

  1. Is anyone else having a problem with cross site links?
  2. Why isn’t this working? Why, when you insert an inline template (or rx link) in the body field (an ephox field) to another content item on a different site does Rhythmyx not correctly put in the correct URL on publish (ie. why doesn’t it think that it is a Cross Site Link)?
  1. Yes, we had problems with this in 6.0. We just upgraded to 6.5.2 but haven’t had a chance to test it.

  2. I’m intersted to learn the answer to this question.

I tried one more thing. I inserted the Link to Content Y in a brief and then included it to both the body and the slot. And the results were the same. When using #field(‘body’), the link doesn’t publish out with the hostname for Site B. When using #slot_simple it does. When it is in the another slot (aside from sys_inline_*) it works.

This sort of implies of an error in the assembly of an ephox field when being called directly by a template (as opposed to being assembled via a slot macro).

FYI, contacted tech support, they were able to reproduce it on an “out of the box” system and the bug id is RX-13550.