Update: I now (May 2009) stopped working with/on Plone in favor of Django simply because working with Plone is no fun anymore. Plone has become way to fat and confusing to work with over the years — I need something that works with me, not against me.

It might be a good idea to read Plone's FAQs (Frequently Asked Questions) before continuing. Also, there are other documents (0 1) which I strongly recommend reading since they introduce the some of the basic principles of Plone, what it is, how it works and what can be done aside from the default out of the box Plone setup. From my point of view, reading the Glossary is a must too. After reading those documents, anybody can consider himself a Plony even if still at the beginning of his Plone career ;-] For those who want to compare their CMS (Content Management System) with Plone there is a way to do so.

What is a CMS?

Plone is a CMS but then, would somebody please explain to me what a CMS is ... what defines a CMS (Content Management System)? One simple definition for a CMS is that it is a system for managing content. This is a rather unhelpful definition, so let us break it down into smaller parts for a fuller explanation. We start with a broad definition of content:

Content is a unit of data with some extra information attached to it. That piece of data could be a webpage, information about an upcoming event, a Microsoft Word document, an image, a movie clip, a GNU Emacs initilaziation file or any other piece of data that has meaning to the person/organization deploying a CMS.

All these items are called content, and they all share similar attributes, such as the need to be added or edited by certain users and be published in various ways — a mechanism called workflow controls these attributes.

Historically there has been a difference between document management systems and CMSs but mostly these two systems have converged. The essential difference is the items being managed — it is often considered that content is any unit of information, and a document refers to something that is created and edited by humans using software such as Microsoft Office or GNU Emacs. Take, for example, a book: A book contains many units of data and may require management slightly different from that required by content. However, in most cases, this is a small difference, and products such as Plone are able to manage the small units of a larger piece of content and reassemble them.

With the ubiquitousness of the WWW (World Wide Web), many CMSs are now classified as WWW CMSs, either because they have a WWW-based interface or because they focus on a WWW-based delivery system over the Internet or an intranet. Plone provides a WWW management interface also known as web-interface and uses a WWW-based delivery system for its content.

The following is one definition of a CMS (http://www.contentmanager.eu.com/history.htm):

A CMS is a tool that enables a variety of (centralized) technical and (decentralized) nontechnical staff to create, edit, manage and finally publish a variety of content (such as text, graphics, video, and so on) whilst being constrained by a centralized set of rules, process, and workflows that ensure a coherent, validated WWW site appearance.

Do I need/want a CMS?

Although not the only advantage of a CMS, the most obvious benefit of a CMS is coordinating a website easily. Take a situation where one person, a Webmaster, coordinates a website, either an intranet or an external site that is on the Internet. Content comes from users in a variety of formats, and the Webmaster turns these into usable webpages by converting them to HTML (Hypertext Markup Language). If a user has to change those pages, then the user sends the changes to the Webmaster, who changes the pages, and so on ...

This presents many problems for the organization, the biggest being that all content is flowing through one person — an obvious bottleneck and a single point of failure. That one person can do only so much work, and if that person is sick or leaves the company, a great deal of productivity is lost in finding a replacement. The publishing process can be quite frustrating as mostly e-mails fly between the Webmaster and the user trying to get content published. Of course, there is also no use of eventually more suitable technology involved (e.g. MUCs (Multi User Chats)) since ordinary folks simply live in a email-only world and are mostly totally unwilling to learn new things ... So, because of that thingy called Real World out there, what is needed is a system that does the following:

• Separates the content of a page from the presentation i.e. If the actual content is separate from the presentation method, then the content author does not need to know any HTML, CSS, etc. nor how the page is delivered to the viewer. In fact, one piece of content could have many different templates applied to it, including formats other than HTML, such as PDF (Portable Document Format), SVG (Scalable Vector Graphics) etc. When we want to change the look and feel of the site, we would simply have to change only that one template rather than all the content.
• Allow certain users to add and edit content i.e. If specified users can add and edit content easily, then there is no need to send content to the Webmaster or third persons. Instead, the user who wants to create a page can do so and edit it as much as necessary.
• Apply rules to who can publish what and when e.g. Our business rules might not want just anybody publishing content on our website. For example, people in marketing would be able to publish to the press release part of the site and not to the engineering section and vice versa.
• Can apply business rules to content i.e. If a person from marketing creates a press release, somebody in legal might need to review that document. In this case, the document will be passed through a review process that ensures it will not go live until these reviews are done.
• Can search and index information intelligently i.e. Since the CMS can keep track of structured information about the content (such as author's name, publication date, modification dates, categories, and so on), it can produce listings of content by author, recent content, and so on. It can also provide searching capabilities that are much smarter and more useful than just a simple textual search.

Although this example portrays paybacks that are more significant for large organizations, organizations of all levels benefit from this approach. In fact, typically small organizations that do not employ a full-time Webmaster can be one of the key beneficiaries of such a system.

By installing a CMS, we can resolve all these issues and more. The key factor of any CMS is that it provides a clear separation of the key elements in it i.e. security, workflow, templates, and so on. For example, the templates presenting an item are separate from the content. This allows one to easily modify the presentation.

Feature Checklist for CMSs

This is a checklist for common features a CMS should provide.

• Manage registration Can users self-register? Can veto by administrator be enforced?
• Modify header Change the header text across the site (how do I have to edit it? can end users edit it once I deploy the site to them?) Change header image and move it to the other side of the page.
• Edit homepage Edit the homepage and replace its content with a page which has headings, images and body text (what granularity do I get e.g. can I break a page into blocks and reuse them elsewhere, so I could do submenus?) Can I place the images easily? Can I upload images through the browser and use them on my pages?
• Modify text styles Change the font of all body text on the site — how close is the content to representation (HTML) — can the representation change without doing any changes to the content?
• Modify column layout Change the layout from the default to one with one less column, whilst retaining any elements in the removed column OR Change the default layout to one with one more column, and shift half of the first column's content to the new one OR Create a column-less layout and move navigation into header.
• Within-site links Create another page and link it to the first one Does it turn up in the navigation? How difficult is it to work out the URL (Uniform Resource Locator)?
• Customisable menus Add the second page to the navigation, as a child of the first, if it was not done automatically.
• Item display by criteria Configure the events area to only show events for the current/next/particular month OR next/last n events.
• User with restricted access Add a user fred who can only add and edit events — as fred, adds a new event which starts tomorrow and ends in a week's time, but release notification now. Restrict access by IP address/range.
• Workflow facilities Add a user bill who can add events but requires someone else to OK them before they go live. Add an event as bill but validate bill's event as administrator.
• Controlled release Add another event and set the release time for the announcement to today but some time in the future (e.g. 2 hour's time) check it does not display in the events area.
• Archiving Create a separate area for archived events (i.e. events which have already happened but which need to remain visible).
• Custom data types Create a Group information category and associated Group type, which allows to list and search information about the following example groups:
  1. Pigeon Fanciers Group Meets the first Monday of each month in the Council Offices, room B6
  2. Greyhound Owners Club Meets every Wednesday at 16:00 in the Village Hall, and Friday at 14:00 in the Council Offices
  3. Pipe Smokers Society Meets every Tuesday at 12:00 in the Old Shed
• Area for specific data types Add an Events area, linked from the navigation — it should display as a separate page with a list of forthcoming events.
• Dynamic in-lining As two groups meet in the Council Offices, put the address information for this location into a central web page on the site and link both groups meeting location details to it.
• Versioning and rollback Delete all the text from the homepage, save it in this state, then recover it back to the last pristine version.
• Access-controlled areas Create a protected area of the website called Members only with a single document describing a special members-only offer — it should only be accessible to registered members of the site.
• File upload Upload a PDF and create a link allowing users to download it — protect the PDF and make it only accessible from within the members only area.
• Printable versions Produce a printable PDF version from the home page.
• Syndication Syndicate the events or news page as RSS.

Introducing Plone

After the reader has read the Abstract, this section continues towards this path — it provides an overview of Plone in order to get a better notion about what it is, what it can be used for and how it might be adapted to fit specific needs.

Plone is FLOSS (Free/Libre Open Source Software), licensed under the GPL (General Public License), which is a common open-source license that allows anyone to use the source code for free. For more information about the GPL, go to the FSF (Free Software Foundation) website at http://ww.gnu.org.

Anyone can examine any aspect of Plone's source code and alter it to fit his needs. There are no licensing fees to pay, there is no license that will expire, and all the code is visible. This open-source philosophy means that Plone already has a large user base and legion of developers, usability experts, translators, technical writers, and graphic designers who are able to work on Plone. By choosing Plone, you are not locked into one company (also known as vendor lock-in) — rather, nearly a dozen companies offer different Plone services.

Overview

A company without a website is unthinkable and most companies and organizations have more than one website. Whether it is an external site for communicating with clients, an intranet for employees to use, or a site for direct client communication and feedback, all websites have a common problem — how to manage the content on them.

This is a challenge that can often cost organizations large amounts of time and effort and thus elevate TCO (Total Cost of Ownership) dramatically. Producing a powerful, yet flexible system for these sites that meets ever-changing requirements while growing to meet a company's emerging needs is not easy.

No matter what the requirements for a website are or the amount of content or users, Plone is a user-friendly, powerful solution that lets us easily add and edit any type of content through the Web, produce navigation and searches for that content, and apply security and workflow to that content.

Plone enables us to put together almost any website and easily update it. This lets us build content-rich sites quickly so we can gain a competitive advantage. Finally, probably the best things about this system are that it is free and open source better known as FLOSS (Free/Libre Open Source Software). With its large and impressive feature set, it is comparable, if not better than, many closed-source content management systems that cost hundreds of thousands of dollars.

Mike Sugarbaker says the following when reporting on the Open Source Content Management Conference (OSCOM) in 2002 for the Mindjack site (http://www.mindjack.com/events/oscom.html):

I will not do the complete rundown of all the competing open-source content management frameworks. I will cut to the chase: The winner is Plone. This poductized take on the six-yearold web application framework Zope was the package with the most tools, the most professionalism, the most traction, and, above all, the most buzz.

Default Capabilities

Standalone installation packages are available for all major operating systems, including Windows, Mac OS X and several Linux distributions. The raw Zope/Plone Products and Python Eggs are also available for download, and are easy to add into a standard Zope installation.

Plone stores all content in the ZODB (Zope Object Database), and all of the elements of a Plone site are objects within the storage. This means there is no need for a separate database to be installed (though the ZODB can be stored in a database if desired). Below are some feature highlights included in a standard installation:

• Management interfac: Almost all of Plone's functionality can be managed through a web interface, including starting and stopping the server, viewing logs, setting permissions, and creating and editing content.
• Epoz editor: This is a WYSIWYG editor for all content on the website.
• Member areas: Each user of the site gets their own personal area, where they can build their own set of pages, including news items, events, and discussion topics.
• News: Any added news item becomes part of the news feed section of the site.
• Events: Events can be added by any user, and are incorporated into a clickable calendar displayed on every page of the site.
• Accessible templates: The default Plone templates conform to the WAI WCAG level 3, and the page mark-up produced is valid XHTML.
• Workflow: Plone has one of the most flexible and fully-featured workflow systems of any of the CMSs available. The default workflow for new content items allows private editing of the new item, followed by submission to the review queue, then publication once approved. At each stage of the workflow, user and group permissions can be set to define who can move the item onto the next stage (or back to a previous stage if it is rejected). Workflows are also heavily customisable, and a wide range of scenarios can be specified.
• Archetypes: This is a framework for adding your own content types to the default Plone types. New types are defined in a text file (schema) which specifies the fields the type has, the kinds of content allowed in those fields (e.g. text, HTML), the widgets to present when those fields are edited (e.g. drop-down box, radio buttons, text field), and the validation rules to be applied when new instances of the type are created. Plone uses the schema file to generate all the forms necessary for updating, deleting and adding instances of the type; it then handles all modifications automatically, without the developer needing to write any persistence code. While the generated code (e.g. HTML forms) is often adequate, it is possible to further customise it to improve its appearance or usability.

Additional Modules

As Plone runs on top of Zope, all of the features of Zope, including its multitude of Plone Products and Python Eggs (packages providing additional functionality), are potentially available inside Plone (in some cases, they may need a bit of tweaking, though). Products and tools specifically targeted at Plone are available from the product page. Some of the more useful ones are summarised below.

• CMFWeblog: Blogging functionality for Plone.
• Calendaring: Calendar functionality which extends the base Plone calendar, including iCal import and export and a variety of different views (day, week, month).
• CMFStaging: Adds staging functionality to a Plone site, so a development version and a live version can be worked on concurrently within a single site.
• Database adapters: A variety of adapters for different databases are available for Zope, including MySQL, PostgreSQL, Firebird, SQL Server, and Oracle. These products allow Zope (and Plone, by association) to interact with a database external to the Zope installation (e.g. to pull records from a database and display them).

There are many more Products available for Plone and Zope (far too many to go into here). One thing in Zope's favour is its relative maturity compared to other CMSs, so many of the Products available for it are well developed and stable. Plone also provides facilities for creating tools, which provide functionality (typically, site-wide properties) for a whole Plone site. For example, a tool might provide data about membership of the site, or about the site's navigation. Another interesting feature of Zope is the possibility of clustering Zope Instances to create a high available, scalable web serving infrastructure — one way to go here would be ZEO (Zope Enterprise Objects).

Template Extensibility

Plone has a very flexible and powerful templating system called ZPT (Zope Page Templates), based around TAL (Template Attribute Language) and METAL (Macro Expansion Template Attribute Language), both of which are specific to Zope. These languages provide facilities for pulling elements from the object database and displaying their properties within HTML (similar to how PHP can be used to pull data from a database like MySQL and create HTML pages from it).

It can initially be confusing when getting to grips with how templates are organised and written in Plone. For example, working out which templates to edit to achieve a desired effect can be a challenge in itself. However, once used to the extreme separation of content from presentation, and getting to grips with ZPT, the templating system turns out to be a very powerful mechanism.

For developers who do not want to create custom templates, a lot can be done simply by editing the site-wide Plone styles — for example, it is easy to change fonts, colours, borders, spacing etc. It is also possible to add, remove or move portlets (small chunks of HTML displaying in side borders) using the management interface. So, for instance, we could use this to move all the portlets from the right-hand column into the left-hand column, resulting in a two-column layout rather than Plone's default three columns.

Elegance

Plone has been designed using object-oriented principles from the beginning. This means that the code is very elegant by comparison with some of the PHP offerings available. The fact that Zope was developed by a professional software house before being open sourced was possibly a factor in this. One consequence of this good design, though, is that the code is extremely abstract — it is often difficult to pin down where a particular piece of functionality comes from, as it may have originated a long way up the tree of inheritance. One may occasionally find it necessary to delve into the Plone code to work this out.

Having said this, a lot of Plone functionality can be added by creating Plone Products or Python Eggs without worrying too much about the Plone code. A Product is basically a bundle of Python code, packaged according to a packaging specification. Products have access to an API (Application Programming Interface) which gives access to virtually the whole of Plone. So there really is little need to customise the core of Plone, as a Product has all the flexibility most developers will need.

Many folks starting out with Plone development tell that the biggest challenge may be understanding how Plone is organised, where properties are configured, where one should add his new stylesheets, and so on. Once the internals are understood, adding functionality to Plone pretty much comes down to ones personal Python programming skills.

Introducing Plone's Features

This subsection lists and describes a selection of the most significant features with plone.

Packaging

Plone maintains easy installers for Windows, Linux, and Mac. Other third-party products and add-ons also come with the installers. Maintaining quality releases of these products makes installation and management easy. Also, each new release maintains migration paths and updates so that a Plone site will keep working and stay up-to-date.

Internationalization

The whole Plone user interface is translated into more than 20 languages, including Korean, Japanese, French, Spanish, and German. Inserting our own translation is easy.

Usability

Plone offers an excellent user experience that provides high levels of usability and accessibility. This is not just a matter of presenting pretty HTML but instead goes to the core of Plone. Plone provides an interface that is compatible with the industry and government standard WAI-AAA and U.S. Section 508. This allows sites built with Plone to be used by people with vision disabilities. In addition, this provides the unexpected but related benefit that our page may index better in search engines such as Google.

Skinnable

Plone separates the content from the actual templates used to present the content, often called skins. The skins are written in the excellent HTML templating system called ZPT (Zope Page Templates), and a large amount of CSS (Cascading Style Sheets). With little knowledge of Plone, we can apply multiple skins, achieve multiple looks, and totally customize our website's appearance.

Registration and Personalization

Plone features a complete user registration system. Users register with a Plone site using their own username, password, and any other information we might want to add about the user. We can then personalize the whole user interface for that particular user. In addition, with add-ons, we can use information we already have about users, coming from many places, such as relational databases, LDAP (Lightweight Directory Access Protocol), Active Directory, and more.

Workflow and Security

Workflow controls the logic of processing content through the site. We can configure this logic through the WWW (World Wide Web) using graphical tools. Site administrators can make sites as complex or as simple as they like. For example, we can add notification tools such as sending e-mails or instant messages to users. For every item of content in a Plone site, we can set up access control lists to decide who has access to that item and how they will be able to interact with it. Will they be able to edit it, view it, or comment on it?

Extensible

Since Plone is free software, it can be easily altered. We can change and configure almost any aspect of Plone to suit our needs. Countless packages and tools for Plone provide a wide array of options for smaller sites and for large-scale enterprises. Repositories of free add-ons for Plone are available at http://www.plone.org. With development tools such as Archetypes, we can generate and alter Plone code easily through the Web or using UML (Unified Modeling Language) tools. Integration of Plone with enterprise solutions such as LDAP, Apache, Microsoft Internet Information Services (IIS), Macromedia Dreamweaver, and so on is possible.

Content Customization

Users of a Plone site can add all manner of content, but the data added is not limited or constrained. Plone developers can create their own content types so that almost any type of content can be managed.

Documentation

The Plone project maintains a huge collection of documentation, which is published under the Creative Commons license. The best starting place for the community documentation is at http://www.plone.org/documentation.

Community

one of the best things about Plone is the community of developers and companies that supports and develops Plone. With dozens of developers involved to some degree in the project around the world, it is almost always possible to find a Plone developer online who is willing and able to help. Alan Runyan, Alexander Limi, and Vidar Andersen started Plone. However, it quickly grew into a thriving open-source project as more developers became involved. The contributions from these developers form the Plone product that is now available.

Example Plone Sites

Many Plone sites exist — some are obvious because of their looks, and some are not. The following is just a small sample of the more diverse sites:

• Plone http://www.plone.org
• Plone Demo Site http://demo.plone.org
• Zope.org http://www.zope.org
• Liquidnet http://www.liquidnet.com
• Design Science Toys http://www.dstoys.com
• Give Kids the World http://www.gktw.org
• Propane http://www.usepropane.com
• Maestro Headquarters http://mars.telascience.org

More Plone sites are available at http://www.plone.org/about/sites, including sites that provide a quite different user interface. Without knowing about the development of these sites, it would in fact be hard to tell that these sites use Plone.

Plone Architecture - Plone's Components respectively its Foundation

Plone's architecture is actually quite simple on first sight (pretty much like an onion) — at its core is Python. Then, the next skin from the inside to the outside is Zope followed by the outermost skin which is Plone itself. At this point I feel pretty comfortable to answer two common questions that pop up a lot

1. The first one is Can Plone do <something>? The answer is Yes, if Python can then Plone can do it since ... (see graph below)
2. The second common question is Does Plone run on <some_operating_system>? The answer to that one is Yes, if that particular OS (Operating System) has support for Python then Plone will run on it. As a matter of fact, I am pretty much with DebianGNU/* only (aside from little journeys in the past and toying around with some other OSs every now and then) but Plone runs on Windows (XP and Vista), Linux (that includes most distributions e.g. Gentoo, Debian, etc.), all sorts of BSDs, the Apple OSs, etc.

   

However, if we take a closer look, it gets a little more detailed but then it looks pretty much the same as Zope's Architecture does — Plone just adds a few things ...

As can be seen, this is a stack-based graph to show how Plone fits into the equation. One particularly important thing to mention is the CMF (Content Management Framework) as an intermediate layer between Zope and Plone.

As a matter of fact, Plone itself is a so-called Product also known as Python module that runs on top of Zope. The difference between Plone and other Products (add-ons to Plone in order to extend Plone's functionality) from a programmers point of view is that those add-on products to Plone depend a lot on core Plone code and during run time, Plone is in control over those add-on products. However, from Zopes point of view, Plone and add-on Products to Plone are no different — they are all Python modules running on top of Zope.

Python

There is a dedicated page for it.

Zope

There is a dedicated page for it.

PCP (Plone Control Panel)

Aside from the ZMI (Zope Management Interface), there is also the Plone Management Interface or Plone Control Panel or sometimes even called Site Setup Page. However, all those terms determine the same thing — a web interface to interact with Plones core features.

The paragraphs below date back to times before we had the PCP (Plone Control Panel) — it just shows what happened, so that we got what we now enjoy ... Plone sites that have become easier to manage thanks to the PCP.

Motivation

The configuration information for a Plone site is scattered all over the ZMI and can be in unintuitive places. The current Plone setup form is too simple and unstructured to cope with the addition of many more options. The ZMI itself is not directly accessible TTP (Through The Plone) and so can lead to confusion with its different and slightly clunky interface, its inaccessibility and its unintuitive organisation.

The Plone Controller (seen in the Windows Installer version of Plone) relies on physical access to the machine Zope is running on. Since this is often impossible, a TTP system is the best solution.

A last motivation is to provide a modular configuration system so that products can supply their own configuration properties without destroying the user-interface or overriding core files in the CMF or Plone.

Proposal

Plone aims to be an easy-to-use CMS for Zope 2 and the CMF. Currently, however, most configuration has to be done through unintuitive places in the Zope Management Interface (ZMI) or a short, unstructured Plone setup form that duplicates a few of these properties. This proposal is for the addition of an extensible control panel system that would allow the creation of configuration applets to group together various properties logically and allow a more usable set of management tools.

This control panel would exist as a CMF tool implementing useful API functions and views and a configlet registry. Configlets would be implemented as standard Zope products, though instead of registering with Zope or CMF, they would register with the control panel tool.

Configlets would typically contain a set of configuration options and (perhaps) processes that are logically related. A number of configlets would come with the tool by default (such as skins, users, content types and syndication) but products will be able to register their own configlets for universal options.

Plone Products respectively Python Eggs

There is a dedicated page about it.

Storage

There is a dedicated page about it.

Install

This sections points out several possible ways to install Zope/Plone. Since I am only using DebianGNU/Linux I am not going to cover how to install Plone on any other OS than Debian. Which way to install Plone depends on various needs and last but not least personal likings. However, I am going to cover all possible ways:

• Manually
• The Debian way i.e. via APT (Advanced Packaging Tool). Those who might just play around a bit or setup a personal Wiki etc. might opt for this way since it is by far the least cumbersome way to install Plone.
• Doing a so-called Buildout (the preferred way)
• Using the UI (Unified Installer)

Manually installing Plone

To use Zope, we must first download and install its libraries and extensions, and then create an instance of the application server. The Zope Instance keeps track of installed applications (such as Plone), any custom configuration settings, and the object database — ZODB (Zope Object Database) — where all our content will live.

Downloading and Unpacking

 1  sa@pc1:~$ type ll
 2  ll is aliased to `ls -lh'
 3  sa@pc1:~$ cd work/git/ && mkdir plone_manually && ll
 4  total 8.0K
 5  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 15:18 plone_manually
 6  drwxr-xr-x 3 sa sa 4.0K 2008-02-28 12:54 ppd
 7  sa@pc1:~/work/git$ cd plone_manually/
 8  sa@pc1:~/work/git/plone_manually$ time curl -O http://www.zope.org/Products/Zope/2.11.0b1/Zope-2.11.0-b1.tgz
 9    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
10                                   Dload  Upload   Total   Spent    Left  Speed
11  100 6928k  100 6928k    0     0   456k      0  0:00:15  0:00:15 --:--:--  477k
12
13  real    0m15.182s
14  user    0m0.076s
15  sys     0m0.136s
16  sa@pc1:~/work/git/plone_manually$ ll
17  total 6.8M
18  -rw-r--r-- 1 sa sa 6.8M 2008-03-01 15:25 Zope-2.11.0-b1.tgz
19  sa@pc1:~/work/git/plone_manually$ tar xzf Zope-2.11.0-b1.tgz
20  sa@pc1:~/work/git/plone_manually$ rm Zope-2.11.0-b1.tgz && cd Zope-2.11.0-b1/
21  sa@pc1:~/work/git/plone_manually/Zope-2.11.0-b1$ ll
22  total 72K
23  -rwxr--r--  1 sa sa 7.0K 2007-12-28 12:14 configure
24  drwxr-xr-x  4 sa sa 4.0K 2007-12-28 12:18 doc
25  drwxr-xr-x  2 sa sa 4.0K 2007-12-28 12:13 Extensions
26  drwxr-xr-x  3 sa sa 4.0K 2007-12-28 12:22 inst
27  drwxr-xr-x  4 sa sa 4.0K 2007-12-28 12:14 lib
28  -rw-r--r--  1 sa sa  586 2007-12-28 12:14 log.ini
29  -rw-r--r--  1 sa sa 1.5K 2007-12-28 12:14 README.txt
30  -rw-r--r--  1 sa sa  21K 2007-12-28 12:14 setup.py
31  drwxr-xr-x 10 sa sa 4.0K 2007-12-28 12:14 skel
32  -rw-r--r--  1 sa sa 3.4K 2007-12-28 12:14 test.py
33  drwxr-xr-x  3 sa sa 4.0K 2007-12-28 12:19 utilities
34  -rw-r--r--  1 sa sa 2.2K 2007-12-28 12:14 ZopePublicLicense.txt
35  sa@pc1:~/work/git/plone_manually/Zope-2.11.0-b1$

Lines 1 and 2 just show an alias from my .bashrc. With line 3 I issued a command sequence to change the directory, create our new directory plone_manually and finally list the directory contents. After changing into plone_manually in line 7, I downloaded the tarball in lines 8 to 15. The time curl -O <some_url> from line 8 could have also been wget <some_url> — it is just I was curious how long it might take plus I prefer curl over wget.

Line 19 untars and decrompresses the tarball. Line 20 removes the tarball plus changes into the just created directory which contents can be seen in lines 23 to 24 after issuing the command ll in line 21.

Line 30 shows there is a file called setup.py. If we take a look at its contents, e.g. by using less setup.py, we figure how to build Zope. I used Dired to show the contents but that is another story ;-]

Creating a Zope Installation

36  sa@pc1:~/work/git/plone_manually/Zope-2.11.0-b1$ time python setup.py build_ext -i
37  running build_ext
38  creating zope.proxy
39  copying zope/proxy/proxy.h -> zope.proxy
40  building 'AccessControl.cAccessControl' extension
41  creating build
42  creating build/temp.linux-i686-2.4
43  creating build/temp.linux-i686-2.4/AccessControl
44
45  [skipping a lot of lines ...]
46
47  gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DEXCLUDE_INTSET_SUPPORT -I. -I/usr/include/python2.4 -c BTrees/_LFBTree.c -o build/temp.linux-i686-2.4/BTrees/_LFBTree.o
48  gcc -pthread -shared build/temp.linux-i686-2.4/BTrees/_LFBTree.o -o BTrees/_LFBTree.so
49  running build_ext
50
51  real        1m36.155s
52  user        0m50.459s
53  sys 0m3.692s
54  sa@pc1:~/work/git/plone_manually/Zope-2.11.0-b1$

In line 36 we issue the command to create (build) a Zope installation (see Glossary) — yes, I used time again to see how long it takes (lines 51). Actually, there is a lot more ouput than just 53 - 36 lines but I skipped the majority of them since they are not of interests.

Creating a Zope Instance

55  sa@pc1:~/work/git/plone_manually/Zope-2.11.0-b1$ cd ..
56  sa@pc1:~/work/git/plone_manually$ mkdir instances
57  sa@pc1:~/work/git/plone_manually$ ll
58  total 8.0K
59  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 20:18 instances
60  drwxr-xr-x 8 sa sa 4.0K 2007-12-28 12:22 Zope-2.11.0-b1
61  sa@pc1:~/work/git/plone_manually$ cd instances/
62  sa@pc1:~/work/git/plone_manually/instances$ ../Zope-2.11.0-b1/utilities/mkzopeinstance.py -d sunos_testinstance
63  Please choose a username and password for the initial user.
64  These will be the credentials you use to initially manage
65  your new Zope instance.
66
67  Username: admin
68  Password:
69  Verify password:
70  sa@pc1:~/work/git/plone_manually/instances$ ll
71  total 4.0K
72  drwxr-xr-x 10 sa sa 4.0K 2008-03-01 20:20 sunos_testinstance
73  sa@pc1:~/work/git/plone_manually/instances$ cd sunos_testinstance/
74  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$

Now that we have a Zope installation we need to create a Zope Instance (again, see Glossary for further information). In line 55 we move one level up, create a new directory in line 56, use ll to list the directory contents in line 57 and finally change into ../instances in line 61. ../instances is where our Zope Instances are going to live from now on.

So, we create a Zope Instance in line 62. As can be seen, we use the script mkzopeinstance.py from ../utilities. In the course of creating a new instance, we are promted for a username (line 67) and a password (lines 68 and 69). Finally, we change into the directory of our just created Zope Instance called sunos_testinstance.

Choosing a HTTP Port for the Zope Instance(s)

Since I have a few other Zope Installations and thus many Zope Instances running on my machine I need to ensure they do not step on each others toes. Since I already installed a Plone site the Debian way before, I need to ensure that our manually installed Zope binds to another port than 8080 which happens to be Zopes standard HTTP (Hypertext Transfer Protocol) port. Again, the Zope Instance I installed by issuing apt-get install plone3-site binds to port 8080 so we need to let our manually installed Zope Instance bind to another port.

If we take a look at what port numbers might suit us well without using any of the occupied ones, it might turn out a port number x in the range of 49999 < x < 2^16 might suit us well — especially since we just need to access the Zope Instance on our local machine anyways ... I tend to start at 50000 and then increase by 100 for any Zope Instance I create. That way I got plenty of space to stick Plone Instances onto every Zope Instance I create. That might sound a litte odd but I like to have a plan laid out before I do stuff ... I am the kind of person who does not even go to the toilet without a plan ;-]

The way how to change the port number from 8080 to 50000 is to edit the configuration file for that particular Zope Instance which is ~/work/git/plone_manually/instances/sunos_testinstance/etc/zope.conf in our current case. All we have to do is to search for address 8080 and change it to what can be seen below.

[skipping a lot of lines ...]

<http-server>
  # valid keys are "address" and "force-connection-close"
  address 50000

  # force-connection-close on
  #
  # You can also use the WSGI interface between ZServer and ZPublisher:
  # use-wsgi on
  #
  # To defer the opening of the HTTP socket until the end of the
  # startup phase:
  # fast_listen false
  #
</http-server>

[skipping a lot of lines ...]

Starting the Zope Instance / Having fun with zopectl

75  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ ./bin/zopectl
76  program: /home/sa/work/git/plone_manually/instances/sunos_testinstance/bin/runzope
77  daemon manager not running
78  zopectl> help
79
80  Documented commands (type help <topic>):
81  ========================================
82  EOF      fg          kill       quit     run    start   test
83  adduser  foreground  logreopen  reload   shell  status  wait
84  debug    help        logtail    restart  show   stop
85
86  Undocumented commands:
87  ======================
88  reopen_transcript
89
90  zopectl> help fg
91  foreground -- Run the program in the forground.
92  fg -- an alias for foreground.
93  zopectl> status
94  daemon manager not running
95  zopectl> start
96  . daemon process started, pid=17187
97  zopectl> status
98  program running; pid=17187
99  zopectl> help test
100  test [args]+ -- run unit / functional tests.
101                  See $ZOPE_HOME/bin/test.py --help for syntax.
102  zopectl> test
103  Running tests via: /usr/bin/python2.4 /home/sa/work/git/plone_manually/Zope-2.11.0-b1/test.py -v --config-file /home/sa/work/git/plone_manually/instances/sunos_testinstance/etc/zope.conf
104  Parsing /home/sa/work/git/plone_manually/instances/sunos_testinstance/etc/zope.conf
105  Running tests at level 1
106  Total: 0 tests, 0 failures, 0 errors in 0.000 seconds.
107  zopectl> quit
108  daemon process and daemon manager still running

The command issued in line 75 brings up zopectl — it is a management tool that allows to manage a particular Zope Instance. Lines 76 to 108 speak for themselves. However, line 95 is of special interest since it is here where we actually start our Zope Instance. Also, line 107 is quite interesting — although we quit from zopectl, the just started Zope Instance keeps on running as we can see in line 111 (just compare the PIDs in line 111 and 96). Lines 109 to 112 also show what I was talking before — currently I got two Zope instances running on my system — one has the PID 3135 and the other one is our just created one with 17187 as its PID.

109  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ psa zope.conf | grep -v grep
110  zope      3135  0.0  5.8 154804 60972 ?        Sl   08:30   0:36 /usr/bin/python2.4 /usr/lib/zope2.10/lib/python/Zope2/Startup/run.py -C /var/lib/zope2.10/instance/plone-site/etc/zope.conf
111  sa       17187  1.1  3.4  72728 36124 ?        Sl   21:37   0:06 /usr/bin/python2.4 /home/sa/work/git/plone_manually/Zope-2.11.0-b1/lib/python/Zope2/Startup/run.py -C /home/sa/work/git/plone_manually/instances/sunos_testinstance/etc/zope.conf
112  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$

Entering the ZMI with some Web Browser

And last but not least, we fire up Iceweasel and take a look at our just created Zope Instance. Note the URL (Uniform Resource Locator) i.e. the port number which is exactly what we have set it to namely 50000.

At this point you might compare this with the URL further down i.e. the Zope Instance we installed the Debian way. The alerted reader might have also already noticed all the Information shown in the ZMI Control Panel e.g. Zope version number, file system path, etc.

Now, you might want to put a Plone Installation in place i.e. you want to create a Plone Instance so you can actually start tinkering around with Plone TTW (Through-The-Web). Well, currently that will not work ... Just go the the Portal root again (click Root folder) and try to add a Plone Site from the pull-down box in the right corner ... did you find Plone Site? ;-]

There can be no choice for Plone Site if there is no Plone Installation in place so far — how to download and put the Plone code into place so we can use the drop-down list in the ZMI to add a Plone Instance follows below ...

Get Plone and set it up

To be able to use Plone, we now need to install its products and packages. Therefore, we are going to stop Zope, download the Plone tarball from http://plone.org/download, and extract it into sunos_testinstance. This puts various directories into the Products folder. For example, sunos_testinstance/Products/CMFPlone and sunos_testinstance/Products/ATContentTypes among other directories.

113  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ ./bin/zopectl
114  program: /home/sa/work/git/plone_manually/instances/sunos_testinstance/bin/runzope
115  program running; pid=17187
116  zopectl> status
117  program running; pid=17187
118  zopectl> stop
119  .
120  Daemon manager not running.
121  zopectl> status
122  daemon manager not running
123  zopectl> quit
124  daemon manager not running
125  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$

In line 113 we fire up zopectl again — remember, we want to stop our former manually installed Zope Instance ... Stopping the instance actually takes place in line 118 which we proof with lines 121 and 122.

At this point, there is the Suno way to do it and then there is the other way — other like what ordinary folks whould do ... I am telling you about both ;-]

1. I guess what most folks might do is to use their web browser and go to http://plone.org/download. Then they would probably move their mouse pointer to Get Plone for all platforms, click the link and after a new window poped up this person would specify to download the tarball and afterwards extract it to ../sunos_testinstance.
2. Now here is what a person does who utterly disklikes computer mice and happens to be a GNU Emacs fan boy. Suno is within GNU Emacs then he hits f10 W since that is a keybinding (those can be found in my .emacs) that fires up w3m. Then follows g and a C-y with the URL from above. Then a few TAB and finally point is on the line stating Get Plone for all platforms. Next Suno hits f10 c u to imbibe the URL which currently happens to be https://launchpad.net/plone/3.0/3.0.6/+download/Plone-3.0.6.tar.gz. Finally, Suno would yet again use curl to download Plone as he did above.

However way the Plone tarball makes it onto ones computer, it need be extracted etc.

126  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ tar xzf Plone-3.0.6.tar.gz
127  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ ll
128  total 13M
129  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 20:20 bin
130  drwxr-xr-x 3 sa sa 4.0K 2008-03-01 21:31 etc
131  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 20:20 Extensions
132  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 20:20 import
133  drwxr-xr-x 3 sa sa 4.0K 2008-03-01 20:20 lib
134  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 21:38 log
135  drwxr-xr-x 4 sa sa 4.0K 2008-02-15 16:15 Plone-3.0.6
136  -rw-r--r-- 1 sa sa  13M 2008-02-15 16:42 Plone-3.0.6.tar.gz
137  drwxr-xr-x 2 sa sa 4.0K 2008-03-01 20:20 Products
138  -rw-r--r-- 1 sa sa  481 2008-03-01 20:20 README.txt
139  drwxr-xr-x 2 sa sa 4.0K 2008-03-02 11:15 var
140  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$

In line 126 I extract Plone which we just downloaded. The result can be seen in line 135. Line 136 happens to be the just downloaded tarball. Actually all we need to know is written down in ../sunos_testinstance/Plone-3.0.6/INSTALL.txt i.e. $INSTANCE_HOME/Plone-3.0.6/INSTALL.txt

At this point I assume the reader has read the Glossary and knows about $SOFTWARE_HOME and $INSTANCE_HOME. The meaning and implications of these terms need to be known. If you do not know exactly what they are and why they are important to know, please go make youself smart and return afterwards.

In case someone is still confused or uncertain about the enviroment variables even after studying the Glossary ... well, luckily, there is M-x super-suno-mode which brings out the SS (Super Suno), buzzing around and dropping good advices at the confused ;-]

141  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ cat bin/zopectl
142  #! /bin/sh
143
144  PYTHON="/usr/bin/python2.4"
145  ZOPE_HOME="/home/sa/work/git/plone_manually/Zope-2.11.0-b1"
146  INSTANCE_HOME="/home/sa/work/git/plone_manually/instances/sunos_testinstance"
147  CONFIG_FILE="/home/sa/work/git/plone_manually/instances/sunos_testinstance/etc/zope.conf"
148  SOFTWARE_HOME="/home/sa/work/git/plone_manually/Zope-2.11.0-b1/lib/python"
149  PYTHONPATH="$SOFTWARE_HOME:$PYTHONPATH"
150  export PYTHONPATH INSTANCE_HOME SOFTWARE_HOME
151
152  ZDCTL="$SOFTWARE_HOME/Zope2/Startup/zopectl.py"
153
154  exec "$PYTHON" "$ZDCTL" -C "$CONFIG_FILE" "$@"
155  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$

By the time we created our new Zope Instance (line 62) the file zopectl was created as well. And now, look what it got for us e.g. line 146 or line 148 etc.

Replacing $INSTANCE_HOME/lib and $INSTANCE_HOME/Products

156  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ rm Plone-3.0.6.tar.gz
157  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ rm -r lib/ Products/ && mv Plone-3.0.6/lib/ . && mv Plone-3.0.6/Products/ .
158  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$ ./bin/zopectl
159  program: /home/sa/work/git/plone_manually/instances/sunos_testinstance/bin/runzope
160  daemon manager not running
161  zopectl> start
162  . daemon process started, pid=18224
163  zopectl> quit
164  daemon process and daemon manager still running
165  sa@pc1:~/work/git/plone_manually/instances/sunos_testinstance$

In line 156 we remove the tarball since we do not need it anymore. The important line however is line 157 — we replace $INSTANCE_HOME/lib and $INSTANCE_HOME/Products with $INSTANCE_HOME/Plone-3.0.6/lib and $INSTANCE_HOME/Plone-3.0.6/Products. Then we fire up zopectl again, start our Zope Instance in line 161 and 162 and quit again in line 163.

Note 1

Zope will scan $INSTANCE_HOME/Products on startup for any old-style products to initialize and load. The products in $INSTANCE_HOME/Products are added to (and could override) those found in $SOFTWARE_HOME/Products.

Note 2

When the application server starts up, the $INSTANCE_HOME/lib/python directory is added to the $PYTHONPATH, making additional plain Python packages available to Zope. However, such packages are not automatically scanned and loaded as products in the Products folder are; they are merely available for other packages to import.

Note 3

The $INSTANCE_HOME/log directory is the default location of Zope's log files. The file event.log contains most error and debugging messages. Z2.log is a low-level access log. Logging is configured from $INSTANCE_HOME/etc/zope.conf.

Note 4

By default, the entire contents of the ZODB (Zope Object Database) are stored in a single file, called Data.fs. This can be found in $INSTANCE_HOME/var. To back up our database, we simply have to make a copy of this file.

Finally, adding a new Plone Instance

Now we can add a new Plone Instance from the drop-down list. The images below are in order, picturing every step until we finally got our new Plone Instance. We are done, manually installing Zope/Plone!

The Debian Way

I can only recommend this way although also the UI (Unified Installer) works great and is pretty user-friendly. However, I prefer to stick to Debian's APT (Advanced Packaging Tool) whenever possible.

Installing as Usual

sa@pc1:~$ cat /etc/debian_version
lenny/sid
sa@pc1:~$ date -u
Sat Dec 15 17:43:22 UTC 2007
sa@pc1:~$ su
Password:
pc1:/home/sa#
pc1:/home/sa# apt-get install plone3-site
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  poppler-utils python-docutils python-openid python-roman zope-cachefu zope-common zope-externaleditor zope-plone3 zope2.10
Suggested packages:
  squid varnish python-unit zope-book zope-devguide
Recommended packages:
  zope-linguaplone
The following packages will be REMOVED
  xpdf-utils
The following NEW packages will be installed
  plone3-site poppler-utils python-docutils python-openid python-roman zope-cachefu zope-common zope-externaleditor zope-plone3 zope2.10
0 upgraded, 10 newly installed, 1 to remove and 13 not upgraded.
Need to get 22.0MB of archives.
After unpacking 129MB of additional disk space will be used.
Do you want to continue [Y/n]? y

During the installation of plone3-site and its dependencies the package xpdf-utils has been removed — since I am with sid (still in development) such things happen sometimes because of some wrong dependencies etc. However, this fact has nothing to do with this Plone installation and I reinstalled xpdf-utils later again anyways so ...

Get: 1 ftp://ftp.de.debian.org unstable/main zope-common 0.5.38 [41.2kB]
Get: 2 ftp://ftp.de.debian.org unstable/main zope2.10 2.10.5-2 [7143kB]
Get: 3 ftp://ftp.de.debian.org unstable/main poppler-utils 0.6.2-1 [176kB]
Get: 4 ftp://ftp.de.debian.org unstable/main python-roman 0.4-5 [12.3kB]
Get: 5 ftp://ftp.de.debian.org unstable/main python-docutils 0.4-5 [1541kB]
Get: 6 ftp://ftp.de.debian.org unstable/main zope-externaleditor 0.9.3-2 [49.0kB]
Get: 7 ftp://ftp.de.debian.org unstable/main zope-plone3 3.0.4-1 [12.7MB]
Get: 8 ftp://ftp.de.debian.org unstable/main plone3-site 3.0.4-1 [10.9kB]
Get: 9 ftp://ftp.de.debian.org unstable/main python-openid 2.0.2-1 [275kB]
Get: 10 ftp://ftp.de.debian.org unstable/main zope-cachefu 1.1-1 [35.2kB]
Fetched 22.0MB in 1m5s (338kB/s)
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Preconfiguring packages ...
(Reading database ... 165401 files and directories currently installed.)
Removing xpdf-utils ...
Selecting previously deselected package zope-common.
(Reading database ... 165391 files and directories currently installed.)
Unpacking zope-common (from .../zope-common_0.5.38_all.deb) ...
Setting up zope-common (0.5.38) ...
Selecting previously deselected package zope2.10.
(Reading database ... 165400 files and directories currently installed.)
Unpacking zope2.10 (from .../zope2.10_2.10.5-2_i386.deb) ...
Selecting previously deselected package poppler-utils.
Unpacking poppler-utils (from .../poppler-utils_0.6.2-1_i386.deb) ...
Replacing files in old package xpdf-reader ...
Selecting previously deselected package python-roman.
Unpacking python-roman (from .../python-roman_0.4-5_all.deb) ...
Selecting previously deselected package python-docutils.
Unpacking python-docutils (from .../python-docutils_0.4-5_all.deb) ...
Selecting previously deselected package zope-externaleditor.
Unpacking zope-externaleditor (from .../zope-externaleditor_0.9.3-2_all.deb) ...
Selecting previously deselected package zope-plone3.
Unpacking zope-plone3 (from .../zope-plone3_3.0.4-1_all.deb) ...
Selecting previously deselected package plone3-site.
Unpacking plone3-site (from .../plone3-site_3.0.4-1_all.deb) ...
Selecting previously deselected package python-openid.
Unpacking python-openid (from .../python-openid_2.0.2-1_all.deb) ...
Selecting previously deselected package zope-cachefu.
Unpacking zope-cachefu (from .../zope-cachefu_1.1-1_all.deb) ...
Setting up zope2.10 (2.10.5-2) ...
Zope2.10: no instances found.
Setting up poppler-utils (0.6.2-1) ...
Setting up python-roman (0.4-5) ...
Setting up python-docutils (0.4-5) ...
Setting up zope-externaleditor (0.9.3-2) ...
Setting up zope-plone3 (3.0.4-1) ...
Setting up plone3-site (3.0.4-1) ...
. daemon process started, pid=2512
Setting up python-openid (2.0.2-1) ...
Setting up zope-cachefu (1.1-1) ...
pc1:/home/sa# exit
exit
sa@pc1:~$

Well, that is a lot of output that we got here but more important are the images below — those are ncurses interfaces that show up during the above installation process. Plone as well as Zope needs to ask us a few things during the installation process in order to set up a few things like the user name for the Zope Instance plone-site as well as the password and a few other things. The three images below are in chronological order but they are just the most important three i.e. there are a few more that show up during the installation.

Using the ZMI (Zope Management Interface)

After we installed the package plone3-site and its dependencies, all that is needed is that we use the ZMI — via the web browser — to create a new Plone Instance. As usual, this is described in /usr/share/doc/plone3-site/README.Debian.

We need to pick Plone Site from the scroll down menu in the right corner and click Add which then starts the process of creating a new, virgin Plone Instance.

The Result - a ready to use Plone Instance

After we created a new Plone Instance, the result can be seen below — this is a pristine Plone site without anything configured or some content being added or edited.

Note the URL (Uniform Resource Locator). This URL, especially the ../sunos_example_site, is what we get when we specify the ID (Identifier) while we set up the new Plone Instance with the ZMI in the preceding step. So, we just put http://localhost:8081/sunos_example_site in the address line of our web browser and our Plone site appears. The left image below shows Plone right after we logged as manager (site admin). The right image shows Plone's Welcome Page.

Essentially, we are done i.e. we now have a fully functional Plone site. The next step would be to set up the Email part and then we would start customizing (layout, workflow, buildout, etc.) our Plone site.

Buildout

How annoying is it to deploy an application? How prone to errors due to the sheer repetitiveness of the common deployment? Buildouts to the rescue! What is a buildout? How does it work?

A buildout is an automated set of steps for creating a deployment environment (something else crosses the mind ...). Literally this could mean one little application, or it could be several (e.g. Zope/Plone + Apache + Varnish) and they would be setup to talk to each other.

zc.buildout is one solution to the problem. The idea that a deployment consists of parts is something that can be explained to anyone, for example:

• A random web application needs a webserver, some kind of storage backend, the application code and some preexisting data e.g. Apache MySQL, Application meta data, Application-data or a
• fully Zope-based solution: Apache, Zope, ZEO, Plone, mywebsite meta data, mywebsite-data

Prerequisites

We need to have some prerequisites in place in order to create/use buildouts. I opted to install the Debian packages instead of building from scratch. The reason I did so is simplicity in the process. Every of the below packages gets upgraded anytime something like aptitude safe-upgrade is issued. Aside from all those technical prerequisites one needs to know about the Glossary as well.

Python

We need the Python Interpreter. Since we are with Debian, we just install the Debian package — I already have it installed

sa@pc1:~$ type dpl
dpl is aliased to `dpkg -l'
sa@pc1:~$ dpl python | grep ^ii
ii  python         2.4.4-6        An interactive high-level object-oriented la
sa@pc1:~$

PIL (Python Imaging Library)

We also need the PIL. Again, already installed on my machine

sa@pc1:~$ dpl python-ima* | grep ^ii
ii  python-imaging 1.1.6-2        Python Imaging Library
sa@pc1:~$

Elementtree

Then we need elementtree, an XML (Extensible Markup Language) processing library

sa@pc1:~$ dpl python-elem* | grep ^ii
ii  python-element 1.2.6-11       Light-weight toolkit for XML processing
sa@pc1:~$

Editor

An editor e.g. GNU Emacs (yes, one can actually also edit text/code with Emacs ;-]). Emacs provides all we need e.g. python-mode, css-mode=, xml-mode, etc. Emacs also has outstanding frontends for SVN (Subversion) and GIT (= a random three-letter combination) which eases things a lot plus it gives you a real speed-boost.

Shell

A shell e.g. Bash (Bourne again shell). Bash is the standard shell with Debian.

SVN (Subversion) Client

A SVN client

sa@pc1:~$ dpl subver* | grep ^ii
ii  subversion     1.4.6dfsg1-1   Advanced version control system
ii  subversion-too 1.4.6dfsg1-1   Assorted tools related to Subversion
sa@pc1:~$

C Compiler

A C compiler e.g.

sa@pc1:~$ dpl gcc-4.3* | grep ^ii
ii  gcc-4.3-base   4.3-20080227-1 The GNU Compiler Collection (base package)
sa@pc1:~$

Python Eggs, setuptools and easy_install

Python eggs are not specific to Zope or Plone. However, since Zope has only recently become egg-aware, they are new to many developers. Traditionally, almost all Zope add-on products, including Plone, have been distributed as Zope products. These are fairly easy to manage — we typically copy or symlink them into $INSTANCE_HOME/Products. Zope will scan this directory on startup, taking care of any product initialization and registration.

However, code inside products is nearly impossible to re-use outside Zope because Zope does magic things with the Products.* namespace. Further, the namespace quickly becomes crowded, which deters developers from breaking up functionality into smaller, more re-usable and better-isolated packages.

The Zope 3 philosophy is to be as close to plain Python as possible, and that means distributing code as such small packages. So long as its dependencies are in order, any package should be able to run in any environment. For example, the zope.interface package is used by the Twisted project, which is not otherwise dependent on Zope. This design goal has made it much easier to adopt Zope 3 packages in Zope 2 and Plone.

Starting with Plone 3, the Plone community has also embraced plain Python packages and uses them wherever possible. A number of packages, such as plone.memoize and plone.portlets are generic enough to work without any dependencies on the rest of Plone. Others are more specific to Plone and live in the plone.app namespace, such as plone.app.layout and plone.app.portlets, the latter containing Plone-centric extensions to the generic plone.portlets package.

All that is needed to use these packages is a sensible $PYTHONPATH. Thus, we can copy or link packages into $INSTANCE_HOME/lib/python/plone/memoize, $INSTANCE_HOME/lib/python/plone/portlets, $INSTANCE_HOME/lib/python/plone/app/portlets, and so forth for Zope to find them. This works, but it is pretty tedious when there are many packages, and it can become outright confusing when there are nested namespaces being used by multiple packages.

Luckily, other Python programmers have solved these problems, first creating distutils, then its successor setuptools and with setuptools, Python eggs. To install setuptools on DebianGNU/Linux just issue apt-get install python-setuptools respectively make use of aptitude.

sa@pc1:~$ afl python-setuptools | grep bin/
python-setuptools: usr/bin/easy_install
python-setuptools: usr/bin/easy_install-2.4
python-setuptools: usr/bin/easy_install-2.5
sa@pc1:~$

For afl please take a look at my aliases in my .bashrc. As we can see, setuptools contains easy_install (see Glossary for more information). The image below just how I use Dired to for example read /usr/share/doc/python-setuptools/setuptools.txt.gz.

zc.buildout - Automating the Build Process

Creating a Zope instance and copying or linking packages into $INSTANCE_HOME/lib/python using setuptools is a piece of cake. However, this approach has a few limitations:

• The process is manual and cumbersome to repeat across multiple environments.
• Multiple developers working on the same project may share the code in eggs and products by using a SCM (Software Configuration Management) version control system such as Subversion or even better, GIT. However, each developer would be responsible for setting up their development environment, and subtle differences may cause problems that are difficult to debug.
• Packages are installed manually, and so cannot benefit from setuptool's ability to manage dependencies and updates.
• Complex deployments that include other libraries, non-python code, or specific configurations will also need to be taken care of manually.

Luckily, there are tools to make deployment easier. zc.buildout is one such tool, written largely by Zope founder Jim Fulton at Zope Corporation. It makes heavy use of eggs and setuptools and is very flexible in supporting a wide range of deployment scenarios.

Central to a buildout (i.e. what zc.buildout is managing for us) is a file called buildout.cfg. This specifies various options, including a list of parts, which will be executed when the buildout is run. Each part is associated with a recipe (a named egg), which will be called upon to parse the options provided, and perform a particular task, such as building a Zope instance, downloading Plone, etc.

A project-specific buildout directory can be checked into a SCM (Software Configuration Management) system and shared among developers. It can also be used to replicate a particular environment across different servers with a high degree of predictability. By writing custom recipes, we can make zc.buildout do almost anything. Writing a recipe is not particularly hard, and there are plenty of examples and generic solutions available.

Picturing the Buildout Process

   +--------------------+
   |                    |
   |   Paste Script     |
   |                    |
   +--------------------+
             |
             | 0.
             |
             v
+----------------------+
|                      |                +--------------------+
|  ZopeSkel            |                |                    |
|  (templates)         |                |   Python Eggs      |
|                      |                |                    |
+----------------------+                +--------------------+
          |                               |
          | 1.                 2.         |
          |               +---------------+
          |               |                         +---------------------+
          +----------+    |           3.            |                     |
                     |    |     +-------------------|   setuptools        |
                     |    |     |                   |    - easy_install   |
                     v    v     v                   |    - alias          |
               --------------------------           |    - etc.           |
              (      buildout.cfg        )          +---------------------+
               --------------------------
                            |
                            |
                            | 4.
                            |
                            |
                            v
                        ---------
                      -/         \-
                    -/             \-
                   /                 \
                  /                   \         +----------------------+
                 /                     \        |                      |
                 |                     |  5.    | A new                |
                 | zc.buildout process |------> | Plone Instance       |
                 |                     |        |                      |
                 \                     /        +----------------------+
                  \                   /
                   \                 /
                    -\             /-
                      -\         /-
                        ---------

1. PasteScript is a library for creating Python project templates that ZopeSkel heavily relies on.
2. ZopeSkel is a collection of skeletons for quickstarting Zope projects. It adds to the list of available PasteScript templates a few that are useful for quickly starting Zope projects that have a setuptools-ready file layout.
3. Python Eggs are used by the buildout process (i.e. zc.buildout).
4. setuptools is used by the buildout process too.
5. Central to a buildout (i.e. what zc.buildout is managing for us) is a file called buildout.cfg. This specifies various options, including a list of parts, which will be executed when the buildout is run.
6. After the buildout process has finished we got a brand-new Plone Instance, ready to enter it TTW (Through-The-Web).

Paste Script and ZopeSkel

To create the buildout.cfg file and some necessary boilerplate, we will make use of Paste Script, a tool for creating project skeletons from templates. Later, we will also use Paste Script to create new packages following standard conventions.

Paste Script is an extensible system with which other packages (or rather, Python Eggs) can register new templates (using entry points). For Zope and Plone development, the ZopeSkel (see Glossary for more information) package provides several useful templates.

Get to grips with the whole Buildout Shebang

We already have easy_install on our system since we installed python-setuptools. What we need next is Paster Script and ZopeSkel. From now on we go with the Python Egg/Package management mechanism — as opposed to continuing with Debian Packages and therefore APT (Advanced Packaging Tool). There is absolutely nothing wrong about this decision and it is of course the recommended way in case we are doing a Buildout (which is exactly what we are going to do now).

I have learned the hard way that it is best to use some sort of high-level software management mechanism whenever possible — instead of dealing with the source/build/get_confused/screw_things_up/waste_time ways of managing software. In short: If it is not APT that I use then it is something like the Buildout mechanism. I only thinker around with source from scratch for software I develop on my own, maintain for Debian, or that happens to be some bleeding etch stuff I use for own e.g. some Emacs code when it is not packaged and/or even Debians experimental branch is not up-to-date enough.

Making sure all Prerequisites are in Place

1  sa@pc1:~$ type dpl
2  dpl is aliased to `dpkg -l'
3  sa@pc1:~/work/git$ dpl python-* | egrep chee*\|all-dev
4  ii  python-all-dev 2.4.4-6        Package depending on all supported Python de
5  ii  python-cheetah 2.0.1-2        text-based template engine and Python code g
6  sa@pc1:~/work/git$

Aside from what we installed above, there is a little more that we should have in place (lines 4 and 5). If not yet installed (I have as can be seen i.e. ii) then now is the time.

A closer look at easy_install 's Options

 7  sa@pc1:~/work/git$ easy_install --help
 8  Global options:
 9    --verbose (-v)  run verbosely (default)
10    --quiet (-q)    run quietly (turns verbosity off)
11    --dry-run (-n)  don't actually do anything
12    --help (-h)     show detailed help message
13
14  Options for 'easy_install' command:
15    --prefix                       installation prefix
16    --zip-ok (-z)                  install package as a zipfile
17    --multi-version (-m)           make apps have to require() a version
18    --upgrade (-U)                 force upgrade (searches PyPI for latest
19                                   versions)
20    --install-dir (-d)             install package to DIR
21    --script-dir (-s)              install scripts to DIR
22    --exclude-scripts (-x)         Don't install scripts
23    --always-copy (-a)             Copy all needed packages to install dir
24    --index-url (-i)               base URL of Python Package Index
25    --find-links (-f)              additional URL(s) to search for packages
26    --delete-conflicting (-D)      no longer needed; don't use this
27    --ignore-conflicts-at-my-risk  no longer needed; don't use this
28    --build-directory (-b)         download/extract/build in DIR; keep the
29                                   results
30    --optimize (-O)                also compile with optimization: -O1 for
31                                   "python -O", -O2 for "python -OO", and -O0 to
32                                   disable [default: -O0]
33    --record                       filename in which to record list of installed
34                                   files
35    --always-unzip (-Z)            don't install as a zipfile, no matter what
36    --site-dirs (-S)               list of directories where .pth files work
37    --editable (-e)                Install specified packages in editable form
38    --no-deps (-N)                 don't install dependencies
39    --allow-hosts (-H)             pattern(s) that hostnames must match
40    --local-snapshots-ok (-l)      allow building eggs from local checkouts
41
42  usage: easy_install [options] requirement_or_url ...
43     or: easy_install --help
44
45  sa@pc1:~/work/git$

Lines 7 to 45 just show what options are available with easy_install. It is generally a good idea to always read this things — a) it is way less time consuming than reading a manual to the command in question and b) you get a feeling about what is possible.

Installing ZopeSkel

46  sa@pc1:~/work/git$ su
47  Password:
48  pc1:/home/sa/work/git# easy_install ZopeSkel
49  Searching for ZopeSkel
50  Reading http://pypi.python.org/simple/ZopeSkel/
51  Best match: ZopeSkel 1.7
52  Downloading http://pypi.python.org/packages/2.4/Z/ZopeSkel/ZopeSkel-1.7-py2.4.egg#md5=1a7a6ad88313b95173723b70659fbd65
53  Processing ZopeSkel-1.7-py2.4.egg
54  creating /usr/lib/python2.4/site-packages/ZopeSkel-1.7-py2.4.egg
55  Extracting ZopeSkel-1.7-py2.4.egg to /usr/lib/python2.4/site-packages
56  Adding ZopeSkel 1.7 to easy-install.pth file
57
58  Installed /usr/lib/python2.4/site-packages/ZopeSkel-1.7-py2.4.egg
59  Processing dependencies for ZopeSkel
60  Searching for Cheetah
61  Reading http://pypi.python.org/simple/Cheetah/
62  Reading http://www.CheetahTemplate.org/
63  Reading http://sourceforge.net/project/showfiles.php?group_id=28961
64  Best match: Cheetah 2.0.1
65  Downloading http://downloads.sourceforge.net/cheetahtemplate/Cheetah-2.0.1.tar.gz?download
66  Processing Cheetah-2.0.1.tar.gz
67  Running Cheetah-2.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-x3LGlr/Cheetah-2.0.1/egg-dist-tmp-k57ww2
68
69  [skipping a lot of lines ...]
70
71  Installed /usr/lib/python2.4/site-packages/Paste-1.6-py2.4.egg
72  Finished processing dependencies for ZopeSkel

Then, in line 48, we actually issue the command to install ZopeSkel. This takes a while — I skipped a lot of lines from the screendump as I indicated in line 69. During the installation of ZopeSkel, Paste Script got installed as well since there is a dependency in ZopeSkel that requires Paste Script — both are needed for the Buildout later on i.e. running zc.buildout.

A closer look at paster 's Options

73  pc1:/home/sa/work/git# exit
74  exit
75  sa@pc1:~/work/git$ paster --help
76  usage: paster [paster_options] COMMAND [command_options]
77
78  options:
79    --version         show program's version number and exit
80    --plugin=PLUGINS  Add a plugin to the list of commands (plugins are Egg
81                      specs; will also require() the Egg)
82    -h, --help        Show this help message
83
84  Commands:
85    create       Create the file layout for a Python distribution
86    help         Display help
87    make-config  Install a package and create a fresh config file/directory
88    points       Show information about entry points
89    post         Run a request for the described application
90    request      Run a request for the described application
91    serve        Serve the described application
92    setup-app    Setup an application, given a config file
93
94  sa@pc1:~/work/git$

Then, in lines 75 to 92, we take a look at the paster command — for the same reason as we took a closer look at easy_install.

Creating the buildout.cfg File

95  sa@pc1:~/work/git$ paster create -t plone3_buildout plone_buildout
96  Selected and implied templates:
97    ZopeSkel#plone3_buildout  A buildout for Plone 3 projects
98
99  Variables:
100    egg:      plone_buildout
101    package:  plone_buildout
102    project:  plone_buildout
103  Enter zope2_install (Path to Zope 2 installation; leave blank to fetch one) ['']:
104  Enter plone_products_install (Path to directory containing Plone products; leave blank to fetch one) ['']:
105  Enter zope_user (Zope root admin user) ['admin']:
106  Enter zope_password (Zope root admin password) ['']: aa
107  Enter http_port (HTTP port) [8080]: 50200
108  Enter debug_mode (Should debug mode be "on" or "off"?) ['off']: on
109  Enter verbose_security (Should verbose security be "on" or "off"?) ['off']: on
110  Creating template plone3_buildout
111  Creating directory ./plone_buildout
112    Copying README.txt to ./plone_buildout/README.txt
113    Copying bootstrap.py to ./plone_buildout/bootstrap.py
114    Copying buildout.cfg_tmpl to ./plone_buildout/buildout.cfg
115    Recursing into products
116      Creating ./plone_buildout/products/
117      Copying README.txt to ./plone_buildout/products/README.txt
118    Recursing into src
119      Creating ./plone_buildout/src/
120      Copying README.txt to ./plone_buildout/src/README.txt
121    Recursing into var
122      Creating ./plone_buildout/var/
123      Copying README.txt to ./plone_buildout/var/README.txt
124  -----------------------------------------------------------
125  Generation finished
126  You probably want to run python bootstrap.py and then edit
127  buildout.cfg before running bin/buildout -v
128
129  See README.txt for details
130  -----------------------------------------------------------
131  sa@pc1:~/work/git$ pi plone
132  drwxr-xr-x  9 sa sa 4096 2008-03-09 14:57 plone_buildout
133  sa@pc1:~/work/git$

Line 95 is another important one after installing ZopeSkel in line 48. Line 95 invokes a whole bunch of ZopeSkel and Paste Script magic which finally ends in providing us with a brand-new buildout.cfg file. What line 95 exactly specifies can be found out by issuing paster create --help. The so-called used recipe is one of the many available (see paster create --list-templates).

We are asked a few questions in the course of creating buildout.cfg as can be seen in lines 103 to 109. I either left it blank i.e. just hit RET or provided input e.g. aa in line 106. After we had been questioned, the process continues automatically until finished in line 131.

As can be seen in line 132, a new directory (../plone_buildout) has been created. In my case, the absolute path is /home/sa/work/git/plone_buildout/buildout.cfg. Of course, since we are paranoid, we take a look at the file and figure all afore specified parameters e.g. HTTP port number 50200 are in place.

We are now ready to actually download and build a whole software solution stack starting with Zope, then Plone, etc. from scratch ... this of course may take a while depending on the bandwidth available and how fast your computer is.

Finally, Bootstrap and Build

134  sa@pc1:~/work/git$ cd plone_buildout/
135  sa@pc1:~/work/git/plone_buildout$ python bootstrap.py
136  Creating directory '/home/sa/work/git/plone_buildout/bin'.
137  Creating directory '/home/sa/work/git/plone_buildout/parts'.
138  Creating directory '/home/sa/work/git/plone_buildout/eggs'.
139  Creating directory '/home/sa/work/git/plone_buildout/develop-eggs'.
140  Generated script '/home/sa/work/git/plone_buildout/bin/buildout'.
141  sa@pc1:~/work/git/plone_buildout$ ./bin/buildout
142  Getting distribution for 'plone.recipe.plone'.
143  Got plone.recipe.plone 3.0.6.
144  Getting distribution for 'plone.recipe.distros'.
145  Got plone.recipe.distros 1.3.
146  Getting distribution for 'zc.recipe.egg'.
147  Got zc.recipe.egg 1.0.0.
148  Getting distribution for 'plone.recipe.zope2install'.
149  Got plone.recipe.zope2install 1.2.
150  Getting distribution for 'plone.recipe.zope2instance'.
151  Got plone.recipe.zope2instance 1.5.
152
153
154
155  [skipping a lot of lines ...]
156
157
158  running build_ext
159  Installing productdistros.
160  Installing instance.
161  Getting distribution for 'elementtree'.
162  zip_safe flag not set; analyzing archive contents...
163  Got elementtree 1.2.7-20070827-preview.
164  Generated script '/home/sa/work/git/plone_buildout/bin/instance'.
165  Generated script '/home/sa/work/git/plone_buildout/bin/repozo'.
166  Installing zopepy.
167  Generated interpreter '/home/sa/work/git/plone_buildout/bin/zopepy'.
168  sa@pc1:~/work/git/plone_buildout$

We are getting closer to completing our Buildout when we issue the command in line 135 — what python bootstrap.py does can pretty much be seen in lines 136 to 140. In fact, the reason we can issue line 141 is because the former issued command in line 135. Line 141 actually triggers all the good things that we call Buildout. Since it downloads and builds all the components listed in buildout.cfg, that might very well take a long time — a coffee, a phone call, the toilet? Definitely, after hitting RET in line 141 is the time to do so.

169  sa@pc1:~/work/git/plone_buildout$ type ll
170  ll is aliased to `ls -lh'
171  sa@pc1:~/work/git/plone_buildout$ ll
172  total 52K
173  drwxr-xr-x  2 sa sa 4.0K 2008-03-09 15:12 bin
174  -rw-r--r--  1 sa sa 1.8K 2008-03-09 14:57 bootstrap.py
175  -rw-r--r--  1 sa sa 2.0K 2008-03-09 14:57 buildout.cfg
176  drwxr-xr-x  2 sa sa 4.0K 2008-03-09 14:57 develop-eggs
177  drwxr-xr-x  2 sa sa 4.0K 2008-03-09 15:11 downloads
178  drwxr-xr-x 39 sa sa 4.0K 2008-03-09 15:12 eggs
179  drwxr-xr-x  6 sa sa 4.0K 2008-03-09 15:12 parts
180  drwxr-xr-x  2 sa sa 4.0K 2008-03-09 14:57 products
181  -rw-r--r--  1 sa sa  11K 2008-03-09 14:57 README.txt
182  drwxr-xr-x  2 sa sa 4.0K 2008-03-09 14:57 src
183  drwxr-xr-x  4 sa sa 4.0K 2008-03-09 15:12 var
184  sa@pc1:~/work/git/plone_buildout$ cd bin/
185  sa@pc1:~/work/git/plone_buildout/bin$ ll
186  total 16K
187  -rwxr-xr-x 1 sa sa  820 2008-03-09 14:57 buildout
188  -rwxr-xr-x 1 sa sa 3.2K 2008-03-09 15:12 instance
189  -rwxr-xr-x 1 sa sa  244 2008-03-09 15:12 repozo
190  -rwxr-xr-x 1 sa sa 3.2K 2008-03-09 15:12 zopepy
191  sa@pc1:~/work/git/plone_buildout/bin$

Lines 169 to 191, nothing special here, I just wanted to show what the Buildout created for us — from now on, we will call this (lines 173 to 183) the Buildout Directory. However, the file instance is somewhat special — we will learn later on that there is actually no difference between issuing ./instance start from the directory above respectively issuing .$INSTANCE_HOME/bin/zopectl (line 200) where $INSTANCE_HOME is

sa@pc1:~/work/git$ type gr
gr is aliased to `grep -rni --color'
sa@pc1:~/work/git$ gr INSTANCE_HOME= plone_buildout/parts/instance/bin/zopectl
5:INSTANCE_HOME="/home/sa/work/git/plone_buildout/parts/instance"
sa@pc1:~/work/git$

200  sa@pc1:~/work/git/plone_buildout/parts/instance/bin$ ./zopectl
201  program: /home/sa/work/git/plone_buildout/parts/instance/bin/runzope
202  daemon manager not running
203  zopectl> start
204  . daemon process started, pid=28147
205  zopectl> quit
206  daemon process and daemon manager still running
207  sa@pc1:~/work/git/plone_buildout/parts/instance/bin$ psa zope.conf | grep -v grep
208  zope      3111  0.0  8.1 154336 84900 ?        Sl   08:45   0:26 /usr/bin/python2.4 /usr/lib/zope2.10/lib/python/Zope2/Startup/run.py -C /var/lib/zope2.10/instance/plone-site/etc/zope.conf
209  sa       28147 21.4  1.7  20928 17928 ?        D    19:13   0:01 /usr/bin/python /home/sa/work/git/plone_buildout/parts/zope2/lib/python/Zope2/Startup/run.py -C /home/sa/work/git/plone_buildout/parts/instance/etc/zope.conf
210  sa@pc1:~/work/git/plone_buildout/parts/instance/bin$ cd
211  sa@pc1:~$

We can now start a Zope Instance as usual in line 200 — the README file actually tells to go with ./instance start so I would recommend to stick to that recommendation i.e. for reasons of clarity I should not have done it like I did with line 200 ... whatever ...

Line 209 shows our just created Zope Instance. We are done as the images below indicate ...

The Buildout Directory

Lines 177 to 187 from above show the so-called Buildout Directory.

../bin

The bin directory contains the instance control script, zopepy, and the buildout command itself. ./bin/instance is equivalent to $INSTANCE_HOME/bin/zopectl.

../eggs

The eggs directory contains eggs that zc.buildout has automatically downloaded. These are enumerated and referenced when needed, for example by the instance control script. This is similar to linking packages into $INSTANCE_HOME/lib/python, but allows us to use the full power of setuptools and eggs.

../develop-eggs

The develop-eggs directory contains egg-links to any development eggs specified in buildout.cfg.

../downloads

A downloads directory will be created as necessary. Recipes such as plone.recipe.plone and plone.recipe.distros that fetch archives of products and packages will place their downloads in this directory. If an archive has already been downloaded, it will not be downloaded again.

../products

The products directory can be used for any old-style products that are being developed as part of the project. It is analogous to the $INSTANCE_HOME/Products directory. Our buildout will also manage various products for us inside the parts directory.

../parts

The parts directory is zc.buildout 's playground. This is where Zope 2 is downloaded and built, for example the $SOFTWARE_HOME becoming parts/zope2/lib/python. The $INSTANCE_HOME is in parts/instance. Typically we will not manage the Zope instance directly when using a buildout. We also should not make changes to anything in the parts directory, as zc.buildout may stomp on our modifications when we re-run ./bin/buildout.

../src

The src directory contains the sources of any custom eggs.

../var

The var directory houses the Data.fs file and Zope's logs.

UI (Unified Installer)

The Unified Installer is a one-shoot thingy i.e. it is capable of installing Plone with all its underlying software in one go. It can be downloaded from http://plone.org/products/plone (watch out for the Unified Installer). I am not going to detail how to use the Unified Installer ... just a screendump which speaks for itself:

 1  sa@pc1:/tmp/unified_installer/Plone-3.0.6-UnifiedInstaller$ ./install.sh standalone
 2
 3  [skipping a lot of lines ...]
 4
 5  [ -f /home/sa/Plone-3.0.6/bin/python ] || ln -sfn "/home/sa/Plone-3.0.6/Python-2.4.4/bin/python" /home/sa/Plone-3.0.6/bin/python
 6
 7  Zope binaries installed successfully.
 8  Now run '/home/sa/Plone-3.0.6/bin/mkzopeinstance.py'
 9  Adding Zope library path to site-packages
10  Generating random password ...
11  Creating Instance ...
12  Extracting Plone tarball ...
13  Writing random password to file ...
14  Setting appropriate file ownership and permissions ...
15  Creating Plone site at /Plone in ZODB ...
16  /home/sa/Plone-3.0.6/lib/python/zope/configuration/xmlconfig.py:323: DeprecationWarning: zope.app.annotation has moved to zope.annotation. Import of zope.app.annotation will become unsupported in Zope 3.5
17    __import__(arguments[0])
18  Added Plone
19  Finished adding Plone site
20
21  #####################################################################
22  ######################  Installation Complete  ######################
23
24  Use the account information below to log into the Zope Management Interface
25  The account has full 'Manager' privileges.
26
27    Username: admin
28    Password: xj6ohdip
29
30  Before you start Plone, you should review the settings in:
31
32    /home/sa/Plone-3.0.6/zinstance/etc/zope.conf
33
34  Adjust the ports Plone uses before starting the site, if necessary
35
36  To start Plone, issue the following command in a Terminal window:
37
38     /home/sa/Plone-3.0.6/zinstance/bin/zopectl start
39
40  To stop Plone, issue the following command in a Terminal window:
41
42     /home/sa/Plone-3.0.6/zinstance/bin/zopectl stop
43
44
45  Plone successfully installed at /home/sa/Plone-3.0.6
46  See /home/sa/Plone-3.0.6/zinstance/adminPassword.txt
47  for password and startup instructions
48
49  Ask for help on plone-users list or #plone
50  Submit feedback and report errors at http://dev.plone.org/plone
51
52  Maintainers for Plone 3 are Kamal Gill and Steve McMahon (steve at dcn.org)
53
54  sa@pc1:/tmp/unified_installer/Plone-3.0.6-UnifiedInstaller$

Actually, building the whole shebang took around 5 minutes. There are not just 54 lines of output but ... well, must have been a few thousand but then, all we need to know is how I triggered the installation (line 1) and the last few lines for example lines 27 and 28 and so on.

Altering the HTTP port and starting the Zope Instance

Again, we need to set the HTTP port (see Manually Installing Plone above for more details) of this Zope Installation respectively of the Zope Instance we are going to start. On my machine, ports 8081 and 50000 are already occopied by other Zope Instances which is why we edit /home/sa/Plone-3.0.6/zinstance/etc/zope.conf and set the HTTP port of the current Zope Instance (the one installed with the Unified Installer) to 50100. We then enter $INSTANCE_HOME/bin e.g. /home/sa/Plone-3.0.6/zinstance/bin/ in our current case and issue ./zopectl in order to start this Zope Instance (see below).

sa@pc1:~/Plone-3.0.6/zinstance/bin$ ./zopectl
program: /home/sa/Plone-3.0.6/zinstance/bin/runzope
daemon manager not running
zopectl> start
. daemon process started, pid=20966
zopectl> quit
daemon process and daemon manager still running
sa@pc1:~/Plone-3.0.6/zinstance/bin$

With this Zope Instance started, I have three Zope Instances running right now

sa@pc1:~/Plone-3.0.6/zinstance/bin$ type psa
psa is aliased to `ps aux | grep'
sa@pc1:~/Plone-3.0.6/zinstance/bin$ psa zope.conf | grep -v grep
zope      3135  0.0  4.0 155828 41632 ?        Sl   Mar01   0:40 /usr/bin/python2.4 /usr/lib/zope2.10/lib/python/Zope2/Startup/run.py -C /var/lib/zope2.10/instance/plone-site/etc/zope.conf
sa       18224  0.3 10.5 148196 109052 ?       Sl   14:48   0:35 /usr/bin/python2.4 /home/sa/work/git/plone_manually/Zope-2.11.0-b1/lib/python/Zope2/Startup/run.py -C /home/sa/work/git/plone_manually/instances/sunos_testinstance/etc/zope.conf
sa       20966 12.3  7.8  87156 81552 ?        S    17:37   0:16 /home/sa/Plone-3.0.6/Python-2.4.4/bin/python /home/sa/Plone-3.0.6/lib/python/Zope2/Startup/run.py -C /home/sa/Plone-3.0.6/zinstance/etc/zope.conf
sa@pc1:~/Plone-3.0.6/zinstance/bin$

Finally, let us enter this Zope Instance TTW (Through-The-Web) as we did with all the others before. At this point, after we entered http://localhost:50100/manage into our web browsers adress field, we are promted for the username (line 27) and password (line 28). If all went fine we are now prestend with yet another ZMI (Zope Management Interface) to yet another Zope Instance.

And yes, this time there is no need either to separately install Plone since it is already in place as we can see.

Configure

I am not sure if it is the right word but one drawback of a world-class CMS (Content Management System) is its learning curve — pretty steep in the beginning so it takes time and an unfaltering will to get through the first two or so months.

However, there is plenty of good documentation and lots of friendly and helpful people to ease the task although I have to say, the only solution that really works is reading, reading and once again reading. Accompanying to that one should play with it since Plone is designed to be toyed with. Try creating some content, joining the site under a few different names and play with the system to get familiar with it.

Generally speaking, Plone should be thought of several parts we need to pay attention to. There is the behind the curtain part which is pretty much anything that handles the content and then there is the visible part which is about how a Plone site looks like. And last but not least there is the user and roles part which in essence is about who does what at what point in time.

Graphics, Design and Themes

There is a dedicated page about it.

Configuration of certain technical Aspects

Storage

There is a dedicated page about it.

Scalability and High Availability

There is a dedicated section about it.

User Accounts and Roles

There is a dedicated page about it.

Development

This subject has a dedicated page.

Security

This website/platform has a dedicated page for all subjects regarding Plone + Security.

Miscellaneous

WRITEME

This section is about all things that are short in terms of number of words. Also, the particular subsections are not necessarily related to each another but can be seen as distinct subsets of the Plone's superset.

Glossary

The table below summarizes the various terms and technologies one will encounter throughout my website/platform. It pays off to be familiar with these names, because we will find them again not only throughout this website, but also in other Plone documentation.

Hints and Notes

Which Viewlets are used to compose a particular Page?

To see which viewlet managers and viewlets are used to compose a page, append /@@manage-viewlets to a URL e.g. http://localhost:8081/sunos_example_site/@@manage-viewlets.

Note that this only works with viewlet managers based on the plone.app.viewletmanager package. All of Plone's viewlet managers use this, but third-party products may come with simpler managers that sort viewlets alphabetically or according to some other means.

Internationalization (I18N)

Performance

The first thing to remember is that Plone is not an I just want to host my weblog or I simply need a web forum or I need a wiki kind of product. It is a powerful (but easy-to-use and extend) system which demands quite a lot from the server. It is more like an operating system than an application, to use an analogy. Therefore, if we are just looking to solve a simple problem, there are probably less demanding and better suited applications out there.

Plone is heavier on RAM and CPU usage than other run-off-the-mill web systems. It is built to do a lot of different things, and should preferably be hosted on a dedicated server if possible.

The most important consideration when building a Plone server is to have enough RAM (Random Access Memory). The more RAM a server has, the more of Plone can held in memory, and the faster it will be. For a straightforward Plone site (such as a small- or medium-sized department intranet for a company), 200-300MiB of memory will do. For a large, complex site with heavy traffic (such as plone.org), as much as 1-2GiB of RAM should be considered.

It is also helpful to have fast processor. Again, a smaller site could use a 1-2GHz machine, but for larger sites, it is helpful to have a multi-processor, high-speed machine. Plone.org runs on a 3.2GHz Xeon with 4GiB of RAM.

Also one has to remember that the way Plone ships by default, it is not set up for deployment, but for development and flexibility. Before one lets his site go live, he should read up on caching and optimization. The out of the box Plone installation is set for ease of development, not speed. Typically, we would use CacheFu, along with a proxy, like Apache or Squid. With minimal effort, a Plone site can go 10-40 times faster as it does with the out of the box settings.

Also, Plone has a technology, ZEO, which allows to operate several Plone servers (either on different physical machines, or several servers on the same machine) so that they can use the same database. With a load-balancer in front, this is an excellent way to scale a website and establish high availability.