Our customer is getting this error when creating a new umbraco form in the backoffice.
They can edit existing forms (including workflow).
One strange thing is that when they edit a form a new form is created called "null" with EmptyGuid as id (00000000-0000-0000-0000-000000000000).
Running UmbracoCMS 7.4.3 and UmbracoForms 4.3.2
Error that occures when trying to create a new form. Happens when they hit Save.
EXCEPTION DETAILS:
System.NullReferenceException: Object reference not set to an instance of an object.
STACKTRACE:
at Umbraco.Forms.Web.Editors.FormController.<>c__DisplayClassf.<SaveForm>b__8(Form x)
at System.Linq.Enumerable.SingleOrDefault[TSource](IEnumerable`1 source, Func`2 predicate)
at Umbraco.Forms.Web.Editors.FormController.SaveForm(FormDesign formData)
at lambda_method(Closure , Object , Object[] )
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.<GetExecutor>b__9(Object instance, Object[] methodParameters)
at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Web.Http.Filters.ActionFilterAttribute.<CallOnActionExecutedAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.ActionFilterAttribute.<ExecuteActionFilterAsyncCore>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()
The problem for us was that we had placed the data-folder under UmbracoForms on another drive, to secure it from deploy overwrites.
Then we had just made a virtual folder pointing at that share.
When using this approach, as we do with media and logs, UmbracoForms just stops working. It starts to create EmptyGuid-files and throwing strange errors.
This is a serious issue, for us, not saving the form-data in database, since we use automatic deploys with Octopus Deploy and need to keep user generated data out of the web root folder.
But thats another story...
I did use the same virtual folder approach here, and suspected this might be the cause, but when I reverted this situation the problem persisted. Might have forgotten to restart perhaps, or something else, have to look into that. We have the same requirements regarding automatic deployment, so I'm sorry to hear the virtual directory approach doesn't work, as it does for media. Anyway, many thanks for answering!
It appears we had both a virtual data folder and a null form in the list of forms. Going back to the physical data folder did not work, but simply naming that null form did fix it! So thanks for taking the time to answer!
You could try saving each form individually. Perhaps a workflow json file is gone missing or something. Or perhaps you could try an upgrade (if available). That might restore things gone wrong. Our case, where a form without a name is preventing creation of a new form, was also rather unexpected.
Error when creating new form
Our customer is getting this error when creating a new umbraco form in the backoffice.
They can edit existing forms (including workflow).
One strange thing is that when they edit a form a new form is created called "null" with EmptyGuid as id (00000000-0000-0000-0000-000000000000).
Running UmbracoCMS 7.4.3 and UmbracoForms 4.3.2
Error that occures when trying to create a new form. Happens when they hit Save.
Hi, we're experience the same problem. Did you solve it?
No, we still have this issue.
Hi Martin and Kenneth,
We have the exact same issue with one of our customers. Has any of you found a solution in the mean time?
Hi Roelof!
The problem for us was that we had placed the data-folder under UmbracoForms on another drive, to secure it from deploy overwrites. Then we had just made a virtual folder pointing at that share.
When using this approach, as we do with media and logs, UmbracoForms just stops working. It starts to create EmptyGuid-files and throwing strange errors.
This is a serious issue, for us, not saving the form-data in database, since we use automatic deploys with Octopus Deploy and need to keep user generated data out of the web root folder. But thats another story...
Hope this could be of any help to you.
Regards, Martin
Hi Martin!
I did use the same virtual folder approach here, and suspected this might be the cause, but when I reverted this situation the problem persisted. Might have forgotten to restart perhaps, or something else, have to look into that. We have the same requirements regarding automatic deployment, so I'm sorry to hear the virtual directory approach doesn't work, as it does for media. Anyway, many thanks for answering!
Best regards, Roelof
Hi Roelof, in my case there was a form with no name set & was null. Simply setting a name on the affected form fixed the problem.
Hi Kenneth,
It appears we had both a virtual data folder and a null form in the list of forms. Going back to the physical data folder did not work, but simply naming that null form did fix it! So thanks for taking the time to answer!
best regards, Roelof
Getting the same issue here but not using a virtual folder and no un-named forms.
Tearing my hair out with frustration!
Hi James,
You could try saving each form individually. Perhaps a workflow json file is gone missing or something. Or perhaps you could try an upgrade (if available). That might restore things gone wrong. Our case, where a form without a name is preventing creation of a new form, was also rather unexpected.
is working on a reply...