Umbraco (4.11) Issue On Save/Publish: UltimatePicker Object reference

Question

Have a site already in production that up until yesterday I was able to add a particular piece of content that uses a variety of data types that use ultimate picker set to a specific parent nodeid which also filters by a document alias.

Right now when saving/publishing any of those content items, I'm getting this exception: [NullReferenceException: Object reference not set to an instance of an object.] umbraco.editorControls.ultimatepicker.ultimatePickerDataEditor.Save()

Anyways, only thing I can thing of is the day before the recycling bin on the site was cleared.

If that's the case, is there a way to clean up the references that some of these content items are using? Or is there some other way to solve this?

Full exception:

2013-12-06 18:19:45,992 [6] ERROR Umbraco.Web.UmbracoApplication - [Thread 7] An unhandled exception occurred System.Web.HttpUnhandledException (0x80004005): Exception of type 'System.Web.HttpUnhandledException' was thrown. ---> System.NullReferenceException: Object reference not set to an instance of an object. at umbraco.editorControls.ultimatepicker.ultimatePickerDataEditor.Save() at umbraco.controls.ContentControl.SaveClick(Object sender, ImageClickEventArgs e) at umbraco.controls.ContentControl.SavePublish(Object sender, ImageClickEventArgs e) at System.Web.UI.WebControls.ImageButton.OnClick(ImageClickEventArgs e)
at System.Web.UI.WebControls.ImageButton.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.HandleError(Exception e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at System.Web.UI.Page.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Answer 1

OK, here's the odd, crazy rundown of what happened:

• Somewhere, somehow along the development chain someone installed a Starter Kit on Umbraco. When the site was first created, it didn't have a Starter Kit. So it had to be on one of our testing environments
• This didn't happen on production as the Install folder was removed.
• So, there was the Homepage, Textpage, and Product types lingering and one was added to one of our document types
• Since there was sample data on testing, staging for that document type, it didn't get a null reference exception on publish, however on publish on production it DID get a null reference exception

I found this by pulling down the Umbraco 4.11 tag on GitHub, adding it to my project, and then debugging on Save/Publish. I found there was an errant property trying to save with no data. This is actually because of the recycling bin being cleared, oddly enough. There wasn't data, so it threw a null reference when trying to iterate through the items.

The moral of the story? Lock down any Starter Kits from being added once you started custom development. Also, don't clear the recycling bin unless you know for sure it won't impact your site, i.e. this shouldn't have been done on production initially.

The recycling bin is great, it's just that there WAS a property relying on data that no longer was present,

Answer 2

Cleaning the recycle bin shouldn't affect it, unless your data type was relying (getting node information) on it? (Doesn't make sense, but...)

Anyways I would check the umbraco log files, the database log table and see what's the output.

Did you change some document types? Check also the code that's relying on them, might be a simple issue that you can spot right on.

For the time being, can you re-create a new data type that uses that ultimate picker and add it again to a test document type and see if it saving/publishing works? Fixing this issue in production, might be similar to change a a flat tire of car while moving on the road. I would recomend you to it in a DEV or STAGING environment.

Can you provide us more detail on the exception?

Good luck!