Publish At throws Null Reference Within uDateFoldersy
Anthony as requested.
2013-09-25 14:12:04,932 [18] INFO Umbraco.Core.Publishing.PublishingStrategy - [Thread 16] Content 'The Editorial Board Blog' with Id '4443' has been published.
2013-09-25 14:12:04,995 [18] ERROR umbraco.presentation.publishingService - [Thread 16] Error publishing node 4443
System.NullReferenceException: Object reference not set to an instance of an object.
at uDateFoldersy.UmbracoEvents.UmbracoNodeEventsForDateFolders.Flagged(String cachePrefix, String suffix)
at uDateFoldersy.UmbracoEvents.UmbracoNodeEventsForDateFolders.ContentService_Saved(IContentService sender, SaveEventArgs`1 e)
at Umbraco.Core.Events.TypedEventHandler`2.Invoke(TSender sender, TEventArgs e)
at Umbraco.Core.Services.ContentService.SaveAndPublishDo(IContent content, Int32 userId, Boolean raiseEvents)
at umbraco.cms.businesslogic.web.Document.SaveAndPublishWithResult(User u)
at umbraco.cms.businesslogic.web.Document.SaveAndPublish(User u)
at umbraco.presentation.publishingService.CheckPublishing(Object sender)
I think I may have fixed it, I pulled your code from bitbucket, added some logging.
From some other searches on HttpContext.Current.Items being null, One suggestion was to inherit IRequiresSessionState.
Rebuilding and copying over seemed to fix the exception and the article appears to be publishing correctly...
Changing HttpContext.Current.Items to use HttpRuntime.Cache has fixed this problem when uDatesFoldersy is invoked by the Timer. So article will now get published when using Publish At and Remove At.
Current.Items is request specific. Using cache means that the value stays around for a period of time. If you use it then you must dump the cache manually. I don't really think its a good idea to use.
The value I'm storying is just for the request. I have no idea why it's crashing now though.
I clipped the stack trace above here's the full trace showing the mscorlib.dll!System.Threading.TimerQueueTimer.Fire()
not sure where in Umbraco the timer get set up though.....
I've now added a return from ContentService_Saved if the HttpContext.Current is null. This appears to work for both Publish At and Remove At.
void ContentService_Saved(IContentService sender, Umbraco.Core.Events.SaveEventArgs<IContent> e)
{
if (!ConfigReader.Instance.UseAutoDateFolders()) { return; }
// If this event isn't invoked from a Request then HttpContext.Current will be null.
// Which MAY indicate that the event was fired by a timer to handler the
// Publish At/Remove At functionality. It would be better if the event object
// provided some context to state this.
if (HttpContext.Current == null) { return; }
...etc...
Publish At throws Null Reference Within uDateFoldersy
Anthony as requested.
I think I may have fixed it, I pulled your code from bitbucket, added some logging. From some other searches on HttpContext.Current.Items being null, One suggestion was to inherit IRequiresSessionState.
Rebuilding and copying over seemed to fix the exception and the article appears to be publishing correctly...
Darn doesn't seem to be working.... :-(
Changing HttpContext.Current.Items to use HttpRuntime.Cache has fixed this problem when uDatesFoldersy is invoked by the Timer. So article will now get published when using Publish At and Remove At.
That will probably cause some issues.
Current.Items is request specific. Using cache means that the value stays around for a period of time. If you use it then you must dump the cache manually. I don't really think its a good idea to use.
The value I'm storying is just for the request. I have no idea why it's crashing now though.
I clipped the stack trace above here's the full trace showing the mscorlib.dll!System.Threading.TimerQueueTimer.Fire() not sure where in Umbraco the timer get set up though.....
Thanks.
I'll need to spend some time to investigate.
I've now added a return from ContentService_Saved if the HttpContext.Current is null. This appears to work for both Publish At and Remove At.
is working on a reply...