I just realized that when creating a hyperlink in Rich Field Text on any page in a collection, you are provided access to easily link to literally any other page in that same collection.
Considering this, and considering the hassle of figuring out weird workarounds, often running out of space for more collections on a page just to provide a few blog tiles with their URL, all the way to putting permalinks in CMS fields or using reference fields, etc. etc. — I feel I must confirm that I am not crazy and that there is no way to do this except in Rich Field Text.
Bonus points if anyone can explain the logic behind neglecting something so very obvious like … finishing a feature in your product?
–
HOLD UP — it isn’t even just the collection the Rich Field Text block is part of — you have access to literally every single page in every other collection.
How is realizing this not mildly infuriating. Hours of time wasted. And honestly, it since it needs to be a hyperlink of text in the Rich Field Block, it won’t even be that helpful in the future.
Certainly not as helpful as, say, doing this for any link creation? Genuinely curious what was said that stopped someone from taking that next, hopefully logical and natural, step.
Yes, you can create a link in a Rich Text Block, and the link tool will enumerate all of the CMS items in every collection.
Yes, this works on the designer canvas, and in CMS rich text field editor, and through the content editor.
No, the standard link tool in the designer ( links, buttons, links in plain text ) cannot enumerate CMS items in the same way.
It’s been that way for the past 7 years at least, ever since I’ve been using WF.
As to the why, I can only guess, and my guess is the performance tradeoffs.
If you’ve noticed, in the designer when you Link an element ( link, button, nav menu, etc ) to a Page, that link is tracked. If you change the page slug, all of the links that link to it will be automatically updated.
In Rich Text Blocks, I believe all links are untracked. You can establish the link, but if you change the target Page’s slug, or a CMS item’s slug that you’ve linked to, that Rich Text link is not updated and will be broken.
If I had to imagine the dev meetings that led to this situation it would have been something like…
Hey cool the rich text element and CMS field type are ready, designers can build blogs now
Oh, customer feedback is that we really need to simplify cross-linking between blogs, since most blog content is written by site admins through the Content Editor
Ok let’s add the ability to form direct CMS item links into the Rich Text Element’s linking widget
Coolies, but how the f@#$@ do we track them for updates, if someone changes the slug, or drafts/archives/deletes an item/page they’ve linked to?
Urg… yeah, that would explode the server resources we need, inflate costs and crush system performance. Plus, it’s trickier to update links in rich text than it is in a link element.
Alright then, its decided… we’ll avoid tracking for now and circle back on this someday when quantum computing make server costs free.