Hi Suzy,

The problem is that with a Razor macro you need to go through an additional step to "RenderMacroContent", in Mvc this is taken care of (as it should be)

Try this in your Razor Macro

 @Html.Raw(umbraco.library.RenderMacroContent(Model.bodyText.ToString(), Model.Id))

Just a thought though, are you creating these Razor Macros for use in a RTE, if so then a "Macro Partial View" would be better as Razor macros are soon to be legacy.

Thanks,

Jeavon

That doesn't work, the links still aren't parsed.  The macro isn't going to be used in the RTE, I'm just trying to output RTE content using a macro but it isn't parsing the local links.

What I'm ultimately trying to do is add content to a sidebar.  I have a simple content widget doctype which just has a rich text editor field.  Using the multi node picker I can select one or more of these widgets to show in the sidebar of a page.  In the sidebar section on my page template I call a macro to output the widget contents.  Except it's not parsing the local links when I output the widget RTE content.

That works, thanks.

Although I changed the call to Umbraco.Web.Templates.TemplateUtilities.ParseInternalLinks as that one is marked as obsolete.

Ran into the same issue. Umbraco 6.1.3.

Hey,

Currently working on that one... while working on the various property converters. Ie, making sure that the RTE property converter does convert local links. In WebForms, there was a global local links conversion of the whole page content, after it had been rendered... so in many cases you had local links conversion "for free" even though RenderMacro, or property converters, forgot to parse them.

Obviously that does not work with MVC, and I'm not sure we want to add a post-action filter to parse the content and filter local links.

I'd much rather make sure they are filtered / parsed in the right place. Which would mean that what is reported by suzyb is a bug. That I'm willing to fix.

What do ppl thing?

Hi all, is this a confirmed bug? I've just noticed it with a 6.16 install.

@Alan: it is  confirmed. What we need to figure out now is what's the best way to fix it.

thanks Stephen

Although I was able to get this to work. There are many users that did not. Umbraco needs to do a better job of making sure all of it's core functionality works before trailblazing down new release paths.

I'm having the same issue in 7 and 7.0.1.  Is it still not fixed or am I missing something? We're still using 4.11 in production, never moved to v6 because of issus ike this.

It is a basic feature of any CMS so I hope it's looked at soon. It's a case of cart before the horse if it's not.

I investigated this issue on v7.0.0 and it seems TinyMCE adds "/umbraco/" to the path of internal links. So, my internal link looks like:

/umbraco/{localLink:1079}

@helper parseText(string text) {
    var tags = Regex.Matches(text, @"href=""/umbraco[/]?(?:\{|\%7B)localLink:([0-9]+)(?:\}|\%7D)", RegexOptions.IgnoreCase | RegexOptions.IgnorePatternWhitespace);
    foreach (Match tag in tags) {
        if (tag.Groups.Count > 0)
        {
            var id = tag.Groups[1].Value;
            var newLink = Library.NodeById(int.Parse(id)).Url;
            text = text.Replace(tag.Value, "href=\"" + newLink);
        }
    }
 @Html.Raw(text)
}

Now, when you want to output RTE content use the helper like:

@parseText(item.GetPropertyValue("RTEcontent"))

I'm sure you could do this better and move it to APP_Code and make site-wide, but I needed a simple solution without leaving the back office.

EDIT: correction for 7.0.1! Part fo this problem is fixed in v7.0.1 (http://issues.umbraco.org/issue/U4-3799)  but i failed to notice it because you have to manually recreate all internal links in RTE and publish for this bugfix to have an effect! v7.0.0 prefixed internal liks with 'umbraco' and v7.0.1 doesn't but you have to remove those old prefixes.

So, in v7.0.1, for me old workarround from this thread works. You just have to render content like this:

http://issues.umbraco.org/issue/U4-3799

@Html.Raw(Umbraco.Web.Templates.TemplateUtilities.ParseInternalLinks(item.RTEcontent.ToString()))

For whatever reason, I am still getting the prefixed links after upgrading to v7.0.1

psiho's did the trick for me. Thanks mate

Have you tried to manually recreate links in RTE and publish the page(s) again? That's what I forgot to do in v7.0.1. Either way, there might be problems if half of your links are prefixed and half not. Maybe I should update Regexp in my solution to match *optional* "umbraco/" prefix. Something like (untested!!!!):

@"href=""/(umbraco/)?(?:\{|\%7B)localLink:([0-9]+)(?:\}|\%7D)"

Yeah, I tried to recreate the links with no luck. So I'm sticking with Your earlier solution - atleast untill the issues are fixed in a later Umbraco version. It is a small site atm. so recreating the links later on will be no problem.

We came across this bug in a 6.1.6 version. Seems to happen if you do something like:

@Html.Raw(@page.GetPropertyValue("bodyText"))

However, we solved it by using Umbraco.Field:

@Umbraco.Field("bodyText")

Hope that helps someone!

Kenny

You should be able to get it working like this as well

@page.Content.GetPropertyValue("bodyText")

Here are some documentation

//fuji

You should be able to use the following Umbraco library / helper:

Lib: Umbraco.Web.Templates

Helper: TemplateUtilities.ParseInternalLinks(stringContainingInternalLinks);

Razor Application - 

@using Umbraco.Web.Templates

...

@Html.Raw(TemplateUtilities.ParseInternalLinks(stringContainingInternalLinks));

I am seeing this some of the time with an install of Umbraco 7.2.2. For example, this is how some of the links in my rich text are getting rendered:

<p>This is a <a href="/{localLink:1050}" title="Homepage">test</a>.</p>

Also, this workaround did not work for me:

@Html.Raw(Umbraco.Web.Templates.TemplateUtilities.ParseInternalLinks(text))

Any ideas?

Correction, ParseInternalLinks does work (though, I'm still having the main issue).

By the way, the Umbraco forum converted my locallink into a hash sign. Also, I submitted a YouTrack ticket for my issue: http://issues.umbraco.org/issue/U4-6447

is working on a reply...