Publishing in Sitecore is a very powerful process. Differently to just flagging content in the database to mark it as published, the content is physically moved across physical databases. This ceremony can however be of different flavors, based on the combination of workflows, publishing restrictions and user roles.
When is an item ready to be published?
Before Sitecore can publish some content, a series of checks is performed. These have to be passed, so that the publication can take place. Sitecore controls that:
- the item is in the “Final Workflow State” – that means if there is a workflow attached to the item, all the steps of that workflow must be went through up to the so called “Final Workflow Step”. Only then, a publication can take place. If workflows are switched off in configuration or they are not assigned on the given item template, these items are not considered to be under workflow and therefore always understood as to be in the “final workflow state”.
- the item fulfills publishing restrictions – it is possible to set publishing restrictions on every item and every of its version. These publishing restrictions specify whether the item is publishable or not and from when to when. Thanks to this restriction, it is possible to precisely shape the lifetime of an item or its version. If we take for instance an item to manage weekly promotions and we prepare upfront the content for a month, we can create 4 versions of that item, where every version holds a promotion for one week. Then we set the publishing restrictions, so that every week only one of the versions is visible.
By this we make sure that content that has not to be published will never be published. It is possible to see the overall publishing restriction setup in a calendar and see the (un)publishability of the single versions.
What is published?
It is always the last version of an item that went throughout the entire workflow that gets published. Let’s say that we have two versions of an item – 1 and 2. Version 1 went through the entire workflow and ended up in the final workflow state. It is therefore ready for publishing. On the other hand, version 2 is still in preparation and is not ready for publishing. It did not go through the entire workflow and therefore did not reach the final workflow state. When the item is published, version 1 is published, even if there is a version with a higher number. That is because version 1 fulfills all parameters for publising, while version 2 does not. Sitecore informs the user about this with a notfication that shows while editing content:
Who publishes content?
In Sitecore, publication can be approached in several ways – it is possible to publish manually, semi-automatically or automatically. To quickly sum up the options:
- Manual – in this scenario all or selected editors can publish with a click of a button and choosing the type of publication (Smart Publish, Site republish, Incremental Publish – there are more details available about website publishing and items publishing on the Sitecore Documentation website)
- Automatic – Sitecore takes care of publishing mainly through scheduled tasks using pre-set intervals
- Semi-automatic – the content is being automatically published at the end of a workflow.
In the cases, where there are a few editors taking care about the content and it is not necessary to publish big amounts of items, publishing is usually granted to the editors. Additionally, scheduled tasks are in place to make automated nightly publishes.
On the other hand, when Sitecore powers multiple websites with tens or hundreds of thousands of items that are edited by many editors, the best thing is to let the system handle all the publishing agenda. By this, it is possible to have total control over the publishing process and human errors could be avoided.
Workflows in Sitecore plays an important role in two cases: in the first case, it is a mean of better control over published content – a typical example is the approval proces prior to publishing. In the second case, it allows to prepare a series of steps that are dependent on each other and can trigger some actions – a typical example is the deployment of goals or starting A/B tests. In Sitecore 8, newly, there are also activities related to social – e.g. account renewal.
In the solutions that build on Sitecore, where bigger teams with of usually steeper hierarchies take on content management, workflows quite often have multiple steps. A typical example can be the situation, when an item is worked on by the editor – in that case it can be in the “Draft” state. When the editor is done with editing the item, he can send the given content for approval – in that case the workflow state can be “Awaiting approval”. The approving role has then the option to edit, approve or reject the content and send it back to the author. If he approves the content, the content gets to the state “Approved”. Exactly this workflow is already pre-set in every Sitecore installation as a reference one and it also usually covers the majority of requirements for an approval workflow.
Since there is no other step in such workflow, we can mark the “Approved” step as the “Final Workflow Step”. Sitecore is then informed that the workflow is finalized an that the content is ready to be published.
The workflow in Sitecore can be set up with any number of steps, name of steps, actions and commands. In any case, one item can have assigned can be in a single step of one workflow at a time.
User roles determine the content that can be accessible to a certain user (in a certain role) and what actions can that user perform with it. In connection with workflow, user roles allow to specify who is in charge of what part of the content lifecycle.
In Sitecore, the roles setup indicate what items are available to the given role. Since workflows are also represented as items, it is possible to configure, what a role can do within those workflow.
Let’s get back to the previous example with the approval workflow. We can imagine two roles – one represents the editor who prepares the content and the other one represents a supervisor, who approves the content. It is then possible to achieve total control over which role can send the content to the “Approved” state and make the content ready for publishing.
It is not necessary to use roles with workflows, it is possible to use them alone. The same is valid the other way round, but the practical usage of workflows is lower, because everyone can do everything. In such case, is almost useless to have any workflow at all.