As long as I have worked with Sitecore the three main complaints that I have always received from content editors are that the experience editor is slow, publishing is slow and that the publishing restrictions are not working as they expect them to.
Well with the new publishing service, they no longer complain about the publishing being slow. However, did you know that it also comes with another feature called content availability that can solve the misunderstanding about publishing restrictions?
Just to quickly summarize, the misunderstanding about publishing restrictions is that most editors expect that the content will be available on the website within a specific date range when they set a publish start and end date. But in reality, as all us Sitecore savvy people know, the restrictions only specify when the version or item can be published.
This is all very logical and all, but no matter how logically correct the publishing restrictions are they still offer content editors a poor user experience that they are not used to from other systems and in their book it is just plainly broken and should be fixed. Now, with the content availability feature you can.
So how does content availability work? Well at its core, it simply allows you to have multiple versions of an item in the web database instead of only the version that was publishable at the time of publishing and then at the time of the request, it is determined which version to show.
This is actually using an old feature in Sitecore called live mode where the website draws its data directly from the master instead of the web database. However live mode is always a bit precarious to use as an item can have many versions in the master database and it takes resources to iterate over each of them to find the right version to display since they can have both publishing restrictions or be in a workflow step that does not allow them to be published.
This is where the ingenuity of the content availability feature comes to shine. Instead of having to sift through all the item versions in the master database, the publishing service only moves the versions to the web database that could potentially be valid in the future. Therefore, versions that are not in a final workflow state, has past publishing restrictions or are marked as unpublishable will not be included and you end up with a much smaller number of versions to process. Actually, in most cases only one version if you are using workflows, as all the previous versions are superseded by the newest version that is in the final state.
This is so brilliantly simple that it almost seems like cheating and setting it up requires only adding a few extra dll files and enabling a few config files as detailed by the installation guide. However, as I learned upon closer inspection of the config files it does require a bit more if you are running a multisite solution or your website is not called website.
The config file, Sitecore.Publishing.Service.ContentAvailability.config contains the following section
<sites>
<site name="website">
<patch:attribute name="filterItems">true</patch:attribute>
<patch:attribute name="enableWorkflow">true</patch:attribute>
</site>
</sites>
It simply sets the attributes filterItems and enableWorkflow to true on the site named website. However, this should also be set on any other site definitions where you want to use content availability in a multisite solution or if your site is not called website.
As a short explanation, FilterItems means that when fetching item versions they are sent through the filterItem pipeline where it is determined if there are any restrictions preventing them from being used. This is again part of the old live mode feature. In honesty, I cannot really say why workflows have to be enabled, as it is my experience that any item versions that are not in a final workflow state will not be moved to the web database anyway. But there is probably a good explanation.
Of course after all, this is still Sitecore and just to state the obvious, for this to work the item versions with future publishing dates still have to be published ahead of time in order for them to be available in the web database. But at least now you won’t have to explain to some poor content editor why she has to stay up till midnight to do a manual publish to start their important sales campaign.
I have tested this extensively and it seems to work pretty much as expected. However, I have to say that in Sitecore there is something almost magical about loading a page and waiting 5 minutes before doing a reload and seeing new content appear – with no publishing or anything. In any other CMS I would have been disappointed if it did not work like this. But in Sitecore, it truly sends shivers down my spine.