We have moved to GitHub Issues
Created by Peter Slight 15 Jul 2013, 14:23:31 Updated by Mads Krohn 07 Oct 2013, 09:06:21
Is duplicated by: U4-2781
Relates to: U4-1304
I seemed to hijack a bug (U4-1304) by mistake which was stating that there is an issue with the locllink not being replaced when rendered.
It wasn't the same bug, so i have to make a another ticket. So here it is.
I am using the NodeFactory, as i am new to version 6 and NodeFactory still seems more performant at working the content than the razor extension/implementations, anyway, when working through a list of nodes and getting the property of the rich text editor .GetProperty("property") it is returning /locallink:NODEID and not the internal link.
As I said in the other ticket - damn the wrong place so seems to be ignored - "I have tried to wire my project into the source to try and debug, and it seems that the Umbraco.Web.Templates.TemplateUtilities.ParseInternalLinks(text) is just being passed empty strings. It is called the same amount of times as the number of locallinks in the page - i assume this could be the problem. Sorry if this is of no use. :-/"
hopefully this will help with a proper fix. i think this is an important bug, but maybe not ? :-s
FYI this has not worked since at least Umbraco 4.7 so it's not a new bug.
Fixed in changeset 8063717e4c7d9ecc88a6b9987940e6975369714e
For now you could wrap your GetProperty calls like so:
But honestly, the NodeFactory might be slightly faster for these operations, but there's easier alternatives. This uses the NodeFactory in the background as well: @
Or in an MVC Template you can do: @
Thanks for responding and not just closing Seb :)
Bit of a worry that it's possible that other sites I've build have this same issue then :-/
I've already made an extension method to parse the links (not ideal), but the purpose of reporting was the benefit of others really.
Have to revert this change in 6.1.4 as it's breaking the expectations of people who used to rely on the link NOT being parsed. So we'll mark it as a breaking change and fix it again in v7. If you're currently using 6.1.3 without the workaround you're going to have to implement the workaround again, sorry for the inconvenience!
Yes, it was definitely breaking our expectations. I don't mind the link parsing for convenience, but we at least need a way to get to the raw value of the xml cache, one way or the other.
Work around for parsing locallinks: Umbraco.Web.Templates.TemplateUtilities.ParseInternalLinks(value) //where value is the property.Value from the nodeFactory or just any string that contains Locallink:NODEID
@Per I set this to v7 as it's a breaking change, it can not be changed in v6 (the changeset is there so it's easy to cherrypick and include).
Fixed in rev 1a9e5f20a858bc73c3dfb7468b050be650c467e0
Fixed how exactly ? :)
@Mads https://github.com/umbraco/Umbraco-CMS/commit/1a9e5f20a858bc73c3dfb7468b050be650c467e0 In other words: in v7 you will not get the localink any more but the actual URL, like it was always intended.
Did anyone investigate whether this breaks Courier? I'm not sure where/when Courier is using the local link thingy, but pretty sure it does use it.
@Morten Shouldn't. This isn't about storing the values, but getting them from the cache (nodefactory).
Ahh, its the property object for published content. Never mind... Thought it was the one from the (content) model.
As you were :-P
So, from v7 and forward it's no longer possible to get the raw value of properties ? I really don't agree with that decision. Url parsing really should be handled somewhere higher up the chain.
At least there should be a way to get the raw value somehow.
@Mads And I look forward to your pull request. You've been using something that was never intended to be exposed in this way at all. :)
The Property (or IProperty) on IPublishedContent should contain the value (or data) as it should be rendered. The Umbraco.Core.Models.Property, which is part of IContent contains the raw value and will continue to do so. So maybe a feature request along the lines of "hook to override published values" is more relevant then having raw values as the published content's values.
Morten, that definitely makes sense.
Backwards Compatible: False
Due in version: 7.0.0