Setting up Plone

The public webiste to which content is deployed from the staging environment is conventionally called 'public_website'. EnSimpleStaging will use this as its deployment target, and the public "retail view" theme will only be applied to this folder.

o To create the 'public_website' folder, simply add a 'Folder' in the Plone root from the Plone UI (**not** in the ZMI!).

You may give it whatever title you want. However, since Plone by default does not enable direct editing of "short names" (aka ids), you may want to use the 'actions' drop-down to rename the folder to 'public_website' afterwards (this is mostly for consistency, it doesn't really matter what the folder is called).

**NOTE:** In versions of Plone prior to 2.1.2, the 'actions' menu did not provide rename functionality, so you would have to go to the 'contents' tab in the Plone root to rename the folder instead.

We then need a bit of magic to ensure the "retail view" theme is applied:

o In the ZMI, go to the root of your Plone site, create a 'Script (Python)' with the id 'applyRetailView'::

request = context.REQUEST
if request.get('URL').startswith('http://public'):
context.portal_url.getPortalObject().changeSkin('Retail View')

o Still in the ZMI at the root of your Plone site, select 'Set Access Rule' from the 'add' menu, and enter 'applyRetailView' as the id.

There are several things to note here. First of all, we have created an access rule from the little 'applyRetailView' script (notice how the icon for the script has changed). This means that the script will be called when the folder is visited. When invoked, the script checks the URL in the request, and if it starts with 'http://public', it changes to the 'Retail View' skin (theme). This assumes that the public URL of your web site starts with 'http://public' and that your "retail view" skin is called 'Retail View'. You can of course change these strings if your theme is called something else, or if your public URL is different. All that is required is that the URL does not match the one through which you will access the authoring and staging environment.

For example, if you are running 'http://mysite.net', which is also accessible via 'http://www.mysite.net', and you will do your authoring via 'http://admin.mysite.net' (we will set up the difference between the public and authoring url's in the next section), you could do::

request = context.REQUEST
url = request.get('URL')
if url.startswith('http://mysite.net') or url.startswith('http://www.mysite.net'):
context.portal_url.getPortalObject().changeSkin('Retail View')

Coupled with the Apache or IIS configuration we will cover in the next section, that will make sure your visitors see the public "retail view" skin. However, Zope will not be much wiser.

Let's say a portlet on the public website does a catalog search for all recent news items. Zope would use the 'portal_catalog' tool from the Plone root, which would find all news items regardless of whether they were in the 'public_website' folder or in the stage. The simplest solution is to make sure that such queries include a path query like 'path = "/Plone/public_website'. You can achieve this customising the relevant portlets in your skin, for example.

For other tools, such as 'reference_catalog' or 'uid_catalog', it is actually necessary that the authoring/staging versions and the 'public_website' versions are separate. We can achieve this by setting up custom versions of these tools inside the 'public_website' folder, which will be acquired before the ones at the portal root. EnSimpleStaging ships with an External Method to do just this.

o In the root of your plone create a External method with id, 'setup_local_tools'

- id: 'setup_local_tools'

- module: 'EnSimpleStaging.Install'

- function: 'setup_local_tools'

o Create a Script (Python) with id, 'do_setup'::

from StringIO import StringIO
context.setup_local_tools(StringIO())
return 'Done'

Save this script and click 'test'. It should return 'Done' when it is finished.

Finally, you must set up your workspace. This is where the content production and staging occurs. Content created inside a workspace can be deployed to the public website, either incrementally or all at once. It is also possible to set up different workspaces, perhaps with different workflows or permissions for different groups of users, deploying to different subfolders of 'public_website' (or to the same target, but then you may get conflicts).

o In the Plone interface, create a 'Folder' called 'workspaces'

o In the 'workspaces' folder, add a 'Staging Area', and call it e.g "Authoring Space"

o Set the deployment path for the staging area to be 'public_website'

o If you want only published content to be deployed, enter 'published' in the "Deploy states" field. This ensures that the standard Plone visible-pending-published workflow cycle applies to staged content as well. You can enter other deployable states too, one per line.