PLIP21

• Description - Managing multiple Public Sites in Plone
• PLIP - 21
• Proposer - Alexander Limi
• Seconder - Godefroid Chapelle
• Status - Draft

Contents

1. Definitions
2. Motivation
3. Assumptions
4. Proposal
5. Implementation
6. Deliverables
7. Risks
8. Time line

Definitions

Public Site

The term referring to a URL that is focused on external Visitors to the site.

Group Areas

Internally, Contributors will organize the repository into: folders independent of where the content ends up in Public Sites.

Web Designers

The designers of the visual aspect of the site.

Site Designers

The people responsible for the structure and information architecture on a site.

Contributors

The people who create content - articles, news items, pictures.

Ghost Objects

Similar to symbolic links on Unix, these are objects that point to other content objects, and do not contain any content themselves. Can also be looked at as a referencing object.

Motivation

A site may have a big repository of content, structured and branded in ways that make sense internally. Parts of this content repository could be re-branded with navigation menus and delivered as Public Sites, targeted at a certain audience. These "Public Sites" views of the repository are thematic and targeted at Visitors, not Contributors.

Site Administrators manage these branded Public Sites, with the navigation elements and information architecture. They need to perform this job with friendly, productive tools.

In general, this brings Plone in line with the CMS industry's separation of concerns between content production and content delivery. In this case, the concern is logical and not physical.

Assumptions

• Public Sites provide an entry point for virtual hosts, thus making that aspect easier for site administrators. The setup that maps the actual domains into the Public Sites has to be done in Apache, though.

Goals

The main goal is to have an easy way for Site Admins to control what goes on their site, and what part of the site it ends up in. This should be independent of the real location in the back-end.

Public Sites should never contain content themselves - only objects that mirror the content that is located on the back-end system.

Proposal

We propose to introduce the concepts of Ghosts to mirror content from other locations in-place. This will allow you to partition a specific area of the Plone site into a Public Sites area, where only Site Admins have access.

A typical use case would be:

• Contributor writes document
• Contributor decides which sites he wants the content to appear on, and submit the document for publication
• Site Admin sees the document showing up in the review queue. She reviews the document, checks the metadata, and decides where to put it. On the technical side, this is done by creating a ghost object in the location where it should show up in that specific site.
• Content is published and available on the site.

Implementation

The implementation is depending on a Ghost content type, and proper handling of any catalog issues.

The Public Sites also have their own skins, set on traversal via Apache and the Emerging setup.

Deliverables

1. The Ghost Content Type
2. An interface that makes it easy to be inside a document, review it, meta-tag it - and then point to the location where it should reside on the site.
3. A review portlet that knows which site it's located in.
4. Documentation on how to set up Apache to point to the Public Sites.
5. Unit tests.
6. Localization
7. Short and concise documentation on the use of the Ghost objects.

Risk Factors

• We have to make sure the content types and navigation are able to be updated and handled properly by the Public Sites
• We have to make sure searches only search the available objects in the public site, and only return results that are available in the site.
• Separate indexes (catalogs) for each site might be required and/or useful to accomplish this.

Time line

Not decided yet.