Petra Liljecrantz
Mar 22, 2016
  7073
(4 votes)

Differences between scheduled publish and normal publish

This is the third post on issues I encountered working for Episerver Managed Services and this time it´s about scheduled publish. One question that we got fairly frequent was about the scheduled publish job. Partners had issues of different kind (pages not publishing, cache not working etc.) and it was escalated to us. I find that there isn´t a whole lot documented about scheduled publishing so these are some stuff I learnt directly from the developer team. It covers some differences between a scheduled publish and a normal publish done manually by an editor which publishes the page directly.

  • The normal publish uses the users context while the scheduled publish runs without the users context and thus it skips the access check. This could in theory mean that a page can be scheduled for publish by a user that isn´t supposed to be able to publish.
  • The normal publish has access to the HttpContext and the scheduled publish hasn´t, so if a page that´s target for a scheduled publish relies on the HttpContext it will probably have some issues and the publish will most likely fail.
  • The normal publish fires off the publish event which will invalidate the built-in cache so that all load balanced servers will go to the database to fetch the new content, the scheduled publish however does not fire off that event so other load balanced servers will not get the new content until the pageCacheSlidingExpiration has passed (which is by default 12 hours). This setting can be changed in web.config by adding pageCacheSlidingExpiration anywhere in the applicationSettings tag within the episerver tag, like this:
<episerver>
    <applicationSettings httpCacheability="Public" pageCacheSlidingExpiration="7.00:00:00"...
Mar 22, 2016

Comments

Santosh Achanta
Santosh Achanta Mar 23, 2016 04:34 AM

Great, thanks for sharing.

Vincent
Vincent Mar 25, 2016 02:44 AM

Nice article. I didn't realize schedule publishing not fire off event. Do you have any solution make it happen automatically?

Petra Liljecrantz
Petra Liljecrantz Mar 25, 2016 12:52 PM

Thanks!

I haven´t actually tried to force the publish event when using scheduled publish but I doubt that there is a way. I might be wrong though.

Tomasz Madeyski
Tomasz Madeyski Aug 9, 2018 02:03 PM

I found this blog post when I had issues with output cache being not cleared after scheduled publish. I was really surprised that lifecycle events are not fired so I did debug and well... those are fired up. DelayedPublishedJob runs `PublishOnBehalfOf` method which calls regular ContentRepository's Publish method which calls all lifecycle events (i.e RaisePostEvents which then fires PublishedEvent). My issue was (and maybe so was yours) that one of my custom event handlers was throwing an exception. Look at `PublishOnBehalfOf` method (Episerver.Util.DelayedPublishJob):

private void PublishOnBehalfOf(ContentReference contentLink, string user)
{
IPrincipal currentPrincipal = Thread.CurrentPrincipal;
try
{
Thread.CurrentPrincipal = (IPrincipal) new GenericPrincipal((IIdentity) new GenericIdentity(user), (string[]) null);
this._contentRepository.Publish(contentLink, AccessLevel.NoAccess);
}
finally
{
Thread.CurrentPrincipal = currentPrincipal;
}
}


so what happens here is Publish throwing (well, my custom event handler is) and exception. It stops executing other event handlers and it gracefully jumps to finally block with no trace of exception being thrown. (status of Publish Delayed Content Versions is just "Nothing was published." - no error). 

So once I fixed my custom event handler I got all lifecycle events fired up and one of them was probably one responsible for clearing output cache. 

Bottom line is: if status of job is "Nothing was published" when actually it was published than you probably have some issues with you event handlers.

Note: I'm working on EpiServer 10.10.4, I didn't check newer versions

Please login to comment.
Latest blogs
Optimizely CMS 13 and the Alloy demo site

The Alloy demo site now runs on Optimizely CMS 13. Here’s a quick guide to getting it up and running locally.

Tomas Hensrud Gulla | Apr 10, 2026 |

A day in the life of an Optimizely OMVP: Getting Up to Speed with Optimizely CMS 13 — A Free Learning Path

If you're working with Optimizely and haven't started exploring CMS 13 yet, now's the time. I've put together a dedicated CMS 13 course within the...

Graham Carr | Apr 10, 2026

A day in the life of an Optimizely OMVP: Optimizely CMS 13 Is Here: The Features, The Add-Ons, and What's Coming Next

CMS 13 went GA on 31st March 2026, and after months of previews, webinars, and internal engineering sessions, it's finally real. I've been deep in...

Graham Carr | Apr 10, 2026

How to get the Page Tree back in Optimizely CMS

Lost the page tree in Optimizely CMS? Here's why it happens and the non-obvious fix to get it back.

Henning Sjørbotten | Apr 10, 2026 |

Optimizely CMS 13 and the first bug fixes

The first bug fixes for Optimizely CMS 13 is here!

Tomas Hensrud Gulla | Apr 9, 2026 |

lunchin Optimizely Cloud Extensions now supports CMS 13

lunchin.Optimizely.Cloud.Extensions version 2.0 has been released today which adds support for Optimizely CMS 13.

Mark Hall | Apr 9, 2026 |