Plone is probably the best Python CMS (Content Management System). This means that it’s a piece of software that provides all the necessary tools for people to publish content.
Why do we say that Plone is the CMS? For several reasons:
It's easy to use
It's available in more than 40 languages
It has granular security
It's regularly updated
It's Open Source
It has almost everything we need and, if it doesn't, we can add that specific need
These two last are, no doubt, its most important features: Plone is extendible, because it’s also a framework, and that is what we’ll mostly cover in this book—the components that are part of the framework and how to use them to build our extensions.
Note
Find out more about Plone features at: http://plone.org/about.
In Plone, the extension facility is provided via the installation of products. Think of them as plugins, add-ons, extensions, or whatever name you want. In Plone literature, they are called products, though.
Note
While most Plone add-ons are technically Python packages, we will use the term products throughout this book because it is still very commonly used in Zope and Plone sphere.
As a matter of fact, Plone itself is a whole set of products, and some of its current basic features were born initially as additional characteristics, like Archetypes (more of this in the Chapter 3). With a little luck and a lot of work, one of your products may be included in a future release.
Note
You can find a variety of available Open Source community-developed products at http://plone.org/products.
In this chapter, we are going to install Plone (in both Linux and Windows). Plone is not an isolated software application, it needs Zope and other associated products to be installed as well. To understand this process and all these components, let’s define a not-too-comprehensive, but sufficient glossary:
Term |
Definition |
---|---|
A file containing Python definitions and statements. | |
A set of Python modules. | |
A way of distributing Python packages. It is very interesting because it provides not only the programming code but also metadata like the version number, dependencies, and license terms. | |
An environment or system created with a configuration file that is used by a special Python package, named zc.buildout, to execute a set or parts in a repeatable way so that it can be run on different computers or operating systems. | |
A Python package, used by | |
The set of Python packages, templates, and other files needed to execute a Zope server. | |
A particular Zope server installation, each of which might have its own configuration set of add-on Python packages and database. |
In the following sections, we’ll mainly look at a method named buildout for a proper Zope instance set up. However, we won’t cover all of its possibilities. Throughout the whole book, after adding products to the project we are developing, we will add recipes or parameters to the buildout
file, which we will create in this chapter.