Do not publish

When it comes to publishing and Sitecore there is one main recommendation: do not let authors publish. I have seen endless evil caused by unsuspecting authors who instead of using the preview functionality, performed a continuous series of publishes to correct any mistakes in the page. Multiply that by a few authors and the stream of continuous publish operations goes on throughout the day.

the dangers of publishing

Why is publishing dangerous? Remember that publishing is potentially an expensive operation, and it can affect the performance of your site as some cache entries will get removed. In particular, the entire HTML cache is flushed. If your site is very dependent on it, then, performance will certainly get affected.

This might seem counter-intuitive at first, but the best you can do is stop authors from publishing and instead give the control of publishing to somebody you trust. Who? The machine itself.

The main recommendation is therefore to rely on scheduled publishing. Even if it happens quite frequently at least you are in control, you know when and how often it will happen and you can prepare for it by making sure your performance does not suffer when the HTML cache is flushed with that frequency.

scheduled publishing

Scheduled publishing comes in two main flavours: at regular intervals or at a particular time.

Setting up Sitecore to publish every X minutes/hours is very easy. Simply change the frequency value of an entry in the web.config. Remember to do so with an include file, you can use the following as an example:

<?xml version="1.0"?>
<configuration xmlns:patch="" xmlns:set="">
      <agent type="Sitecore.Tasks.PublishAgent" set:interval="06:00:00"/>

If you want Sitecore to publish at a particular time, maybe coinciding with low-traffic volumes, you could use Sitecore's scheduled tasks defined in the master database. The configuration is slightly fiddly, as you have to create both a task item and a schedule item. Also, the syntax for defining the actual time when the action should execute is slightly over-complicated. And you are still relying on the scheduling agent picking up the task, so there is no guarantee it will execute at a precise time. Of course you could change the frequency the scheduler looks for tasks, and in fact recent versions of Sitecore have that set up at a very frequent interval: 5 seconds!

    <!-- Time between checking for scheduled tasks waiting to execute -->

In my opinion, relying on Windows scheduled tasks is a much better solution. This will then invoke either a service or a custom web page with the code to perform the publish. Obviously you ought to make sure this page or service is not accessible from the outside world. If you want to see an example of how easy it is to set up just check my post on Scheduled Publishing

stop authors from publishing

But what if you need authors to control exactly when something appears on the site. Typically, that is a requirement for only certain type of pages: press releases, campaigns, etc. It would make sense to give authors the power to publish those items, and those items only. However, there is no publishing security permission in Sitecore. Authors can either publish or not publish. You can't allow them to publish only certain items .

Usually, your authors' ability to publish is controlled through membership to the Sitecore Client Publishing role. If you do not want them to be able to publish, simply ensure they do not belong to that role.

workflow publish

You can give authors some control over the publishing of certain items by using workflow. Publishing can happen as a side-effect of workflow, which is linked to a particular type of items through their Standard Values.

The default workflow that comes pre-configured with Sitecore is already capable of publishing. This is done through the publish action (see item /sitecore/system/Workflows/Sample Workflow/Approved/Auto Publish).

If you don't want to have approval as part of the workflow, simply delete the awaiting aproval state, rename the submit action to Publish and make it point to the Approved state. You still get the benefit of allowing authors to publish, and as a bonus, automatic versioning.

modified workflow with two states

I would also recommend you use the Workflow State Execute access right to make sure only certain people are able to actually publish the item. In this way you are controlling which items need to be published (by associating the workflow to them) and which users can publish (by granting them Workflow Command Execute to the command that transfers the item to the Approved state).

This does not end here though, as there are further challenges along the way.

related items

So let's imagine the item that needs to be published as part of this workflow is a press release that has some text and images. With the default configuration those images will not get published at the same time as the press release. They will potentially get published in an incremental/smart site[1] publish. But if there has been no site publish, by default, the workflow publish action will not publish them.

Fortunately you can alter this behaviour by modifying the publish action: simply add the related=1 parameter.

auto publish action with related parameter

I would imagine this is the preferred situation in most cases, so I would recommend always adding this parameter.


To sum it up, these are my recommendations:

  • Make sure your authors are not members of the Sitecore Client Publish role
  • Configure a site publish either through the publish agent (frequency) or scheduled tasks (time+frequency)
  • Assign a publish-capable workflow to those items that need immediate publication
  • Grant Workflow Command Execute access right to the command that triggers the publish to the few users that should do the publishing
  • Set related=1 in the publish action


There is another cool use of publishing in workflow where you can have a non-logged in preview functionality. A story for another day...

  1. Don't be fooled, it's called site publish but in reality it is a database publish operation. ↩︎