Using CMF controls, custom skins and other Zope-based tools, Plone can look and feel however you want.
The market for content management systems (CMS) continues to grow by leaps and bounds, which should come as no surprise. Several years ago, a CEO might have wondered whether to create a web site for his or her company. Nowadays, the question is not whether to put up a site, but how to manage the people who run it and organize the information it contains. A good CMS makes it easy to handle all of this, by taking care of users, groups, permissions and scheduled publication.
But as anyone experienced with mission-critical software knows, software rarely (if ever) handles everything you need out of the box. Companies such as Vignette and Documentum, which sell and service their own content management systems, use this to their advantage and demand consulting and support fees from their customers. CMS customers would prefer to put as much power as possible in their own hands, both to avoid paying consulting fees and to have a greater degree of freedom on a day-to-day basis.
It should come as no surprise that open-source content management solutions allow and even encourage users to modify their own CMS software. But all too often, modifying a system means changing the source code, which not everyone is prepared or able to do. Writing a CMS that is simultaneously powerful, flexible and simple for nonprogrammers to customize has turned out to be a difficult and challenging task, one that is likely to occupy the time of many CMS vendors for years to come.
An increasingly popular open-source CMS, and one that makes it easy to customize a site's look and feel without too much programming, is Plone. Plone does not exist in a vacuum but is built on top of Zope's Content Management Framework (CMF), a set of APIs for creating content management systems. As we saw last month, Plone makes it easy to create a web site that has a number of advanced features built in, including an event calendar, a news archive and a search engine.
But what happens when you want to change things? What if you don't like Plone's default look and feel? Luckily, Plone was designed to be modified in a number of ways and at a number of different levels. This month, we look at some of the ways in which Plone can be modified. Along the way, we learn quite a bit about Zope's CMF, which serves as an excellent segue to next month's CMF tour.
One of the most basic ways you can customize Plone is by modifying the look and feel. To do this, you need to log in to Plone as a site manager. Assuming you configured Plone in the standard default way, there are two ways to accomplish this. The simpler one is to log in to Plone as a site administrator, giving the user name and password you would use with the web-based Zope management interface (ZMI). Plone normally inherits user names, passwords and roles from its surrounding environment, so you can log in to Plone with those credentials.
Unfortunately, logging in to Plone means you aren't recognized as being logged in by the rest of the Zope site. To avoid this problem and to be able to manage both Zope and Plone, log in to your site at its /manage URL. For example, if your site is located on www.example.com, you can try to log in as the administrator by going to www.example.com/manage.
Once you have entered a Plone site as a site manager, you should see a menubar across the screen, under the main menu of boxes and right over the “you are here” line. Click on the menu item named Plone setup.
Once inside Plone setup, you are asked to answer several questions, such as the name of your Plone site (or portal, as Plone refers to it) and the e-mail address from which system messages should be sent. One of the options allows you to choose a default look, with about a dozen such looks provided in the default installation. A change to the site's default look takes place immediately, allowing you to view and then change whatever look you have chosen.
As the name indicates, the color scheme you choose here is only the default. All users on the system can go into the My Preferences menu and change their own looks. Thus, even if you want your site to have the look of New Mozilla, a user with more conservative tastes can choose something else.
Unfortunately, the majority of Plone cannot be configured from within Plone itself. Rather, you must use the Zope management interface to modify Plone as if it were a simple component of the CMF. This means using a number of CMF controls to change the default Plone look and feel.
I was able to get to these controls by pointing my browser to the folder above the place where I had created my Plone instance. That is, if I access my Plone site at www.example.com/atf, I get to the management interface at www.example.com/manage. The management interface shows all of the objects in the top-level folder, including my Plone instance. Clicking on the Plone object (atf, in our particular case) brings up a long list of objects, most of which begin with the word portal: portal_catalog, portal_calendar, portal_skins, portal_membership and portal_undo, among others. Objects with wrench icons are CMF tools, allowing you to modify part of your Plone instance. For example, the portal_actions tool allows us to modify the different box-like buttons that appear in various places within a Plone site. These include the buttons at the top of each page, such as news and advanced search, and the buttons that appear when a site administrator wants to edit content over the Web. Each action is controlled by seven fields:
The name of the action that is displayed to the outside world within the box.
A unique identifier.
The action that should be taken when the user clicks on a box, which is expressed in TALES format (from the Zope Page Templates system for web templates), normally pointing to a URL.
The (optional) conditions under which the button should be visible. For example, the Paste button should appear only if there is valid information in the current clipboard, a condition represented in TALES as folder/cb_dataValid.
The permission a user must have in order to see this button. For example, if an action has View permission, then anyone authorized can see the action box and is able to click on it. By contrast, if an action has Modify folder content permission, then only the users authorized to modify content can see the action's button box.
The category in which the button should be placed, such as portal_tabs (shown at the top of the screen) or object_tabs (at the top of the screen).
Finally, we can show or hide actions by clicking and unclicking the check boxes.
Adding, deleting and modifying actions is quite easy. But what if we want to add, remove or shift around the portlets that appear on the right and left sides of a Plone site? These items are known as slots in Plone, and they are customized by modifying the properties of the Plone instance itself. That is, you must click on the Plone instance you created (atf in this case) and then on the properties tab at the top of the page.
The left_slots and right_slots properties determine what is displayed on the side. If you have recently installed a Plone instance, you immediately will notice that each slot contains more lines than slots displayed at the top of the screen. This is because a portlet is displayed only if there is something to display. If, for example, no current events are defined, Plone does not display your events portlet at all. The portlet named in the third line of left_slots thus might appear first, second or third, depending on whether the first and second contain any current content.
On my own site, I was able to move the event listing to the left side and the calendar to the right side (and remove the login portlet altogether), simply by modifying the definitions of the left_side and right_side properties. Making these sorts of changes is both easy and quick, and they allow you to include only the functions you want on your site.
Finally, click on the portal properties link that ZMI displays within your Plone instance. This has a Plone icon rather than a wrench icon, indicating that this tool is specific to Plone and not generally available in the CMF. Clicking on this brings up a list of four different property lists (form_properties, navigation_properties, navtree_properties and site_properties), each of which allows us to change some of the properties on our Plone site.
If you click on site_properties, the list might seem strangely familiar. That's because site_properties lists many of the same settings we saw earlier. Plone itself exposes only the most common and necessary settings; more complex and advanced settings are available through the ZMI. It doesn't really matter whether you change the date format, for example, from the ZMI or the Plone settings page; in either case, the site immediately changes to reflect the new value.
We can modify quite a bit of our Plone site by changing property definitions and using the ZMI. But if you really want to change your Plone site, you need to modify the page templates (ZPTs) that come with the system. This is easier said than done. The default ZPTs are stored in the filesystem, in such directories as $ZOPE_ROOT/lib/python/Products/CMFDefault/skins (for CMF content) and $ZOPE_ROOT/lib/python/Products/CMFPlone/skins/ (for Plone content). Modifying the skins within these directories affects all Plone instances, which is not what you want.
Plone takes this possibility into account and allows you to copy one or more ZPTs into Zope's object database (ZODB), where you can edit it as you would any other ZPT. For example, from within the ZMI, enter the portal_skins tool and then the plone_templates folder within portal_skins. plone_templates looks like a normal Zope folder (aside from the different icon), but it reflects the contents of files on disk rather than those within ZODB. plone_templates contains the ZPTs for most of the pages you see within Plone. The ui_slots folder within plone_templates contains ZPTs that determine how the portlets look.
If you want to modify the header that appears at the top of each page within your Plone site, you can click on the header icon. This brings you to a page that lets you view, but not modify, the header page template. In order to modify the header, you must export it to the custom folder, which exists only within ZODB. Click on Customize, and you can see that the URL has hung within the ZMI, putting you now within portal_skins/custom rather than within portal_skins/plone_templates. This custom folder is the central repository for all customized templates, and you can edit them as you would any other ZPT on the system. Because the custom folder is specific to each instance of Plone, you can be sure that any changes you make affect only what you are working on.
If nothing else, it is worth looking through the header and footer page templates to see the great deal of customization work that was done, largely in JavaScript, to make sure that Plone would work on different browsers. Given that every browser has somewhat different support for CSS and JavaScript, it is rather impressive to see the great deal of effort the Plone authors put into keeping things as level as possible.
Of course, this means you might be in for a surprise or two. My father, who used Netscape 4 until quite recently, complimented me on my new site and on the fact that it chastised him for not using a more modern browser. Because I have long been using the latest versions of Mozilla and Galeon, I hadn't ever seen this message; it never occurred to me that one would appear. The Web would be a better place if every application were so clever and conscientious about checking cross-platform compatibility.
Plone is probably the best-known and most popular application written with Zope's CMF, one that is powerful and easy to customize. Between Plone-specific customization screens, changes that we can make with the ZMI and modifications to the page templates by importing them into the custom folder in ZODB, we can change things in a great many ways. We also can add new custom skins to Plone, contributing to the already interesting and varied options that come with the distribution.
Of course, Plone is only one application built using Zope's CMF. Next month, we will peel away another abstraction layer, looking at the CMF directly and seeing what sorts of applications we can create with it. As you will see, there is good reason why the CMF is attracting a great deal of attention in the Zope community, as well as from Zope Corporation itself.