This came up today. A few guys on the front-end team were trying to figure out why a link wasn’t working. I came in on the tail-end of the problem, when one of them shared the source code for a link. They were ready to start down the path of, “let’s find it in the codebase!” when I noticed that it wasn’t a front-end issue at all.
So here’s a quick tip for you front-end developers dealing with Tridion. Not every link that doesn’t work is your fault
When Links Go Loony
Here’s an example of what the link looked like, in the source code (used with view source, not inspect element) :
<a xlink:href="tcm:110-65581" title="How to sell amazing thinks" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:title="How to sell amazing things">Link to amazing things</a>
Notice what attributes you see there:
What you want to see is something like this:
<a href="link/to/page.html" title="How to sell amazing thinks"> Link To amazing things </a>
These are all clear signs that something has gone wrong on the content-management side. If you’re a front-end developer, you can’t fix this.
In Tridion, you can’t really link to pages. You link to the components that are on a page. When you do that, and then publish a page (or a component), a link resolver steps in, and it turns the markup that you see above, into a properly resolved link.
When you’re seeing a link that looks like the first example, there’s little you can do to get it looking like the second example:
Someone could possibly correct this link by:
- Publishing the page that the target component is on, or
- Publishing the target component
Whether a content author needs to republish the component, the page, or both, depends on the kind of Tridion implementation you have. But, you as a front-end developer can’t do anything about this. And if republishing component and page don’t work, it’s time to get a glass of whisky, present it to your nearest back-end developer, and ask for some help.