Plone is a content management system. A lot of thought has gone into the user interface that enables the modification and organisation of content and workflow. Plone is also used as a content delivery platform, pushing content (via Zope and probably a web server like Apache) down to the browsers of people who just want to view the content, not manage it. Typically, it is the same object (e.g. a page or a news item) that is the point of reference for the person managing the content and the person consuming it. We'll call this scenario "in-place editing".

For many people, this in-place editing works well. It is easy to understand, it is easy to see the effects of your changes, and this is indeed the default way of doing things in Plone. For some more demanding users, however, in-place editing can be a problem. The use case here is when Plone is used principally to manage content such as pages, news items or events that is to be presented in a branded website. Some of the drawbacks of the in-place approach are:

Theming

For a professional public-facing website, you'll probably not be happy with the standard Plone look-and-feel. It is not very hard to re-theme Plone, but often your public-facing theme and branding may be difficult to adapt to a content-editing scenario. Patching together Plone's editing views with your designer's vision of the public web site often leads to sacrifices in one of Plone's strongest areas: usability.

Control

You may want to impose more control on how the final site ends up looking than what standard workflow can support. For example, you may want to your content editors to work on several parts of the site at once, but only update the public site when all the pieces are ready. Workflow for in-place edited documents works on one item at a time. Worse, there is no support in an out-of-the-box Plone site for working on an already-published document and only publishing the changes when they have been finalised and approved.

Performance

Because it has to support logged-in users making changes to the live system, Plone's default authoring templates are harder to cache, deploy to other delivery platforms (e.g. using Entransit or CMFDeployment) and performance optimise.

Repeatability

If you are a consultant or technical lead setting up "serious" deployments of Plone more than once, having a repeatable way of setting up your Plone sites robustly is important. With in-place editing, it's more difficult to separate the repeatable parts of the development and deployment process from the parts that need heavy customisation, from the parts that should ideally involve no change to Plone's default behaviour.

The approach described in this tutorial is the one championed by Enfold Systems for enterprise deployments. Briefly, it consists of:

• Standard Plone as the content management environment
• A folder in the Plone root, conventionally called public_website, where the public website is located. All day-to-day content management happens outside of this folder. When content is ready, it is deployed to the public website.
• This two-staged approach to content publication is called staging, and is enabled by EnSimpleStaging.
• A "retail view" for the public site - this is simply a Plone skin that deals only with the public view of the site, not any editing views. As such, it can be greatly simplified from the full-blown Plone skin. Often, it is easiest to disregard Plone's main_template and CSS entirely, providing your own alternatives only as far as your needs go. (For optimisation in advanced use cases, using Five views for these views may be a good idea)
• Two URLs configured for the site via Apache rewrite rules. For example, http://admin.mysite.net may point to the standard Plone root and the Plone editing environment, whilst http://mysite.net would be the public view, pointing to the public_website folder directly.
• An Access rule in the public_website folder. This is a Zope mechanism that in this case will be used to ensure that when accessing public_website from the URL http://mysite.net, visitors will see the "retail view", not the standard Plone skin.

We will cover these steps in more detail in the following pages. Before you launch into this, though, you need to carefully consider whether you really want or need staged content and separate editing and display environments.

There are several reasons why this setup is not the default:

Ease of use

For many users, separate editing and delivery skins may be confusing. It is harder to see exactly how content will look in the final site (which may necessitate content previews or similar solutions), and it is more difficult to know to change something on the public site, say if you discover a problem with a page there. You can of course get around this by customising the standard Plone editing skin as well, but this kind of defeats the point; alternatively, you will have to rely on previews or similar mechanisms.

Set-up time and difficulty

This approach does require more set up than a vanilla Plone site, and you generally have to know what you're doing. If you don't understand acquisition, workflow, security and other basic Zope and Plone mechanisms fairly well, you are likely to find yourself in deep waters soon.

Interoperability

Most products are written for the default set-up of in-place editing. Hence, not every product will work equally well with staged content. If you have a highly interactive site where users are logged in most of the time and use the system as an application rather than purely for viewing content, you're likely to find that many of the products that provide this interactivity make assumptions that don't gel with the staged approach.

Sometimes it may be worth working around these problems, sometimes it may not be. Since there is no one right answer, you'll have to rely on your experience and prototyping to find the balance that works for you. If you are in doubt, read on and think carefully about what is being suggested. If this tutorial doesn't make much sense to you, you're probably better off sticking with in-place editing, at least for the time being. It shouldn't be too difficult to move to a staged solution at a later date if it becomes necessary.