1. User Experiences with the
Plone Content Management
System
George K. Thiruvathukal (speaker)
with special guests:
Benjamín González, Matt Bone, and Konstantin Läufer
Loyola University Chicago
Computer Science Department
Emerging Technologies Laboratory
http://www.etl.luc.edu
gkt@etl.luc.edu

2. Overview
• •
Our Requirements Customizing Plone: Skins/Layers
• •
Quick Tour of Plone Customizing Plone: Archetypes
• •
What is Plone? Plugins
• •
The Open Source Definition Hosting Plone with Apache
• •
Plone’s Default Content Types Critique
• •
Publication States Conclusions
• Content Metadata

3. Our Requirements
• Maintaining content should require little/no knowledge of HTML
and web standards. Although we are technical, we don't want to
be bothered with these details in most cases. Content is king...or
queen.
• Published site should be viewable from any standards-compliant
browser on any platform.
• Managing content and performing administrative tasks should also
be possible on any standards-compliant browser on any platform.
• We want to be future-proofed inasmuch as possible. For
example, nothing should stand in the way of supporting non-
desktop clients, e.g. phones, PDAs, or other quot;limitedquot; devices.
• While less interesting to typical users, good architecture matters
a great deal to us. This includes the software design, system
scalability, and extensibility.

4. A Quick Visual Tour

5. Published View

6. Edit Mode

7. Kupu WYSIWYG Editor

8. Live Search!

9. Content Properties/Metadata

10. Content “Explorer”

11. Plone
• a Free/Open Source (FOSS) Content Management
System (CMS)
• focus on non-technical users who want create/manage
web sites
• minimal knowledge of HTML or web standards assumed
in UI
• customization on the other hand requires knowledge of
web standards (XHTML, CSS, XML)
• Python required to extend Plone via plugins

12. Open Source Licensing
• •
Free Redistribution No discrimination against
fields of endeavor
• Source code must be
•
included Distribution of license
• •
Derived works allowed License may not be specific
to a product
• Integrity of the Author's
•
Source Code License must not restrict
other software
• No discrimination against
•
persons or groups License must be technology-
neutral

13. Plone Default Content
Types
• Folders
• Documents
Everything you see
• Link Objects
in Plone is (has) a content
• Files
type. Everything!
• Events
• Images
• News Items

14. Publication States
• Private: Content not viewable by the outside world, even
if URI to reach the item is known.
• Visible: Content viewable by outside world, if URI is
known.
• Published: Visible + URI is linked on page that is already
being viewed (often as part of a navigation portlet)

15. Customizing Plone
• changing the look/feel
• adding functionality via plugins
• adding user-defined content types
(archetypes)

16. Customizing Look/Feel
(Basics)
• Plone's presentation layer is based on skins.
• Skins in Plone are arranged in a layered scheme.
• Each layer contributes presentation elements (templates,
scripts, css files).
• Elements in the upper layers override elements in lower
layers.

17. Adding Skins
• Go to the Zope Management Interface (ZMI).
• Go to portal_skins.
• Click properties.
• Add your new skin at the bottom.

19. Adding New Layers
• Create a new folder under portal_skins.
• Add it as a layer under your skin in
Properties.
• Create/customize your elements under
that folder.

21. Hosting Plone
• Apache Web Server acts as front end
• Zope application acts as server back end
• Plone is simply a Zope product that
provides the core CMS functionality

22. Apache + Plone ==
Happiness
• integrated support for virtual domains (e.g. cs.luc.edu,
etl.luc.edu, math.luc.edu, reu.cs.luc.edu, citep.com, etc.)
• use of Apache virtual host (vhost) and rewriting logic to
map incoming requests to individual Plone sites
• rewriting logic allows each site to appear as separate web
server but in fact all are (or can be) hosted on the same
box
• Plone/Zope itself serves the actual content via Apache
proxying
• option to cache Plone content for performance

23. Archetypes
• A framework in Plone that allows us to easily create content
types.
• A content type is something like a document, link, event or news
item.
• Archetypes is distributed as a Plone Product. (Our own custom
content types will be distributed within a Plone Product, too.)
• To create a new content type you write a Python class
representing the content type and its schema.
• The schema defines the fields contained within the type.

24. ETL Project: An
Example Content Type
• Sometimes you want a page or content item that has a bit of
structure.
• Our research group has a number of projects with common
elements:
• project hosting site
• repository location
• developer and documentation wikis
• version tracking
• developer and support mailing lists
• developer blog, etc.

25. from Products.ATContentTypes.content.base import ATCTContent
from Products.Archetypes.public import *
from Products.ETL.ETLGlobals import *
ETLProjectSchema = ATCTContent.schema.copy() + Schema((
StringField('projectHosting',
validators=(quot;isURLquot;),
widget=StringWidget(label='Project Hosting (URL):'),
),
StringField('versionControl',
validators=(quot;isURLquot;),
widget=StringWidget(label='Version Control (URL):'),
),
StringField('documentationWiki',
validators=(quot;isURLquot;),
widget=StringWidget(label='Documentation Wiki (URL):'),
),
StringField('developmentWiki',
Excerpt of Python code
validators=(quot;isURLquot;),
widget=StringWidget(label='Development Wiki (URL):'),
),
to describe an ETL
StringField('versionTracking',
validators=(quot;isURLquot;),
Project Archetype
widget=StringWidget(label='Version Tracking (URL):'),
),
StringField('developerMailingList',
validators=(quot;isEmailquot;),
widget=StringWidget(label='Developer Mailing List (email):'),
),
StringField('supportMailingList',
validators=(quot;isEmailquot;),
widget=StringWidget(label='Support Mailing List(email):'),
),
StringField('developersBlog',
validators=(quot;isURLquot;),
widget=StringWidget(label='Developers Blog (URL):'),
),
TextField('projectSummary',
searchable=1,
default_output_type='text/html',
default_content_type='text/html',
allowable_content_types=('text/plain', 'text/structured', 'text/restructured', 'text/html'),
widget = RichWidget(label='Project Summary:'),
),
))

26. <!DOCTYPE html PUBLIC quot;-//W3C//DTD XHTML 1.0 Transitional//ENquot;
quot;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtdquot;>
<html xmlns=quot;http://www.w3.org/1999/xhtmlquot; xml:lang=quot;en-USquot; lang=quot;en-USquot;
metal:use-macro=quot;here/main_template/macros/masterquot;>
XHTML+XML code to
<body>
<div metal:fill-slot=quot;mainquot;>
<div metal:define-macro=quot;mainquot; tal:omit-tag=quot;quot;>
create the “skin” for
<h1 tal:content=quot;here/title_or_idquot;/>
<tal:main_block
ETL Project Content
tal:define=quot;fieldList python:[('Project Hosting:', here.getProjectHosting(),'url'),
('Version Control:', here.getVersionControl(), 'url'),
('Documentation Wiki:', here.getDocumentationWiki(), 'url'),
Type
('Development Wiki:', here.getDevelopmentWiki(), 'url'),
('Version Tracking:', here.getVersionTracking(), 'url'),
('Developers Mailing List:', here.getDeveloperMailingList(), 'email'),
('Support Mailing List:', here.getSupportMailingList(), 'email'),
('Developers Blog', here.getDevelopersBlog(), 'url'),]quot;>
<tal:field_loop repeat=quot;field fieldListquot;>
<tal:block condition=quot;python:bool(field[1])quot;>
<h2 tal:content=quot;python:field[0]quot;>Label</h2>
<a tal:condition=quot;python:field[2]=='url'quot; tal:attributes=quot;href python:field[1]quot; tal:content=quot;python:field[1]quot;>Link</a>
<a tal:condition=quot;python:field[2]=='email'quot; tal:attributes=quot;href python:'mailto:%s'%field[1]quot; tal:content=quot;python:field[1]quot;>email</a>
<!--<a tal:condition=quot;python:field[2]=='string'quot; tal:replace=quot;python:field[1]quot;/>-->
<br/><br/>
</tal:block>
</tal:field_loop>
</tal:main_block>
<tal:block condition=quot;here/getProjectSummaryquot;>
<h2>Project Summary:</h2>
<tal:replace tal:content=quot;structure here/getProjectSummaryquot;/>
<br/>
</tal:block>
</div>
</div>
</body>
</html>

27. Generated Editor View

28. Generated View

29. Plugins
• Live search: Allows users to search the site locally (similar to
desktop search) by typing a few characters of the search string
(now part of Plone >=2.5).
• Kupu: WYSIWYG editing. Plone 2.1 and earlier used to require
the use of structured text, which is great but sometimes lacks the
richness and clarity of HTML.
• JavaScript/CSS Menuing: The ability to introduce JavaScript menuing
into a site by describing the navigation as a basic HTML table.
(Our cs.luc.edu site uses this capability.)
• Google Analytics for Plone: http://ingeniweb.sourceforge.net/
Products/AnalyticsForPlone

30. Plugins: Zope + Plone
• Plone is a Zope product and addition plugins (for Plone and
Zope) are available through the extensible Zope architecture.
• Zope is a Python-based extensible application serving platform
(similar to J2EE and .Net).
• In addition to full support for HTTP, Zope provides support for
DAV, FTP, and other emerging web standards.

31. Critique: The Good
• Content types are part of a sophisticated vocabulary for thinking
about a web site.
• Plone places a premium on ease-of-use for day-to-day content
management (i.e. content writers).
• Plone is a project with considerable community interest with
hundreds of plugins available. (one of the most active as measured
by http://cmsmatrix.org.
• The ability to do practically everything (as user and developer)
within the browser and no client plugins (e.g. Java or ActiveX) on
any major platform (Linux, OS X, and Windows) is compelling.
• End-user documentation for end users is excellent. One of the
few CMSs with a significant number of published books.
• Installation is a breeze on most major platforms (Windows, OS
X, and Linux).

32. Critique: The Bad
• While content writing can be done with WYSIWYG editors, the
same is not true of layout at this time, hence the code examples
we’ve presented.
• Rich and powerful XML based template system requires
significant technical (read: Python) knowledge to master.
• Despite the Plone project's maturity, technical documentation
remains somewhat weak (an irony, considering the user docs are
excellent).
• Some might take issue with the integration of content
management and content serving within the same framework.
Straightforward integration with Apache remedies this issue in
part but the content still comes from the CMS itself.

33. Critique: The Ugly
• Some Plone releases (e.g. 2.1) have presented great difficulty
when migrating from the previous releases (2.0).
• Some plugin interactions can result in an unusable setup. When in
doubt about a plugin, we recommend testing it in a non-
production “sandbox” first.
• Zope uses its own database, which seems to deliver excellent
overall performance. Not having a standard database backend
(e.g. MySQL or other relational DB) makes it difficult to do
proper backup, which requires a special script. While MySQL is
allegedly supported, we have not gotten it working yet. (The ZEO
effort appears to be a recent effort to enhance support for load
balancing and 3rd-party databases.)

34. Futures
• University has recently acquired a commercial CMS.
• We'll continue to support and use Plone for specialized needs
(e.g. research groups like ETL, student activities, and individual
web sites) within our department.
• Plone is a great solution, especially for small departments and
groups with a need to get content up/running quickly and reliably
with a consistent look/feel. As shown, with some work, Plone can
be customized to give the appearance of a hand-crafted web site.
• The ability to manage content from anywhere with a minimum
number of browser dependencies is a key strength of Plone. Many
CMS solutions require ActiveX or Java plugins that either do not
work properly outside of Windows/IE or have not been tested
sufficiently on alternate platforms, e.g. Linux and OS X.

35. Questions?