I'm working with a multisite solution with 3 sites.
I'm struggling with a curious issue when editing XhtmlStrings in TinyMCE (epi-link).
When creating a new link from site 2 to site 1 (editing on site 2, creating a link to site 1), I am able to pick a Page from site 1 in "Page". Using the code plugin (HTML view) I can see that pre-publishing, it creates the expected href="~/link/c11fdbcc(... etc).aspx link. If I publish the page, the link shows up as expected on the web site, with the proper nested url (https//correct-domain:portno/(language)/my-folder/my-page).
However, if I go in to edit the XhtmlString again after publishing, the a-tag is empty (no href), when expecting a href of type href="/EPiServer/CMS/Content/(language)/my-folder/my-page,,(contentId)/?epieditmode=False". Pressing the epi-link icon on the link, "Page" radio button is selected, but the field is empty. Needless to say, when saving the edited text, the link is also gone from the web view. But as the text shows up as a link while editing (if pressing "code" it updates to a non-link, but the editors usually don't enter HTML mode), this is not apparent to my editors, to them it's still a link. So the link is now gone for our users without the editors noticing.
A workaround is to use the External url field, but as the editors are able to choose a page through the Page option, there's a good chance someone will think it works (as it does, on first publish!), risking the link disappearing altogether without realising what has happened.
A workaround is to find a way to remove the site 1 pages from the Page options in site 2, but I'd rather try fixing the problem. Which basically is, while all the content remains in the same database (and is able to be fetched through ContentLoader etc), CMS is able to fetch and create the proper url on first creation of the link, but has issues when trying to fetch and create them when loading a page with the link already set.
There's a good chance "someone has done something" with access rights across the sites, or set some custom routing rules or whatnot, but what is a headscratcher to me is that it works on first publish. Although I assume different functionality is at play here - the real issue is, CMS is having problems fetching the proper data from /link/c11fdbcc(... etc).aspx. I have the same issue when, in a custom Extension class, trying to resolve the url using UrlResolver.Current.GetUrl() and the likes from the PageData content link ID. Which probably makes sense as this is based on route data... but I digress.
What I guess I'm aiming for with this thread is to
1) Have it confirmed that linking between sites in a multisite solution is supposed to work out of the box (assuming proper setup), and
2) Hopefully get some pointers of what could be wrong, where to start looking (continue looking, really) and maybe how to solve the problem
Update for anyone interested: Optimizely added a Bug for this issue on June 22nd this year, possibly related: /support/bug-list/bug/CMS-24056 (I'm not allowed to post links)
Hello,
I'm working with a multisite solution with 3 sites.
I'm struggling with a curious issue when editing XhtmlStrings in TinyMCE (epi-link).
When creating a new link from site 2 to site 1 (editing on site 2, creating a link to site 1), I am able to pick a Page from site 1 in "Page". Using the code plugin (HTML view) I can see that pre-publishing, it creates the expected href="~/link/c11fdbcc(... etc).aspx link. If I publish the page, the link shows up as expected on the web site, with the proper nested url (https//correct-domain:portno/(language)/my-folder/my-page).
However, if I go in to edit the XhtmlString again after publishing, the a-tag is empty (no href), when expecting a href of type href="/EPiServer/CMS/Content/(language)/my-folder/my-page,,(contentId)/?epieditmode=False". Pressing the epi-link icon on the link, "Page" radio button is selected, but the field is empty. Needless to say, when saving the edited text, the link is also gone from the web view. But as the text shows up as a link while editing (if pressing "code" it updates to a non-link, but the editors usually don't enter HTML mode), this is not apparent to my editors, to them it's still a link. So the link is now gone for our users without the editors noticing.
A workaround is to use the External url field, but as the editors are able to choose a page through the Page option, there's a good chance someone will think it works (as it does, on first publish!), risking the link disappearing altogether without realising what has happened.
A workaround is to find a way to remove the site 1 pages from the Page options in site 2, but I'd rather try fixing the problem. Which basically is, while all the content remains in the same database (and is able to be fetched through ContentLoader etc), CMS is able to fetch and create the proper url on first creation of the link, but has issues when trying to fetch and create them when loading a page with the link already set.
There's a good chance "someone has done something" with access rights across the sites, or set some custom routing rules or whatnot, but what is a headscratcher to me is that it works on first publish. Although I assume different functionality is at play here - the real issue is, CMS is having problems fetching the proper data from /link/c11fdbcc(... etc).aspx. I have the same issue when, in a custom Extension class, trying to resolve the url using UrlResolver.Current.GetUrl() and the likes from the PageData content link ID. Which probably makes sense as this is based on route data... but I digress.
What I guess I'm aiming for with this thread is to
1) Have it confirmed that linking between sites in a multisite solution is supposed to work out of the box (assuming proper setup), and
2) Hopefully get some pointers of what could be wrong, where to start looking (continue looking, really) and maybe how to solve the problem
Both sites are currently on:
EPiserver.Framework 11.20.12
EPiServer.CMS.Core 11.20.12
EPiServer.CSM.UI 11.36.0
EPiServer.CMS.TinyMce 2.13.7
But according to my editors, this has "always" been an issue since setting up the multisite.