Links in Page Builder/Preview vs the live (channel) site - SaaS

2025/03/23 11:44 PM

How do you ensure that links in Page Builder/Preview render with the proper channel domain, and not the Administrative domain?

I have examples where a link that starts with a / renders correctly in Page Builder/Preview and the live site, and also examples where in Page Builder/Preview the link renders with the Administrative domain.

The '~' character doesn't seem to help either, as also sometimes that works and sometimes it doesn't.

And, if I use an RTE to create a new link (that starts with / ), it gets a data-channel-guid attribute that appears to point to the correct channel and works, but after creating the link I can remove the attribute completely and the link still works.

I having trouble finding a consistent pattern where links do work, and where they don't work.

Environment

  • Xperience by Kentico version: [30.2.2]
  • .NET version: 8
  • Execution environment: SaaS

Answers

2025/03/24 5:55 AM

I remember having issues resolving preview URLs as well. Some links and URLs are handled automatically by XbyK. However, when this automation isn’t triggered, you’ll need to process the URLs manually.

For example, this can happen when resolving links for a JSON output within a .cshtml file.

Here are three methods that have helped me:

  • ApplyPreviewContext – This is likely the method you need to resolve URLs for preview. More details in the docs: Add preview context to URLs.
  • If you only need to apply the preview context in preview mode, check if the current context is in preview using Context.Kentico().Preview().Enabled.
  • If you're working with Media Libraries and have trouble resolving URLs, use the Url.Content method. More details in the docs: Retrieve content from media libraries.
2025/03/24 3:49 PM

Thanks Milan - I will look into what you mentioned and see what's what! :-)

2025/03/24 4:01 PM

Is there a way to ensure links in Preview mode (that were not handled automatically) get handled properly as a whole?

If I'm reading your response (and the docs you linked) right, it seems I would have to leverage ApplyPreviewContext for every single link. I don't think that's feasible, especially because the overwhelming majority of these links reside inside an RTE on a given page. And there are LOTS of pages. The links got there primarily by being migrated in using the Migration Tool, not manually added by a user.

How can I ensure that when in Preview mode, all of them are treated such that the proper channel domain gets added? Unfortunately, at this point, processing them manually (one at a time) just isn't realistic.

2025/03/26 7:46 AM
Accepted answer

The RTE links should be handled automatically. However, I suspect there might be an issue since your RTE content has been migrated. I looked into my XbyK site, and this is how the automatic URL resolution seems to work when adding links manually in the RTE:

  1. You select a page to be linked in the RTE editor.
  2. In the markup, an a tag is added with a relative URL in the href attribute and a data-channel-guid attribute that identifies your channel (it is the value of the ChannelGUID column in the CMS_Channel table). Example: 
    <a href="/about" data-channel-guid="0c3f353f-efc1-4975-99ef-9dec3bc2336d">About</a>
  3. If the RTE is within a widget on a page and the page gets saved/published, the href attribute will resolve automatically in the markup. If the RTE is inside a content item, it seems the URL is not resolved upon saving the item. The data-channel-guid attribute persists, and therefore the preview URL is resolved on-the-fly when rendering the actual page.

My assumption is that if you add the data-channel-guid to each a tag, the preview link resolution will work. However, first, check how your current links are built to verify that the above description is valid for your case.

In my custom migration scripts for a client site, I also manipulated links in RTE markup, so it should be feasible to create custom scripts that will modify the RTE markup in one go.

Since I don't have access to your migrated site, I can't validate my assumptions. Therefore, I recommend you put some effort into resolving this and then consult Kentico customer success team. Alternatively, you can hire me as a consultant.

To response this discussion, you have to login first.