Plone content managment

13 April 2010
Although I have run Plone on some of my web-servers for some time, these are all for websites where other people maintain the content itself. Having had to do a Plone transplant recently I decided it was finally time I tried to build & skin a (skeleton) Plone site myself.

Background

For personal websites I don't think CMS's (Content Management Systems) are worthwhile, as they involve a lot of effort hammering your personal style to fit in with the CMS's idiosyncracies. My preferred approach to websites is to edit a local copy and then Rsync it to the live server, which at the very least rules out all the CMS's that use MySQL as a data store (ie most of them). I also dislike Wiki syntax, and of the maintained CMS's out there most have been disappointments. I gave up trying to get Drupal to work, and Joomla was unacceptably slow (on a LAN connection to a dedicated server, there should be no noticeable latency). Having seen Plone in operation, I decided that I would not settle for anything else for non-personal websites.

Resource use

My big complaint with CMS's is that they are a filesystem built on top of a filesystem. Particularly for images, they bypass a perfectly good persistent object store and instead build a (more likely than not, suboptimal) one on top. In the past I did prototype parts of a CMS that used the filesystem directly, with per-directory metadata kept in SQLite files, but I abandoned that project due to PHP using an out-of-date version of the SQLite library.

Plone runs as an application server, so don't expect to be able to run it on your £1.49 shared host. You will need at least a VPS, and quite a powerful one as well. From personal experience you will need at least 256mb of guaranteed ram (128mb would be an absolute squeeze). There are some specialist Plone hosting outfits around, but they seem comparable in price to a cheap dedicated server, and having used VPSs for a few years I would not want to go back to any sort of shared hosting anyway.

Setting up Plone

For testing purposes I did a non-root standalone install of Plone 3.2.2 into /home/remy/Plone/ (with a deliberately insecure admin password):

wget http://launchpad.net/plone/3.2/3.2.2/+download/Plone-3.2.2-UnifiedInstaller.tgz tar -xzvf Plone-3.2.2-UnifiedInstaller.tgz cd Plone-3.2.2-UnifiedInstaller ./install.sh --target=/home/plone/Plone --password=sekret standalone

Skinning via the web interface

It is rather verbose, but I found a howto that details creation of new skins (aka themes) via the web interface. Remember to reconfigure Plone to show CSS changes immediately - Plone does a lot of internal caching, and you need to switch this off.

Moving the breadcrumb bar to the footer

Plone has two kinds of components: portlets and viewlets. Portlets are the things that appear in the left/right columns (e.g. calendar), and viewlets which is everything else (the viewlet we are interested in is plone.path_bar). They can be arranged by using the following URLs (for some reason there is an easy-to-find link for arranging portlets, but not viewlets):

http://localhost:8080/site/@@manage-viewlets http://localhost:8080/site/@@manage-portlets

Each viewlet is assigned to a viewlet-manager, and the order in which viewlets appear (and whether they appear) can be customised via the Plone web interface. The location of viewlet-managers can also be changed by editing main_template. However, moving viewlets between viewlet-manager cannot be done via the web interface (you have to edit via the filesystem instead, and cleanest way of doing that is to make a product template (see below).

The Plone site has instructions for moving viewlets between viewlet-managers. However when it mentions IMyThemeSpecific you should instead use IThemeSpecific.

Setting up skeleton product templates

Although skinning via the ZMI (web interface) is easier for those who are not command-line junkies, it has one big disadvantage: there are some things you cannot customise. Personally I found this out the hard way, but on the whole I prefer the filesystem approach (once I got it working..). The Plone website has instructions for doing this, and it pretty much amounts to:

PATH=/home/remy/Plone/Python-2.4/bin/:$PATH ./easy_install -U ZopeSkel cd /home/remy/Plone/zinstance/src paster create -t plone3_buildout pgu.theme pgu.theme paster create -t plone3_theme pgu.theme

When editing buildout.cfg, remember that only the develop egg entry has the src/ prefix. Also, there is a bug in ZopeSkel that means some manual editing is needed if you are getting errors. These two gotchas took me to dawn to solve.

Getting errors on the console

When Plone goes seriously wrong, it is usually due to a Python exception getting thrown. The resulting error messages are hard to read, so I prefer to get the errors on the console rather than the web browser. You can do this by shutting down Plone and starting it up again in foreground mode:

bin/plonectl stop bin/instance fg

If the Python error is a missing global, fastest thing is to do a grep for that variable. In my case not uncommenting all the bits needed to see an example led to some of the errors.