Find and Install Add-Ons that Expand Plone Functionality

(For more resources on Plone, see here.)


It seems like every application platform uses a different name for its add-ons: modules, components, libraries, packages, extensions, plug-ins, and more. Add-on packages for the Zope web application server are generally called Products. A Zope product is a bundle of Zope or Plone functionality contained in a Python module or modules. Like Plone, add-on products are distributed in source code, so that you may always read and examine them. Plone itself is actually a set of tightly connected Zope products and Python modules.

Plone add-on products may be divided into three major categories:

  1. Skins or themes that change Plone’s look and feel or add visual elements like portlets. These are typically the simplest of Plone products.
  2. Products that add new content types with specialized functionality. Some are simple extensions of built-in types, others have custom workflows and behaviours.
  3. Products that add to or change the behaviour of Plone itself.

Where to Find Products’s Products section at is the place to look for Plone products. At the time of this writing, the contains listings for 765 products and 1,901 product releases.

The Plone Products section is itself built with a Plone product, the Plone Software Center – often called the PSC – that adds content types for projects, software releases, project roadmaps, issue trackers, and project documentation.

Using the Plone Product Pages

Visiting the Plone product pages for the first time may be a bewildering experience due to the number of available products. However, by specifying a product category and target Plone version, you will quickly narrow the product selection to the point where it’s worth reading descriptions and following the links to product pages.

Product pages typically contain product descriptions, software releases, and a list of available documentation, issue tracker, version control repository, and contact resources.

Each release will have release notes, a change log, and a list of Plone versions with which the release has been tested. If the release has a product package available, it will be available here for download. Some releases do not have associated software packages. This may be because the release is still in a planning stage, and the listing is mainly meant to document the product’s development roadmap; or because the development is still in an early stage, and the software is only available from a version-control repository.

The release notes commonly include a list of dependencies, and you should make special note of that along with compatible Plone versions. Many products require the installation of other, supporting products. Some require that your server or test workstation have particular system libraries or utilities.

Product pages may also have links to a variety of additional resources: product-specific documentation, other release pages, an issue tracker, a roadmap for future development, contact form for the project, and a version-control repository.

Playing it Safe with Add-On Products

Plone 3 is probably one of the most rigorously tested open-source software packages in existence. While no software is defect free, Plone’s core development team is on the leading edge of software development methodologies and work under a strong testing culture that requires that they prove their components work correctly before they ever become part of Plone.

Plone’s library of add-on products is a very different story. Add-on products are contributed by a diverse community of developers. Some add-on products follow the same development and maintenance methodologies as Plone itself; others are haphazard experiments. To complicate matters, today’s haphazard experiment may be – if it succeeds – next year’s rigorously developed and reliable product. (Much of the Plone core codebase began as add-on products.) And, this year’s reliable standby may lose the devotion of its developers and not be upgraded to work with the next version of Plone.

If you’re new to the world of open source software, this may seem dismaying. Don’t be discouraged. It is not hard to evaluate the status of a product, and the Plone community is happy to help. Be encouraged by evidence of continual, exciting innovation. Most importantly, stop thinking of yourself as a consumer. Take an interest in the community process that produces good products. Test some early releases and file bug reports and feature requests. Participate in, or help document, test, and fund the development of the products that are most important to you.

Product Choice Strategy

Trying out new Plone add-on products is great fun, but incorporating them into production websites requires planning and judgement if you’re going to have good long-run results.

New versions of Plone pose a particular challenge. Major new releases of Plone don’t just add features: with every major version of Plone the application programming interface (API) and presentation templates change. This is not done arbitrarily, and there is usually a good deal of warning before a major change, but it means that add-on products often need to be updated before they will work with a major new version of Plone.

Probably worthwhile to point out that major versions are released very ~18 months, and that minor version upgrades generally do not pose compatibility problems for the vast majority of add-on products.

This means that when a new version of Plone appears on the scene, you won’t be able to migrate your Plone site to use it until compatible product versions are available for all the add-on products in use on the site. If you’re using mainstream, well-supported products, this may happen very quickly. Many products are upgraded to work with new Plone versions during the beta and release-candidate stages of Plone development. Some products take longer, and some may not make the jump at all. The products least likely to be updated are often ones made obsolete by new functionality.

This creates a somewhat ironic situation when a new version of Plone arrives: the quickest adopters are often those with the least history with the platform. The slowest adopters are sometimes the sites that are most heavily invested in the new features. Consider, as a prime example,, a very active, very large, community site which must be conservatively managed and stick with proven versions of add-on products. often does not migrate to a new Plone version until many months after release.

Is this a problem? Not really – unless you need both the newest features of the newest Plone version and the functionality of a more slowly developed add-on product. If that’s the case, prepare to make an investment of time or money in supporting product development and possibly writing some custom migration scripts.

If you want to be more conservative, try the following strategy:

  • Enjoy testing many products and keeping up with new developments by trying them out on a test server.
  • Learn the built-in Plone functionality well, and use it in preference to add-on products whenever possible.
  • Make sure you have a good understanding of the maturity level and degree of developer support for add-on products.
  • Incorporate the smallest number of add-on products reasonably possible into your production sites.
  • Don’t be just a consumer: when you commit to a product, help support it by filing bug reports and feature requests, contributing translations, documentation or code, and answering questions about it on the Plone mailing lists or #plone IRC channel.

Evaluating a Product

Judging the maturity of a Plone product is generally easy. Start with a product’s project page on The product page may offer you a "Current release" and one or more "Experimental releases". Anything marked as a current release should be stable on its tested Plone versions. If you need a release to work with an earlier version of Plone than the ones supported by the current release, follow the "List all releases..." link.

Releases in the "Experimental" list will be marked as "alpha", "beta", or "Release Candidate." These terms are well-defined in practice:

  • Alpha releases are truly experimental, and are usually posted in order to get early feedback. Interfaces and implementations are likely still in flux. Download an alpha release only for testing in an experimental environment, and only for purposes of previewing new features and giving feedback to developers. Do not plan on keeping any content you develop using an alpha release, as there may be no upgrade path to later releases.
  • With a beta release, feature sets and programming interfaces should be stable or changing only incrementally. It’s reasonable to start testing the integration of the product with the platform and with other products. There will typically be an upgrade path to future releases. Bug reports will be welcome and will help develop the product.
  • Release candidates have a fixed feature set and no known major issues. Templates and messages should be complete, so that translators may work on language files with some confidence that their work won’t be lost. If you encounter a bug in release-candidate products, please immediately file an issue report.

Products may be re-released repeatedly at any release state. For alpha, beta and RC releases, each additional release changes the release count, but not the version number. So, "PloneFormGen 1.2" (Beta release 6) is the sixth beta release of version 1.2 of PloneFormGen. Once a product release reaches current release status, new releases for maintenance will increment the version number by 0.0.1. "PloneFormGen 1.1.3" is thus the third maintenance release of version 1.1 of that product.

Don’t make too much of version numbers or release counts. Release status is a better indicator of maturity.

If your site is mission-critical, don’t use beta releases on it. However, if you test carefully before deploying, you may find that some products are ready for live use when late in their beta development on sites where an error or glitch wouldn’t be intolerable.

Testing a Product

Conscientious Plone site administrators maintain an off-line mirror of their production sites on a secondary server – or even a desktop computer – that they may use for testing purposes.

Always test a new product on a test server. Before deploying, test it on a server that has precisely the combination of products in use on your production server. Ideally, test with a copy of the database of your live server. Check the functionality of not only the new product, but also the products you’re already using. The latter is particularly important if you’re using products that alter the base functionality of Plone or Zope.

Looking to the Future

Evaluating product maturity and testing the product will help you judge its current status, but what about the future? What are the signs of a product that’s likely to be well-maintained and available for future versions of Plone? There are no guarantees, but here are some signs that experienced Plone integrators look for:

  • Developing in public. This is open-source software. Look to see if the product is being developed with a public roadmap for the future, and with a public version-control repository. provides product authors with great tools for indicating release plans, and makes a Subversion (SVN) version-control repository available to all product authors. Look to see if they’re using these facilities.
  • Issue tracker status. Every released product should have a public issue (bug) tracker. Look for it. Look to see if it’s being maintained, and if issues are actively responded to. No issue tracker, or lots of old, uncategorized issues are bad signs.
  • Support for multiple Plone versions. If a product has been around a while look to see if versions are available for at least a couple of Plone releases. This might be the previous and current releases, or the current and next releases.
  • Internationalization. Excellent products attract translations.
  • Good development methodologies. This is the hardest criterion for a non-developer to judge, but a forthcoming version of the Plone Software Center will ask developers to rate themselves on compliance with a set of community standards. My guess is that product developers will be pretty honest about these ratings.

Several of these criteria have something in common: they allow the Plone community to participate in product maintenance and development. The best projects belong to the community, and not any single author.

One of the best ways to get a quick read on the quality of an add-on product is to hop on the #plone IRC channel and ask. Chances are you’ll run into someone who can share their experiences and offer insight. You may even run into the product author him/herself!

(For more resources on Plone, see here.)

Installing and Testing Products

Installing an add-on product requires two steps:

  • Installing the product files on the file system so that they become part of the Zope instance.
  • Activating the product in a Plone site – we’ll call this part the Plone installation.

Zope Installation

The method by which add-on products are integrated into a Zope instance is undergoing a change, and over the course of Plone 3’s lifetime, you’re probably going to have to install products using both the old and new techniques. We’ll cover both here.

The older style of add-on is based on the original Zope product system. In this model, any specially structured Python module that exists inside a magic "Products" directory in your Zope instance is installed as a Zope product when Zope starts.

Newer style products are distributed as Python eggs. (See for a discussion of eggs and how they work with Python.) The main advantage of this approach is that it encourages more a modular style of development where components are available to multiple packages as part of the Python library.

Several products, including Plone itself, are currently hybrids: portions are eggs and other parts are traditional Zope products.

Plone 3.2, which may be out by the time you read this, will be Plone's first "all egg" release.

How do you know what type of installation procedure is required? The project’s description or release page may tell you, but the best information is nearly always in a README.txt or INSTALL.txt text file distributed with the product.

Downloading and Unpacking a Product

You already know where to find product packages: in the Products section of, on product release pages. You may generally download them with a click. Save them in a workspace where you might store other uninstalled products.

Plone product packages are generally distributed in the form of tarballs, gzip-compressed UNIX tape archive (tar) files, and will have a ".tar.gz" or ".tgz" filename extension. A few products are in Zip archive format, and have a .zip extension.

Windows users may use a program like WinZip or 7-Zip to unpack both formats. Linux, BSD, and OS X users may use unzip to directly unpack .zip files, and will use the command:

tar -zxf product_file.tar.gz

to unpack .tgz and .tar.gz files.

Always unpack a product package into a working directory first, and not directly into your Zope/Plone install. You’re going to want to take a look at the contents before installing.

Product packages will generally unpack into a directory with a name similar to the product package archive. Look in this directory for the README.txt file, and look to see if there is an INSTALL.txt file.

Even the most experienced users should not take it for granted that they know how a product installs. Always read the README.txt and (if available) INSTALL.txt files. Installation methods and product dependencies may change with product versions.

These text files may specify dependencies: requirements that must be satisfied for a product to work. Sometimes these are specific Python, Zope or Plone versions; sometimes Python or system utilities or libraries; and sometimes other products.

The texts should also let you know whether your new product requires a traditional (Products directory) install, an egg installation, or a hybrid.

Traditional Product Installation

Remember that a traditional Plone (or Zope) product is just a specially structured Python module located in a special "Products" directory. Typically, these products are distributed in archives that contain a single product directory. For example, you might download Ploneboard as a single archive file, Ploneboard-1.0.tar.gz. The archive unpacks into a single directory, Ploneboard. Zope-level installation of a product like this is simple:

  • Move the directory created when you unpacked the archive into the "Products" directory or your Zope/Plone instance.
  • Check ownership and permissions.
  • Restart the Zope server.

Finding the Instance Products Directory

Where is your Zope/Plone instance? A single Zope installation may be used with several running Zope servers, which we call instances. An instance directory contains the etc, var, log, and Product subdirectories for a given Zope server.

If you’ve installed a standalone Plone with the Unified Installer, the instance directory will be:




depending on whether you installed as root or as a normal user. If you installed a ZEO cluster, substitute "zeocluster" for "zinstance".

On a Windows installation, the instance directory will usually be:

X:\Plone 3\Data

where "X" is the installation drive.

On a Mac installation created with the binary OS X installer, it will be at:


In all of these cases, you should find a "Products" subdirectory within the instance directory. Copy your product into it.

Some "bundle" distributions may contain multiple products in a single archive file. Check the README.txt or INSTALL.txt, but the usual procedure will be to copy all the directories created when you unpacked the archive into the instance Products directory.

Checking Ownership and Permissions

If you are running Zope and Plone on a UNIX-like machine, and if you ran a root installation (i.e., you were either logged in as root, or used "sudo" when you installed), you need to make sure that the ownership and permissions of the new product directories is correct. The key is that the user identity used to run Zope must be able to write to these directories. (This is so that Zope will be able to create compiled versions of the new Python files.) If you used either the Unified Installer or the OS X binary installer, the installer will have set Zope up to run under the "plone" user identity, and you may satisfy the owner/permission requirements by using chown to give the plone user ownership of the new directory. The command:

chown -R plone Ploneboard

will change the ownership of Ploneboard directory and all its contents to the "plone" user.

Restarting Zope

Zope only looks for new products when it starts or restarts. When you’ve added a new product on the file system, restart Zope to make sure your product is registered.


Plone 3 products may be delivered in whole, or in part, as Python eggs. Eggs are packaged Python libraries that know about their own dependencies and have simple installation procedures.

To install an egg for use with Zope and Plone, you may often just use a command like:


To install an egg for a package like, easy_install will fetch the egg from the Python Package Index at and install it.

However, you must make sure that you use the copy of easy_install that is part of the Python that you’re using to run Zope and Plone. So, it’s much more common to use a command like:


while operating in the directory at the top of your Plone/Zope installation. You’ll also need to preface the command with "sudo" if working with a root installation on a UNIX-like system.

If a product is a hybrid of old and new product distribution styles, you may need to install both an egg and product directory (in the instance Products directory).

If the product is completely new style, there will likely be an additional step required to tell Zope about the new Python library. This additional step will typically be the creation of one or more ZCML slugs in .zcml files. ZCML files are just special XML files, and may be edited with text editors.

Plone Installation

Installing a product for Zope does not automatically install it for use with your Plone site. You must take an additional step to add the product in Plone. While it may seem like extra work, this is actually a good thing. Remember that you may be running several Plone sites in particular Zope instance. The Plone product installation step means that each may have its own mix of Plone products, out of a common pool of Zope products.

To add a product to a given Plone site, log in and navigate to "Site Setup". Choose the "Add-on Products" configlet. If your Zope-level install succeeded, you should see your new product listed in the "Products available for install" section. Check the box beside it and press the "Install" button. The listing for the new product should move to the "Installed products" section within a few seconds.

Installation Problems

When something goes wrong in a product installation, the first place it’s usually noticed is when you check the "Add-on Products" configlet and don’t find the product listed. If this happens to you, first ask yourself a couple of questions:

  • Did I remember to restart Zope after filesystem installation? Remember, your new product won’t be available until after Zope has been restarted and reloads the Product directory.
  • Is this actually a Plone product? Some products, for example DocFinderTab and many field and widget products, are Zope products and not Plone products. They supplement the facilities of the Zope application server, but don’t need to be installed in a Plone site directly.

You may check to see if a product has been loaded by Zope via the Zope Management Interface (ZMI). You may already know how to view the ZMI, but if not, log into Plone and go to "Site Setup". Select the "Zope Management Interface" and navigate to the Zope application server root view by clicking on the "/"" following "Plone Site at". Then, click on "Control Panel" and "Product Management". You’ll see a long list of products; look for the new one.

If your new product is listed, consider again the possibility that it may be a Zope-level product that does not contain a Plone-specific component. If it really is a Plone product, then some error probably occurred when the Plone product installation component (often called the QuickInstaller, tried to load the product installation code.

If the product is not listed, then an error nearly certainly occurred when Zope tried to load it. In either of these cases, you should first review the product requirements (or dependencies) specified in the README.txt or INSTALL.txt file.

If you’d like to debug this, start with your event.log log file. This will be in the "log" directory of your Zope instance. Event log files may be very noisy, though, and it may simplify your hunt to start your Zope instance running in "foreground" mode, as special operating mode where messages are issued to the terminal window rather than just added to the log file. The great advantage of staring in foreground mode is that, in this mode, Zope will halt on an error loading a product. This makes it likely that your error will be the last item in the messages preceding the halt.

To start Zope in foreground mode, use the command:

./instance fg

to start Zope. The usual startup command is "instance start". (Use "zopectl" rather than "instance" if your installer did not create an "instance" command.)

If you’re using a ZEO cluster, you’ll probably need to stop one of your clients, then restart that client in foreground mode.

(For more resources on Plone, see here.)

Widely-used Plone Products

Let’s take a quick look at some of Plone’s most useful products, organized by the general class of problem they address. This list leaves out many favourites and mainstays in the interest of showing variety and new approaches.


One of the most common problems faced by a Plone integrator is sharing authentication (login IDs and passwords) with other systems. A common solution is to use LDAP, Lightweight Directory Access Protocol, for a shared authentication system. OpenLDAP, Microsoft’s Active Directory and Apple’s Open Directory are common LDAP implementations.

PloneLDAP provides Plone integration with LDAP. You may mix users, groups, and member properties from your LDAP database with other Plone Pluggable Authentication Service (PAS) sources.

Plone 3 also comes with OpenID support ready to enable. Check out for more information about this distributed authentication system.

Integration with file system-based content is another common integration problem. All Plone content is typically stored in a Zope object database (ZODB), and that presents a challenge if you need to serve content maintained on the file system (or kept out of the ZODB for other reasons, such as avoiding large binary bloat). Reflecto is an amazingly slick solution. Like many great products, Reflecto looks simple, and is easy to install and use. But it does a sophisticated job of mapping file-system file types to MIME types, and can even index many file types.

Content Management

Let’s look at a few products that help with common content-management chores.

Press Room and Plone Help Center are good examples of products that provide specialized content types.

Many organizational web sites need a polished repository for press releases, clips contacts. Press Room provides basic content types for all of these and for a Press Room folder that organizes them all. There’s nothing complex about what Press Room does, it just does it well, and saves you a lot of work in the process.

Plone Help Center is the product behind’s Documentation section. It’s a simple knowledge-base package with content types for FAQ items, short how-tos, multi-page tutorials, multi-section manuals, tutorial videos.

If your website’s content is licensed under a single copyright or license policy, life is easy (at least in that regard). But some sites need to manage content appearing under several licenses. If that’s your situation, the ContentLicensing product will ease your burden. It allows you to manage multiple licensing policies and control their application from site defaults, to particular site sections, down to the individual page.

As a site ages, you’re increasingly going to need to move content from its original location. Ideally, this should be done without breaking old URLs. Install RedirectionTool, and you’ll be able to establish in-site aliases for content. Requests for those aliases will be automatically redirected to the new document home. This is another product in heavy use on


A great content-management system is, in its own way, the ultimate community feature because it makes it possible to build a well-structured web site from distributed contributions – and to find the content once it’s on the site. Plone has many add-on products in addition that promote community information sharing. And, don’t forget that wiki-style markup is built-in – thanks to a product named Wicked that began as a popular add-on and became part of the Plone core.

PloneBoard is your best choice for bulletin-board-style structured discussion.

If you need to maintain a community calendar, consider the Plone4Artists Calendar, which supplements the basic Plone event content type by adding much improved calendar views and iCal import and export.

Need integrated e-mailing lists? Look to see if Listen, which was still in beta-release at the time of this writing, has matured. Listen is being championed by, which makes heavy use of it, and it makes great use of Zope 3 component architecture technologies.

A truly great blog product has eluded the Plone community, perhaps because Plone provides – out of the box – so many key blogging components that there’s been no consistent push for more. If you’re just after a simple blog with date sorting and an RSS feed, you don’t need any add-on product to do it, or may find the very lightweight Scrawl product ideal. However, if you need cool blogging functions like trackback pings, MetaWeblogAPI, aggregation into planets, and topics with images, take a look at Quills. Quills has had its ups and downs as a product, but has been the beneficiary of some recent loving care that promises a good future.


For structured feedback, Plone has a couple of well-supported, solid products.

Poi is an issue-tracker products, and is used on Plone.Org for the product issue trackers in the Plone Software Center. Poi is not meant to be a replacement for database-oriented, svn-integrated, project-management systems like Trac. Rather, Poi is lightweight, easy to use, well-integrated with Plone, and easy to integrate with other products.

Well-behaved forms are one of the toughest parts of web design. They need to look good, incorporate help, validate data, do useful things with input, and be secure against easy repurposing by hackers. PloneFormGen is a general-purpose form generator that makes use of the form styles, widgets, and validators already built into Plone to allow you to easily create web forms that can e-mail and/or save user input. PloneFormGen allows you to create form folders, populate them with fields that act like content objects, and add action handlers like mailers, data-savers, and thank-you pages.

Page Composition

One of the most common questions on the #plone IRC channel is about how to incorporate presentation of multiple content items onto the same page – typically the home page of a site. Plone 3’s more flexible portlet facility will help answer this question for some, but others will still need a more flexible approach to identifying page areas and filling them with content, like site news, obtained from various parts of the site.

Products that do this sort of composite page construction are necessarily very dependent on Plone version, and there have been one or more product solutions for each of the recent major versions of Plone.

Collage appears to be the current leader for filling this role in Plone 3. It makes good use of the new component architecture and even supports in-line content editing in collage elements.


The Plone4Artists project,, has been providing great leadership for integrating rich media like audio and video into Plone. Two of their products, Plone4Artists Audio and Plone4Artists Video, are not only good products for handling audio and video, but point to a new pattern for Plone products. Using Zope 3 component architecture facilities, these products add functionality without proliferating content types.

When Plone4Artists Audio is installed, for example, and you want to upload an MP3 or Ogg audio file, you just upload it by creating a new Plone file object. The file object, with the P4A support, becomes smart enough to recognize that it’s not just a file, but an audio file with metadata like artist and album. The file is then displayed in Plone with an embedded audio player and appropriate audio metadata.

Want to create a podcast? Just mark a folder or collection as an audio container via a new item on the actions menu. The folder is then presented as an audio collection, complete with RSS feed.

Plone4Artists Video does the same thing for video files, but adds an extra twist. Since video files, due to their great bulk and bandwidth demands, are often served elsewhere, P4A Video extends the link item by allowing you to activate links to Google Video, YouTube, and other video repositories as video links. The link items are then displayed with embedded video players.

Managing images? There are several Plone products that provide photo gallery functionality. If you don’t really need their special functions, you may be better off sticking with Plone’s built-in folder gallery view. Image Repository, though, is much more than a photo gallery: it extends the idea of content management to images. Organize thousands of images by keywords, then browse the keywords as if they were hierarchically organized. Image Repository is useful throughout your site because it extends the kupu visual editor to allow you to locate images by keyword.


GetPaid is unique among Plone e-commerce products, and deserves your attention if you want to sell items or site content. Visit the project web site at to get an idea of the tremendous support and community this project has drawn. GetPaid allows you to mark any of the content of your site as payable; shopping cart and payment processors complete the transaction.


Mashup is Web 2.0 jargon for presenting web content from a third party, for example a Google Maps map view, in a web page with your own content. We already saw one example of a mashup in discussing Plone4Artists Video, which allows you to put a viewer for a Google or YouTube video on a page.

The Maps product puts a Google Maps map view on a page, complete with location pointers. Using it is as simple as putting a set of location objects in a folder, then setting the folder view to show the map. Maps zooms and centers the map for you based on the locations. You can also use a Plone collection to gather together location objects, then show them in a map view, which makes Maps a sort of lightweight Geographic Information System. To use Maps, you’ll need a Google Maps API key, which is free for most use.

windowZ provides an old-fashioned sort of mashup: it shows another web page inside an XHTML iFrame in your Plone page. That may not win you any awards for Web 2.0 coolness, but it will solve a surprising variety of web integration problems quickly. windowZ will even index the content of the iFrame linked web site.



Development and Examples

One of Plone’s great strengths is internationalization. With Plone interface translations for many languages, internal use of Unicode, and a default UTF-8 character set, Plone is ready to produce a web site in most languages. But, what if you need to support content in multiple languages on the same web site? LinguaPlone to the rescue!

Soon you may wish to solve problems that aren’t covered by any existing Plone products. There are several add-on products that aid the would-be Plone developer. They range from code examples, to API inspection tools, to code generators.


Martin Aspeli’s RichDocument code example accompanied a tutorial entitled RichDocument: Creating content types the Plone 2.1 way, and has served as a canonical example for many of us developing new content types for Plone. Don’t be deceived by the “Plone 2.1” title; Martin has been continually updating the code example to work with new versions of Plone. The B-Org (Base Organization) example product has served a similar function for the use of component architecture for more complex applications, like collaborative workspaces.

API Exploration

If you’re developing with Plone, you know you can always read the source code to understand how a given bit of functionality works. But, it can often be a daunting chore to figure out where to start reading. Fortunately, there are a couple of excellent products that make use of the introspective power of Python to allow you to explore the methods and properties of content objects, along with their documentation strings and security declarations.

DocFinderTab adds a tab in the Zope Management Interface that allows you to explore the class hierarchy of a content object. Expand the display for any class to see class method declarations and their security and document strings.

Clouseau uses AJAX techniques to allow you to open an interactive Python prompt from inside Plone. As you type, Clouseau helps you with identifier completion, and shows you documentation strings and class attributes. You may even change objects and commit the changes. All of this would be a terrible security hole, but Clouseau only works when you’re running Zope in debug mode.

Code Generators

Though these projects aren’t formally products, in the sense of running as a Plone extension, they are available in the Plone.Org/products area.

ArchGenXML allows you to model new Plone content types in Unified Modeling Language, then generates for you an Archetypes-based product ready for Plone installation.

ZopeSkel is a Zope-oriented extension to the Python code skeleton generator, paster. One of ZopeSkel’s options allows it to produce a "plone3_theme" product skeleton that’s a solid basis for starting a Plone skin or theme product project. If you’ve worked on skins for earlier versions of Plone, you may have used the excellent DIYPloneStyle code generator to create your product skeleton; ZopeSkel fills the same niche in Plone 3.

It’s amazingly easy to add international message translation features, often called i18n, to a Plone product, and if you’re developing a generally useful Plone product, you should do so. Creating and maintaining the language translation files, though, is never easy. i18nDude helps a lot. It will scan your Plone product code and templates and automatically generate the base translation files. It also helps keep translation files in sync. For the editing of actual language files, take a look at poedit at Poedit is not a Plone product, but it’s been enthusiastically embraced by the Plone i18n team.


In this article, we have learned:

  • That Plone add-on modules or extensions are available in bundles called Products.
  • How to use the Product pages to find add-on products for Plone.
  • Strategies for using and choosing products wisely.
  • How to install and test a product.
  • About several of the most popular and useful Plone products.

Using what you have learned in this article, you should be ready to start enhancing the functionality of your Plone site.

Further resources on this subject:





You've been reading an excerpt of:

Practical Plone 3: A Beginner's Guide to Building Powerful Websites

Explore Title