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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Three More Lessons
- Django Models and Migrations
- August 2015 Issue of Linux Journal: Programming
- Hacking a Safe with Bash
- The Controversy Behind Canonical's Intellectual Property Policy
- Secure Server Deployments in Hostile Territory, Part II
- Shashlik - a Tasty New Android Simulator
- Huge Package Overhaul for Debian and Ubuntu
- General Relativity in Python
- Embed Linux in Monitoring and Control Systems