Differences between Editors and Moderators

MCMS has two built in approval roles: Editors and Moderators. This leads to the common misunderstanding that MCMS ships with two levels of approval – which is not correct! Editors and Moderators are not approving the same things.

To understand the difference we first need to have a look at the underlaying architecture of pages within MCMS.

Postings and Pages

With MCMS 2001 users could see two objects in Site Builder: A Page object holding the content and a Posting object which is actually an object defining at which place in the Channel hierarchy the content of the Page object should show up. For every Page object multiple Posting objects could exist – which allowed to show the same content in multiple places in the Channel hierarchy.

With MCMS 2002 users can only see a Posting object. The Page object is no longer exposed – but it still exists! You can see this when creating a connected Posting: here the same content is shared between all connected Posting. All these connected Postings link to the same Page object. And with different connected templates – which are again linked to the Posting object – the same content (which comes from the Page object) can be displayed with a different layout.

The Page object holds the following information:

  • The “Name” property
  • The “Description” property
  • The Custom Property Collection
  • The Placeholder Collection

The Posting object holds all the other information like

  • The associated Template object
  • The “DisplayName” property
  • The “StartDate” property
  • The “ExpiryDate” property
  • The “IsImportant” property
  • The “IsRobotFollowable” property
  • The “IsRobotIndexable” property
  • The “IsHiddenModePublished” property
  • The “Url” property

It is important to understand the fact that every visible Posting also has an underlaying Page object before we cover the side effects of this implementation.

Editors versus Moderators

As we have learned in the paragraph before: every Posting is linked to a Template object and to a Page object holding the content.

  • Editor only approve changes to the Page object – not changes to the Posting object.
  • Moderators only approve changes to the Posting object – not changes to the Page object.

So whenever either a property of the Page or a property of the Posting object a member of the relevant approval role has to approve it. So if the StartDate is changed a Moderator has to approve the change. If a placeholder content is changed then an Editor has to approve the change.

One interesting aspect is changing the Name property. The Name property is hosted in the Page object – so we would expect that this change only requires Editor approval. Unfortunatelly this is not correct. You will notice that also Moderator approval is required. The reason for this is that the Name property is part of the generated URL of the item. So changing the Name property also changes the Url property and thus requires also Moderator approval.

Why do pages that require Moderator approval go out of production?

This behaviour is a design limitation in the current version of the product. The problem occurs due to the fact that the Posting object is not versioned. So there is only exactly one version of the Posting object. Changing the “IsImportant” property would then require Moderator approval. As the change cannot go live without being approved – and due to the fact that there is no other version of the Posting object holding the old value – the Posting object cannot be live any more. So although the Page object holding the content is approved the Page object cannot be live any more and the Posting is removed from the live site.

Btw: this is also the reasons that it is not possible to have a new revision of a Page with a future StartDate: there is only one StartDate and this is hosted in the Posting object and not in the Page object with the content.

The Page object on the other hand IS versioned. So if the item has been approved before the last approved historical revision will be used on the live site while the working revision is waiting for approval.

Workarounds for this problem

There are two recommended workarounds for this:

  1. Do not use the Moderator role in an environment where authoring is done on the production system. This should not be to much of a problem as content changes do not require Moderator approval anyway – only changes to the properties listed above.
  2. Implement a staging environment. In a staging environment it usually does not matter when a posting goes out of production. As Site Deployment does only deploy approved items on the production environment the items would always be visible.


  1. Hi Stefan

    As you have stated in one statement that it is not possible: " Btw: this is also the reasons that it is not possible to have a new revision of a Page with a future StartDate: there is only one StartDate and this is hosted in the Posting object and not in the Page object with the content."

    Would the work around solve the startdate issue?

    I have test the no moderator role solution and it doesn’t seem to solve the problem.


  2. Hi Tupiq,

    no there is no workaround for the startdate issue.

    You cannot have more than one start date per posting.




  3. Has the issue resolved in MS Share point 2007


  4. Hi Tupic,

    in MOSS 2007 you can have one future version for each item.




  5. Thank you for your reply

    I just need more clarification on a couple of questions.

    I have been investigating alternative to resolve the issue on pages that require Moderator approval go out of production.

    Question 1

    It looks like in MOSS 2007 pages and posting information are version together. see link below


    So my question is it is possible to have a new revision of a Page with a future StartDate without the page going offline?

    Question 2

    As you have suggested as a work around to the issue is to create a staging environment.

    I have investigated the Site deployment tool.

    It looks like site deployment will only export

    approved Items only. So what will site deployment do if a page was set to expired on the content creation environment? will the page in the production environment expire after export and import had been performed?


  6. Hi Tupick,

    1) yes.

    2) expired pages are still approved – so they will be deployed and put the item offline on the production as well. In addition the expiration date will also have been deployed to the production server earlier. So the item will expire here also without an additional deployment.




  7. I still have an issue with site deployment tool, when the start date is changed, the page goes to "waiting for editor approval". Site deployment will not deploy this page which is good.  However when it is approved, the page will be deployed. This is an issue when existing pages are pre-approved the existing page will go offline prior to when its intend to be published, if site deployment runs nightly.


    1. when the start date is changed and saved can I intercept the process? I like to have my own plugin to handle future start date publication on existing pages.

    2. I had read the best practice approach from Microsoft regarding site deployment. What are the risk of run site deployment on a production environment very minute without have a backup server, for example directly deploy to production when users(read only) are using it?


  8. Hi Tupick,

    if you change the start date the item will change to "waiting for moderator approval" – not "waiting for editor approval".

    1) yes you can intercept this using a PropertyChanging workflow event handler.

    2) you should only deploy once or twice a day during a time where small traffic hits the site. Reason: during the import the database tables are locked for a short time. That means that page requests coming during this time can result in 500 errors or other
    exceptions. See here:





Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.