On Linkage

Here's the situation: you make a spiffy new blog entry / news item in your spiffy CMS linking to another place in the spiffy CMS. Like this. Doesn't seem that complicated, but consider if this blog entry / news item gets reused elsewhere in the site on, for example, the front page. This is happening more frequently now, since there are other interesting reuse opportunities in new CMSs like page compositing. Perhaps the most proliferic use is giving each user a blog, and then aggregating all user blogs on the front page.

Now, how was your link formed? This is a big deal, and can cause a lot of grief. Here are a few choices, with some comments:

• Relative URL: href="../gallery/computers"
• This kind of link will break if the blog entry / news item is moved.
• It also breaks if the blog entry is used elsewhere. The path "../gallery/computers" doesn't exist when the item is, for example, shown on the front page.
• It also breaks if 'computers' is relocated.
• The only real plus side is that this link is easy to get right with most popular in-browser editors.
  
• Site Relative URL: href="/Members/fprimex/gallery/computers"
• This is much better, and will survive moving the blog entry / news item.
• It also works if the blog entry is used elsewhere. After all, no matter where you are on the site, "/Members/fprimex/gallery/computers" points to the same place.
• However, the link breaks if 'computers' is relocated or renamed.
• It's not very friendly to ask your CMS users to get links like this right.
  
• Absolute URL: href="http://www.fprimex.com/Members/fprimex/gallery/computers"
• This type of link has all of the effects of a Site Relative URL, with the additional negative of breaking if the domain name of the site changes.
  
• Site Reference: something like href="/stuff_finding_script?item=3764898"
• This link will survive moving, being used elsewhere, and relocating / renaming 'computers'. Drupal has links like this when you use "/node/19369172".
• One downside is that the link is not easy to remember and is ugly compared to something meaningful like '/Members/fprimex/gallery/computers'.
• Another downside is that doubling up on links (where both 'computers' and '/stuff?item=38' are used to point to the same piece of content) is a search engine scoring no-no.
  
• We're only concerned with internal links within the site here, but keep in mind that someone, somewhere may reference 'computers' using the nice URL and not the Site Reference way. If the nice URL is ever changed, the link breaks.

The landscape for making good internal links looks pretty dismal. But wait! There may yet be some hope for easy to create, quality linkage.

What I've decided to do in Plone

By default, it's hard to predict what kind of links you're going to get out of Plone using the Kupu editor. This is truely unfortunate, because it's such a big part of managing content. I think other in-browser, javascript based editors suffer from this problem - they're at the mercy of browser makers, after all. Here's some fun you may run into (from this email):

Some of the transformations which may happen to your links:

When you start editing in Kupu, IE will convert all links from relative to absolute.

During editing, Firefox will sometimes convert absolute links to relative (if you drag/drop images Firefox will convert absolute links to the *wrong* relative links which will break the images unless you also enable the link-by-uid feature).

When you save, Kupu will convert all absolute links to relative (obviously only where the links can be expressed as relative). Also, if you have enabled the link-by-uid feature it will reduce such links down to just a 'resolveuid' call.

When the page is rendered it is possible that some transforms may run on the page. One such transform supplied with Kupu but not enabled by default will replace all the 'resolveuid' links with the absolute url for the target. If you are using Apache rewrites this will result in an absolute http://www.somedomain.com link rather than the somehost:8080 link from when you edited the page.

The link-by-uid feature sounds pretty nice, but how is it different than the Site Reference above? Will it put ugly '/resolveuid/1928479' links throughout my site? The answer is thankfully 'no', and link-by-uid is a very good solution in almost all cases. Head to the Kupu settings and just tick the link-by-uid checkbox. Here's what happens:

• User inserts a relative link using the content browser in Kupu
• In the editor, this link will show up as a 'resolveuid/12093879eeoai' type of link
• When the page is viewed, the page goes through a portal transform that finds the content item and puts in our nice Site Relative URLs.

The only downside I can see is that you might take a performance hit resolving these UIDs on view, but this can be mitigated with caching. This type of link also suffers from the "someone, somewhere using the nice URL" problem, but remember we're mostly only concerned with links within the site.

Link-by-uid is a great way to do your internal linkage!