Kicking this up. Can't believe I'm the only one running into this issue. Does anyone get this working with Umbraco Forms? Using Contour this was no problem at all and I can't believe the dev team missed this.
What I did notice is that lots of calls from the CacheService end in obsolete methods.
I've been digging into this today and finally found the cause. UmbracoForms at some moment in time loads all the member properties into the HttpRuntimeCache with the key umbrtmche-ContourMemberValues(memberId).
In our scenario, we have a couple of customer member properties with editors that only display data. E.g. when, in the Umbraco Member section a member is viewed the a list of recent logins is displayed. Obviously, this editor does not persist any data. Another example is a button that is added as property editor to member that can be used to directly send the user his login credentials.
It appears that UmbracoForms cannot handle these custom property editors. After removing these type of editors, all works as intended. After re-adding one of these property editors, bang.
I digged into the cache, found the below exception for the mentioned key:
However, no solution found. Can the Umbraco Forms cachemechanism be instructed to only cache properties that are relevant?
For anyone running into this, I managed to solve the issue, with what I would call a "palliative". Or workaround.
The issue is that we're using a bunch of custom property editors for a member that do not store a value, but rather act as a viewport to some custom datatables. The moment the-artist-formerly-known-as-contour reads a member's properties and stores them in the cache dictionary, these null values (which they are), are not accounted for. When retrieving the dictionary, this leads to the error message shown above.
The palliative here is simple but effective. In the OnMemberSaving event of the MemberService, for any property that uses this kind of propertyeditor, a non-null value is set.
private void OnMemberSaving(IMemberService sender, SaveEventArgs<IMember> e)
{
foreach (var member in e.SavedEntities)
{
foreach (var p in member.PropertyTypes.Where(p => p.PropertyEditorAlias.StartsWith("Ults.")))
{
//NOTE: simply setting the value to an emtpy string is not enough, the value has to be "something"
if (member.GetValue(p.Alias) == null)
member.SetValue(p.Alias, p.PropertyEditorAlias);
}
}
}
Where do I add the workaround? Also, can the workaround be avoided if you have more complete members data? Again, not sure I understand what the issue is.
The issue is there when you have members with properties that can (potentially) be null. If this is the case, the caching mechanism that UmbracoForms uses to store and retrieve the member properties fails with a NullReferenceException.
Using the workaround above, properties with null-values are assigned a value before a member is saved, so that these properties can be stored and retrieved succesfully from the cache.
The complete code below:
public class MemberEventHandler : ApplicationEventHandler
{
protected override void ApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)
{
base.ApplicationStarted(umbracoApplication, applicationContext);
//NOTE: The runtime cache that umbraco keeps for members does not support NULL values
// The workaround for this is for any property that has a NULL value, the property is assigned a default value
MemberService.Saving += OnMemberSaving;
}
private void OnMemberSaving(IMemberService sender, SaveEventArgs<IMember> e)
{
foreach (var member in e.SavedEntities)
{
foreach (var p in member.PropertyTypes.Where(p => p.PropertyEditorAlias.StartsWith("Ults.")))
{
//NOTE: simply setting the value to an emtpy string is not enough, the value has to be "something"
if (member.GetValue(p.Alias) == null)
member.SetValue(p.Alias, p.PropertyEditorAlias);
}
}
}
}
Hey Matthew, can you confirm this occurs with the latest Umbraco Forms edition? I know that there has been an update released that should have solved this.
NullReferenceException on Umbraco Forms with DefaultValue for logged in member
I'm running Umbraco 7.2.8 with Umbraco Forms 4.1.4 and receive a NullReferenceException when I use DefaultValue in a form for a logged-in member.
Steps to reproduce:
Am I the only one running into this issue?
Kicking this up. Can't believe I'm the only one running into this issue. Does anyone get this working with Umbraco Forms? Using Contour this was no problem at all and I can't believe the dev team missed this.
What I did notice is that lots of calls from the CacheService end in obsolete methods.
I've been digging into this today and finally found the cause. UmbracoForms at some moment in time loads all the member properties into the HttpRuntimeCache with the key umbrtmche-ContourMemberValues(memberId). In our scenario, we have a couple of customer member properties with editors that only display data. E.g. when, in the Umbraco Member section a member is viewed the a list of recent logins is displayed. Obviously, this editor does not persist any data. Another example is a button that is added as property editor to member that can be used to directly send the user his login credentials. It appears that UmbracoForms cannot handle these custom property editors. After removing these type of editors, all works as intended. After re-adding one of these property editors, bang.
I digged into the cache, found the below exception for the mentioned key:
However, no solution found. Can the Umbraco Forms cachemechanism be instructed to only cache properties that are relevant?
For anyone running into this, I managed to solve the issue, with what I would call a "palliative". Or workaround.
The issue is that we're using a bunch of custom property editors for a member that do not store a value, but rather act as a viewport to some custom datatables. The moment the-artist-formerly-known-as-contour reads a member's properties and stores them in the cache dictionary, these null values (which they are), are not accounted for. When retrieving the dictionary, this leads to the error message shown above.
The palliative here is simple but effective. In the OnMemberSaving event of the MemberService, for any property that uses this kind of propertyeditor, a non-null value is set.
Not sure I understand.
Where do I add the workaround? Also, can the workaround be avoided if you have more complete members data? Again, not sure I understand what the issue is.
The issue is there when you have members with properties that can (potentially) be null. If this is the case, the caching mechanism that UmbracoForms uses to store and retrieve the member properties fails with a NullReferenceException.
Using the workaround above, properties with null-values are assigned a value before a member is saved, so that these properties can be stored and retrieved succesfully from the cache.
The complete code below:
Thanks for help.
Where do I put this code?
Intresting find. Hopefully this will be fixed in a coming release.
Question though. What does the "Ults." mean in your code snippet? Is it a namespace you use in your custom member properties?
Yup, hopefully it will. It's been bugging me a couple of months already...
"Ults." is indeed the namespace that the propertyeditor starts with, in our case.
I noticed this happening even without default values if a member is simply signed in and submits a form.
Hey Matthew, can you confirm this occurs with the latest Umbraco Forms edition? I know that there has been an update released that should have solved this.
I'm using 4.3.2 (latest) with the new UI.
I've also just checked the Changelog for versions 4.3.0+, and didn't see anything referencing this issue. Was this ever posted on the issue tracker?
Hi Metthew,
Yes try to see this issue from the tracker http://issues.umbraco.org/issue/CON-841
It has been fixed in next release of Umbraco Forms 4.3.3, which we are working hard to get out very soon.
If you canĀ“t wait for the release, then you can always run the latest nightly build from here http://nightlies.s1.umbraco.io/?container=umbraco-forms-nightlies
/Dennis
is working on a reply...