Anatomy of page lifecycles in SharePoint 2010 publishing pages
As most of you already know, SharePoint 2010 brings a whole load of nice publishing features out of the box. One of these are the handling of publishing pages. Publishing pages are basically .aspx pages that get their content from the listitem associated to them. You can imagine a publishing page much like any other document you would put in a document library. Specialty of these pages is that it stores most of its contents in its properties. If you go ahead and check any publishing page in the Pages document library you will find columns like Page Content, Title, Page Image. These are inserted into the “slots” of the page layout associated with the content type of the publishing page. These slots (content placeholders) are defined in page layouts by using field controls.
Going back to our original topic, these publishing pages behave pretty similar to documents in terms of lifecycle management. Every document has the following aspects of lifecycle properties:
- version (major and minor)
- check-out state: checked-out (long-term or short-term), checked-in
- approval state: draft, pending, rejected, approved, scheduled
Let’s take versions for first. When enabling major and minor versioning (default on the Pages document library on publishing sites) every document starts with version 0.1. Minor versions (0.1, 0.2, 1.1, 1.2, etc.) can only be seen by users with editor rights on the page. Major versions can be seen by read-only users as well. This provides with a nice way of preparing content for general consumption while not showing anything to unauthorized users.
A typical workflow would be:
0.1 --- save ---> 0.2 --- save ---> 0.3 … any number of minor versions …. --- publish ---> 1.0
When reaching a major version the page content will be visible to users with just read permissions. This version of the page will remain visible until an other major version is published. The tricky thing is that if you go ahead and edit version 1.0 and save (check-in) SharePoint will create a version 1.1 while still showing version 1.0 to read-only users. This way you can continue preparing your version 2.0 and only show it to users when you feel like it’s ready.
Check-in and check-out provides a simple way of letting other editors know that you are working on a specific page. While a page is checked out to you, no other editor will be able to edit the page. Users with editor rights can Undo checkout which means that changes to a page (content and also changes in webparts) will be undone and checked-in state will be restored.
Approval state complicates the picture by introducing a new attribute to versions. Content approval can be enabled without using versions as well, in this case it functions as a yes-no switch on the visibility of the page to read-only users. Things get more complicated when using major and minor versions. A usual version flow would be as follows:
0.1 draft --- save ---> 0.2 draft --- save ---> 0.3 draft … any number of draft minor versions … --- publish ---> 1.0 pending --- approve ---> 1.0 approved
Content approval is started as soon as you publish a major version. After the page is approved, read-only users will start to see the modifications made since the last approved major version.
Content approval scheduling (or simply scheduling) adds a way to postpone the approval process to a specific time. During this time the status of the page will be 1.0 scheduled to show that it will be visible to read-only users at a later time. Scheduling works by employing a scheduled job that runs every minute and checks if the Publishing start date (or Publishing end date) has been reached. If yes, the job sets approval on the page accordingly.