V8: Magic strings doesn't display value

[Frost117]

If you want to display the [#CurrentPage] for when the forms are being used, then you won't be able to do it in version 8.

In the documentation we have the following:
https://our.umbraco.com/documentation/Add-ons/UmbracoForms/Developer/Magic-Strings/#umbraco-page-field-item

But if you want to use this in a forms you will be left with nothing rendered in the view.

This is what it looks like in version 8:

Which should render out the name "Root Node".

And as you can see it fails to do so.

You are able to do it version 7.

The exact same setup, with 2 different results.

Reproduction

Steps to reproduce

1. make form in v8.

2. In the label put in [#pageName] like so:
   

3. Make a doctype, with a template, that has a form picker.

4. Make a content node using the doctype that you have just made.
   If the form doesn't get displayed in the front-end you will need to update the template so it renders out the picked form.

5. If you visit the front-end of the site you should see that the [#pageName] does not render out what you called the content node.

Specifics

The problem occurs on the root node.

Umbraco 8.0.1
Forms 8.1.1
Deploy 3.0.2

Problem exist in Firefox, Chrome and Edge

Expected result

That the form label displays the current node it is being viewed on.

Actual result

Nothing gets displayed.

---

This item has been added to our backlog AB#2334

[facingdigital]

I have the same problem to use the magic string in the workflow step...
I have a form field with an alias and a caption "topic"

I put the value {topic} in the workflow field "receiver email" but this value is empty....

Please, it's very urgent to fix this big issue!

Thank you for your comprehension.

User from Umbraco Cloud

[shaishavkarnani]

Did this issue get fixed? I can see same issue in Umbraco version 8.1.1 and Umbraco Form version 8.1.1

[rgdagostino]

Same issue here on Umbraco 8.1.2 and Forms 8.1.1

[seekingcode18]

I'm having the same issue.
Umbraco 8.1.2
Forms 8.1.1
Deploy 3.1.1

[callumbwhyte]

Also having this issue!

Umbraco 8.1.2
Forms 8.1.1

Given this seems to be affecting a few people I hope we can get a resolution soon 🙏

[nul800sebastiaan]

Looks like in v7 we were relying on some things we insterted into HttpContext.Items from withing Umbraco, items like pageName and pageID used to be available there, this is no longer the case in v8 making these two items fail.

Is there other magic strings than those two that are currently failing? It looks like everything else is wired up correctly. We can probably hack these back in to Forms as special cases. We'll have a look.

[callumbwhyte]

That was exactly as my investigation found too - as the "pageElements" hashtable is no longer in HTTP Context none of the data needed is there.

Previously we could do [#myPropertyAlias] to get any value from the current content item, or [$myPropertyAlias] to get a value recursively. This logic relied on the pageID from that "pageElements" collection, which no longer works (as above)...

The big question here is how do we deal with variant properties? This applies to both custom properties, and the page name... My (selfish) preference would be to get the value for the "default" language and ignore other variants for now as I think this handling this properly is a much bigger discussion!

[clausjensen]

@callumbwhyte I'd say it would make sense to do what we also do if you fetch a property without specifying a variant in a normal template. We would pick the variant data that fits with the current context being rendered.

The reason being that if you use #pageName (without specifying a culture) in your form rendering - you'd get 'Page Name' displayed. You render the same field out in your template - you get 'Page Name'.
If you then switch to a context of Danish .. you would have 'Side Navn' rendered in the template due to the culture being changed - but just using default language for Forms would then cause 'Page Name' to be rendered in the form rendering.

I don't think we (at the moment) should support fetching fields from different (other than the current) cultures for these magic strings. Not sure if anyone would ever need that so until then let's not try to do that.

[callumbwhyte]

Hey FRIENDLY® Forms team 😊

Just wondering if there was any progress on getting this fixed? Or anything we can do as the community to help you out...?

Understand there's quite a few bugs to triage / fix with Forms, and there's other priorities, but it's disappointing to see "minor" fixes for more recent issues than this one being fixed and silence here when this is affecting quite a few people... ❤

[Robiwahn23]

Yeah, any reaction from the forms team would be nice!

[NikRimington]

Hey all,

I've got the same issue with place holders relating to the same node. However you can hack it around a little bit and use this inside what ever calls your form render, be it a macro or a partial to put the basics in there:

var hashTable = new System.Collections.Hashtable{ {"pageName", Umbraco.AssignedContentItem.Name}, {"pageID", Umbraco.AssignedContentItem.Id}, {"pageKey", Umbraco.AssignedContentItem.Key} };
    if(Context.Items.Contains("pageElements") == false)
    {
        Context.Items.Add("pageElements", hashTable);
    }

Although I've not done it here, if you also add a property with the key "splitpath" that is a string[] of the path value split on , then you'll also be able to use the $ place holders for properties on the document type. I think that it will the current culture if using variants, although I've not tested this to be honest.

[NikRimington]

Since my comment yesterday I've tested adding in splitpath and that seems to work as well, giving access to the content item.

[callumbwhyte]

I ended up doing the same as @NikRimington, but certainly not an ideal solution as editors can place forms in many places on the site... A "proper" solution would be great 😊

Wondering if there's a nice-ish way of running this code on every request? Was thinking I could do this by overriding something in UmbracoApplication but couldn't see anywhere suitable...