George Thiruvathukal, User Experiences with Plone Content Management

Post on 12-May-2015

3,392 views 0 download

Tags:

transcript

User Experiences with the Plone Content Management

SystemGeorge K. Thiruvathukal (speaker)

with special guests:Benjamín González, Matt Bone, and Konstantin Läufer

Loyola University ChicagoComputer Science Department

Emerging Technologies Laboratory

http://www.etl.luc.edugkt@etl.luc.edu

Overview• Our Requirements

• Quick Tour of Plone

• What is Plone?

• The Open Source Definition

• Plone’s Default Content Types

• Publication States

• Content Metadata

• Customizing Plone: Skins/Layers

• Customizing Plone: Archetypes

• Plugins

• Hosting Plone with Apache

• Critique

• Conclusions

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 "limited" devices.

• While less interesting to typical users, good architecture matters a great deal to us. This includes the software design, system scalability, and extensibility.

A Quick Visual Tour

Published View

Edit Mode

Kupu WYSIWYG Editor

Live Search!

Content Properties/Metadata

Content “Explorer”

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

Open Source Licensing• Free Redistribution

• Source code must be included

• Derived works allowed

• Integrity of the Author's Source Code

• No discrimination against persons or groups

• No discrimination against fields of endeavor

• Distribution of license

• License may not be specific to a product

• License must not restrict other software

• License must be technology-neutral

Plone Default Content Types

• Folders

• Documents

• Link Objects

• Files

• Events

• Images

• News Items

Everything you seein Plone is (has) a content

type. Everything!

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)

Customizing Plone

• changing the look/feel

• adding functionality via plugins

• adding user-defined content types (archetypes)

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.

Adding Skins

• Go to the Zope Management Interface (ZMI).

• Go to portal_skins.

• Click properties.

• Add your new skin at the bottom.

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.

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

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

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.

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.

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=("isURL"), widget=StringWidget(label='Project Hosting (URL):'), ), StringField('versionControl', validators=("isURL"), widget=StringWidget(label='Version Control (URL):'), ), StringField('documentationWiki', validators=("isURL"), widget=StringWidget(label='Documentation Wiki (URL):'), ), StringField('developmentWiki', validators=("isURL"), widget=StringWidget(label='Development Wiki (URL):'), ), StringField('versionTracking', validators=("isURL"), widget=StringWidget(label='Version Tracking (URL):'), ), StringField('developerMailingList', validators=("isEmail"), widget=StringWidget(label='Developer Mailing List (email):'), ), StringField('supportMailingList', validators=("isEmail"), widget=StringWidget(label='Support Mailing List(email):'), ), StringField('developersBlog', validators=("isURL"), 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:'), ), ))

Excerpt of Python code to describe an ETLProject Archetype

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US" metal:use-macro="here/main_template/macros/master"> <body> <div metal:fill-slot="main"> <div metal:define-macro="main" tal:omit-tag=""> <h1 tal:content="here/title_or_id"/> <tal:main_block tal:define="fieldList python:[('Project Hosting:', here.getProjectHosting(),'url'), ('Version Control:', here.getVersionControl(), 'url'), ('Documentation Wiki:', here.getDocumentationWiki(), 'url'), ('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'),]"> <tal:field_loop repeat="field fieldList"> <tal:block condition="python:bool(field[1])"> <h2 tal:content="python:field[0]">Label</h2> <a tal:condition="python:field[2]=='url'" tal:attributes="href python:field[1]" tal:content="python:field[1]">Link</a> <a tal:condition="python:field[2]=='email'" tal:attributes="href python:'mailto:%s'%field[1]" tal:content="python:field[1]">email</a> <!--<a tal:condition="python:field[2]=='string'" tal:replace="python:field[1]"/>--> <br/><br/> </tal:block> </tal:field_loop> </tal:main_block>

<tal:block condition="here/getProjectSummary"> <h2>Project Summary:</h2> <tal:replace tal:content="structure here/getProjectSummary"/> <br/> </tal:block> </div> </div> </body> </html>

XHTML+XML code to create the “skin” for ETL Project Content

Type

Generated Editor View

Generated View

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

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.

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).

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.

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.)

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.

Questions?