Dynamic Links in Content

Sharon Parry asked on March 28, 2019 01:15

Hi,

I've got an interesting problem to try and solve, which is more a CKEditor problem rather than Kentico, but curious whether anyone has ever achieved this. The website is a version 9.0.18 application, but I don't think that would have a bearing on the problem.

The website scenario is:

  • There are about 6,000 pages (documents) - most of them standard content pages, although a large percentage are custom pages (documents) that do not have standard CKEditor WYSIWYG content areas.
  • The standard content pages are grouped under 8 level-1 pages, drilling down in some sections to a maximum of level-4.
  • About 2/3 of those standard content pages are not displayed on the menu. They are accessed by links that have been entered into content areas on pages - so that means about 1,000 pages (or more) have "hard-coded" links to various pages. By "hard-coded" I mean that content editors (4 content editors) have inserted them by clicking the Insert/Edit Link button on the toolbar and navigating to the relevant page to insert the link. So, for example, the html in the content area for a link would be "/[Section-title]/[Perhaps-a-Second-Level-Title]/[this-is-the-page-that-is-linked]"
  • There are approximately 40 "Member" roles, with approximately 1,500 users each assigned to their individual "Member" role.
  • Access permissions are assigned to the various Member roles at the page level.
  • Not all member roles have access to all pages - the member roles have access to usually only a small sub-set of all the pages (documents).

Managing the content of the site and the content permissions has become extremely cumbersome and inefficient for the content editors, and so the site tree is being reconfigured as follows:

  • A folder is created at Level-1 in the name of the Member role. Let's call it "Icecreams-by-Ivy". Inside that folder a sub-set of ONLY the pages (documents) that the particular role has access to are created as LINKED pages (shortcuts to the actual page).
  • A special "Home" page created as a new page, with the Page URL Path setup (using my "Icreams..." example section) as "/icreams-by-ivy".
  • Access permission for the relevant "icreams-by-ivy" role is assigned at the Folder level, with all pages below that inheriting from the parent. That is the only role that is assigned permission to access that section of the site.
  • Members will then access their section of the site by going to https://[site-name]/icreams-by-ivy

Any links that have been created by code within *.cs files are all working perfectly.

HOWEVER, the problem is the links inserted into the content areas will send the user back to the ORIGINAL page, rather than to its linked page within the relevant section.

I've been able to amend all the relevant menus (in c#) by testing for the base path like:

    string sBaseNode = "";
    string parentPath = "/" + DocumentContext.CurrentAliasPath.Split('/')[1];
    if (!String.IsNullOrEmpty(parentPath))
    {
        CMS.DocumentEngine.TreeNode node = null;
        UserInfo ui = UserInfoProvider.GetUserInfo("administrator");
        CMS.DocumentEngine.TreeProvider tree = new TreeProvider(ui);
        node = tree.SelectSingleNode(SiteContext.CurrentSiteName, parentPath, "en-au");
        if (node != null)
        {
            bool bFolder = node.IsFolder();
            if (bFolder)
            {
                sBaseNode = node.NodeAliasPath;
            }
        }
    }
    if (!string.IsNullOrEmpty(sBaseNode))
    {
        this.Cmslistmenu1.Path = sBaseNode + "/%";
        this.lnkHome.HRef = sBaseNode + "/";
    }
    else
    {
        this.Cmslistmenu1.Path = "/%";
        this.lnkHome.HRef = "/";
    }
    this.Cmslistmenu1.ReloadData();

SO ....

Has anyone got any ideas on how I can achieve similar functionality for links inserted directly into content areas? ie, if the page is a linked page within a member-folder, the link in the content area will be prefixed by the section title - eg: "/icecreams-by-ivy/".

Recent Answers


Peter Mogilnitski answered on March 29, 2019 13:49 (last edited on March 29, 2019 13:50)

Not quite sure I understand, but here is my 2 cents: if you are editing you should have this editor menu with widgets to insert:Image Text

There is a link widget, the editors should always insert links using this link widget:

Image Text

All you logic for link processing should be incapsulated insde this widget or its clone.

0 votesVote for this answer Mark as a Correct answer

Sharon Parry answered on March 30, 2019 23:20 (last edited on March 30, 2019 23:22)

Thanks for your reply, Peter, however the main problem is all the links that already exist in the content of about 1,500 pages. I was hoping to find a solution that would deal with all those existing links as well as links in new content, without the content editors having to learn something new when a link is inserted into content.

I think I've found something that works, although it requires running an update script on the database to modify all the existing content, and then teaching the editors what they would need to do from now on when creating new content.

  1. Add a dynamically created <base> tag as the first item in <head> of the master template which sets the base url. So, for example, when the page is accessed via the main site, the base tag would be (eg) <base href="https://thesite.com/" />. If, however, the page is accessed via the "Icecreams by Ivy" section of the site, the base tag would be <base href="https://thesite.com/icrecreams-by-ivy/" />.
  2. Update ALL content and replace "~/" with "" where the content IS NOT like "~/getmedia" or "~/getattachment" - ie, update all links to pages, removing the prefixed "~/"
  3. Whenever a NEW link is inserted into a content area by an editor, always use the Insert/Editor Link button on the toolbar (which they already do, anyway), navigate to the relevant page, and then manually DELETE the prefixed "~/" that is displayed in the URL textbox on the Insert link dialog BEFORE they click the "Save & Close" button.

We've got to do a lot of testing before any of this is deployed live, but so far for everything we've tested appears to be redirecting correctly.

0 votesVote for this answer Mark as a Correct answer

   Please, sign in to be able to submit a new answer.