George Thiruvathukal, User Experiences with Plone Content Management

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

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

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.

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 No discrimination against ﬁelds of endeavor • Source code must be • included Distribution of license • • Derived works allowed License may not be speciﬁc 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

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

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-deﬁned 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 ﬁles). • 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 deﬁnes the ﬁelds 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=(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:'), ), ))

<!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>  <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>

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 signiﬁcant 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 signiﬁcant 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 sufﬁciently on alternate platforms, e.g. Linux and OS X.

Questions?

George Thiruvathukal, User Experiences with Plone Content Management

by webcontent2007

Accessibility

Categories

Upload Details

Usage Rights

Statistics

George Thiruvathukal, User Experiences with Plone Content Management Presentation Transcript