Blog Entries tagged plone
Feeds: RSS | Atom

Why I left Plone - Part 1, the Learning Curve

Published: 2009-02-07 11:44 UTC. Tags: plone noplone

For a long time, I was a Plone user and developer. I tried hard to keep myself convinced that Plone was the solution to many web-related problems, not only strictly Content Management-related ones, but all sorts of web applications.

A while ago, I realized that I was, just that - trying hard to keep myself convinced. That is really not a good sign when it comes to frameworks you use in your programming - if you're to work with them and get productive, you have to like them because they actually are good, and fun, to work with. This is not the case with Plone, and I'll try to explain why.

After starting to write this, I realized that I have so many reasons to leave Plone that this will have to be the first in a series of posts. Stay tuned!

The Learning Curve

I started using Plone while looking for a good solution for the external website of the company I was then working for. After some evaluation of different alternatives, I decided on Plone. Plone was then at version 2.0.6, if I recall correctly.

We hired a summer intern with some previous Plone experience with the task of doing different kinds of integration with our existing systems, including some LDAP integration. I remember that he was spending lots of time cursing especially the LDAP integration and the user management code.

About the time when the integration were finished and we began thinking about deplying, Plone 2.1 was released.


KABOOM - an explosion of new things to learn!

Plone 2.1 was like an entirely new piece of software. Lot's and lot's and lot's of things had changed. At least that was the impression you got if you were not a Plone Guru.

I made the decision of going for Plone 2.1, since I didn't want us to be left behind with incompatible Products (that's the Plone term for more or less useful addons that can be downloaded and installed in a Plone instance - I'll probably write something about them later..). So, lot's of time had to be spent again trying to fixup the site into a usable state. The LDAP integration we hoped for had to be half-ditched because of time constraints, and we also had to lower the ambitions on the creation of a nice-looking graphic appearance, instead reusing some old CSS we alread had. Even then, fighting the Plone styles system was a pain, and it didn't really get better in later versions.

We finally got the site deployed. It didn't get updated as often as I had hoped for, and frankly, it didn't work that well, with hickups and performance trouble.

After a few years, Plone 2.5 arrived.


KABOOM - an explosion of new things to learn!

This was where the magical mystery tour of Zope3 technology began to show its ugly face in the code. You had to learn stuff like adapters, interfaces, etc. And although these are well known concepts in the programming world, the key is to neither overuse them nor overcomplicate!

I don't remember, but I think I managed to lift the site up to Plone 2.5. I was really starting to get tired of Plone at this point.

The fun however didn't end there, because some time later, Plone 3 arrived. And again.. KABOOM - lot's of new things to learn. To be just, some of the new things were already familiar if you had learnt them in Plone 2.5, but there were still plenty of new weirdness.


For me, not being a full time web site developer, it was near to impossible to keep track of all changes and concepts. It was especially hard to know which concepts to use for good compatibility with future versions of Plone.

New things arrived all the time - one example being the way you were supposed to make skins (the graphic appearance). It was completely revamped several times, each time introducing new layers of abstraction and complexity. Stuff like the stylesheet registry, where you are supposed to write XML code that registers your stylesheets in a magic registry that's accessible only via the magic web interface (the ZMI). Argl!

Trying to manage the way installations are made became more and more complicated, being a python script to begin with, then growing into countless XML files per product, making it very hard to keep track of what's going into what file. Argl, again!

No, I'm all happy I left Plone, and the learning curve is just one of the reasons.

(Beautiful explosion images from PD


Migrating Plone Sites to Django

Published: 2008-11-01 20:50 UTC. Tags: software plone django noplone

As mentioned earlier on this blog, I have converted this site from Plone to Django.

The conversion included migrating most of the data from the Plone instance's ZODB (Zope Object Database) into Django's ORM.

The hard part of that process is to get the data out of ZODB as the format depends completely on which Plone products you have been using. You need to check the schema for each product for which you want to extract data to get the field names, and you need to write code for extracting the data from each type of content type and add a new object in Django's ORM, translating data from one format to another in some cases.

In my case, I wrote a script that takes care of:

  • Document and Folder objects from Plone's standard contenttypes.
  • Blog entries in a Quills blog.

The script will traverse all Document, Folder and Blog entries and extract their data, adding instances of Django models from two custom Django products I have written.

A second script will then read the data from Django's database and modify the URLs in <img> tags, downloading the images from the Plone site via HTTP to a directory which will be configured as MEDIA_ROOT in Django. The script does the same for <a> tags that refer to images, .tar.gz files, etc. that also were stored in the ZODB of the Plone instance.

Each site that wants to do a conversion from Plone to Django will have to write their own script, as the set of products used in the Plone instance is site-specific, and the set of applications used in Django is also site-specific. However, I have made my conversion scripts available via subversion in the hope that they can serve as an example.

To access the scripts, either check them out with your subversion client. Example:

git clone git://

The scripts are in the plone2django_migration subdirectory.

You can also browse them here:


Bye Bye Plone, Hello Django!

Published: 2008-09-21 20:18 UTC. Tags: plone django noplone

This is the first post on the rewritten, now running a set of django apps instead of Plone. Yay!

Now let's hope everything works as I want them to. More info follows.


Plone and 256Mb - forget that

Published: 2008-05-05 18:00 UTC. Tags: plone

Quoting myself from the other day:

''It actually seems like Plone 2.5 can run on a machine with only 256Mb of memory with acceptable performance as long as the CPU is fast.''

Very wrong for my instance. At least if there is anything else running on the machine, in this case a mail server (Postfix+Dovecot). Sloooow..

Resized my slice from 256M to 512M. Seems to work better now.


A contenttype template in ZopeSkel's localcommands

Published: 2007-12-02 22:14 UTC. Tags: software plone

As Tarek  noted the other day, I've added a template for injecting content types into an existing Archetype product, using Mustap's
localcommands support for ZopeSkel


Here's what the contenttype template will do for you after you've answered some questions:

  • Define a new Add Permission the product's
  • Define an interface for the content type you're creating.
  • Create a content type class, in a subdirectory named content/
  • Register this content type class in content/configure.zcml
  • Register the new content type in the factorytool, by adding to profiles/default/factorytool.xml
  • Register basic permissions for the new content types, by adding to profiles/default/rolemap.xml
  • Register the content type with portal_types by adding to profiles/default/types.xml
  • Add a new file with configuration information in profiles/default/types/.


Here's an example on how to use the template. You'll need mustap's branch of ZopeSkel for this to work:

Begin by creating a new product based on ZopeSkel's the Archetype template:

$ paster create -t archetype
Selected and implied templates:
  ZopeSkel#basic_namespace  A project with a namespace package
  ZopeSkel#plone            A Plone project
  ZopeSkel#archetype        A Plone project that uses Archetypes
Enter project name: efod.test
  egg:      efod.test
  package:  efodtest
  project:  efod.test
Enter title (The title of the project) ['Plone Example']: Contenttype Example
Enter namespace_package (Namespace package (like plone)) ['plone']: efod
Enter package (The package contained namespace package (like example)) ['example']: test
Enter zope2product (Are you creating a Zope 2 Product?) [False]: True
Enter version (Version) ['0.1']:
Enter description (One-line description of the package) ['']:
Enter long_description (Multi-line description (in reST)) ['']:
Enter author (Author name) ['Plone Foundation']:
Enter author_email (Author email) ['']:
Enter keywords (Space-separated keywords/tags) ['']:
Enter url (URL of homepage) ['']:
Enter license_name (License name) ['GPL']:
Enter zip_safe (True/False: if the package can be distributed as a .zip file) [False]:

Now go into the directory just created:

$ cd efod.test
$ paster addcontent contenttype
Enter contenttype_name (Content type name ) ['Example Type']:
Enter contenttype_description (Content type description ) ['Description of the Example Type']:
Enter folderish (True/False: Content type is Folderish ) [False]:
Enter global_allow (True/False: Globally addable ) [True]:
Enter allow_discussion (True/False: Allow discussion ) [False]:
  Inserting from config.py_insert into /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/
  Recursing into content
    Copying +content_class_filename+.py_tmpl to /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/content/
    Inserting from configure.zcml_insert into /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/content/configure.zcml
  Inserting from interfaces.py_insert into /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/
  Recursing into profiles
    Recursing into default
      Inserting from factorytool.xml_insert into /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/profiles/default/factorytool.xml
      Copying rolemap.xml_insert to /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/profiles/default/rolemap.xml
      Recursing into types
        Copying +types_xml_filename+.xml_tmpl to /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/profiles/default/types/Example_Type.xml
      Inserting from types.xml_insert into /home/forsberg/dev/plone/mustaptest/src/efod.test/efod/test/profiles/default/types.xml

That's it! After registering the archetype product in your buildout and installing it in Plone, you'll be able to add new 'Example Type' content.

Of course, for your custom content type to be really useful, you'll have to edit it, adding new fields and modifying templates.

Some Details

I am by no means a Plone guru, so some of the details in how this template constructs the new content type may be less than optimal. Please tell me if that's the case, and I'll see what I can

Base Classes

Depending on the answer to the "Folderish" question, the newly created content type will inherit either from Products.ATContentTypes.content.base, or from Products.ATContentTypes.content.folder.

Standard Fields

The template will set up AnnotationStorage and bridge properties for the standard title and description fields.


The Manager role is given the add permission for the content type (in profiles/Default/rolemap.xml).

zope2.View is required to view the content, and cmf.ModifyPortalContent to edit.


The standard views auto-generated by Archetypes are used as a default. Perhaps generating a custom view class, with template, would
be more Plone3? On the other hand there's already another template for creating a view available.

Please test!

Please test the template and tell me what you think! What should be made different, and what have I forgotten?


PlacelessTranslationService bit my head off!

Published: 2007-08-09 16:34 UTC. Tags: open source software plone
Today, I made the mistake of adding a <myproductname>-sv.po file in the i18n directory of my product, which accidentally were marked with
Language: en

This of course made the english strings appear in swedish, but that's only to expect. What happened then was worse - after correcting the file to contain:

Language: sv

..there were no change! The english strings still appeared in swedish!

After a frustrated debug session, it turns out that the language property of the GettextMessageCatalog object stored in the ZODB (I think) is not reloaded when the Language property in the file is changed. So, even if you change the Language line in the .po file, the translation will still be marked as being in the language it first was entered as.

The solution? Move the .po-file out of the i18n directory, restart Zope, then move it back, and restart again.


Well, at least I can be glad that my CMS is an open source product, allowing me to debug problems properly.


Plone 2.5.2 and LDAP - revisited

Published: 2007-03-04 18:23 UTC. Tags: software LDAP plone

One or two years ago, I spent some time trying to understand how to connect Plone 2.0 to LDAP. I really had no luck as things were complicated. Reading out existing users from the directory might have been possible, but trying to create users was a thing never heard of.

I decided to check out the current state of Plone and LDAP again with amore modern version of Plone, in my case, Plone 2.5.2. After some heavy experimentation, I've come to the conclusion that the software involved has grown more mature, but it's still hard to get it working.

Sources of Information

Software Requirements

  • python-ldap. Make sure the python that is used to run Zope has this module available, or nothing at all will work.
  • LDAPUserFolder. I used version 2.8beta.
  • LDAPMultiPlugins. I first tried version 1.4, but got some problems. Version 1.5, released yesterday(!), works much better.
  • The LDAPMultiPlugins patch available at For me, it applied cleanly on top of LDAPMultiPlugins 1.5. It adds functionality that is available and needed by PlonePAS. Group memberships seems to work much better with this patch than without.
  • Two patches, one on CMFPlone/ (download here), and one on PasswordResetTool/skins/PasswordReset/ (download here). Without these, registration will fail. Please note that both patches are ugly hacks that are not long-term solutions to the problem.
  • This patch:, or login after password reset will fail with a recursion depth error.


Drop LDAPUserFolder and LDAPMultiPlugins into your Products folder, apply patches listed above, and restart Zope.


Follow In short, you add a LDAP Multi Plugin to your PAS folder (acl_users in ZMI) by using the dropdown in the top right corner and then configure it.

Theory of Operation

Plone 2.5 uses PlonePAS, which is an adaption of Zope's PAS (the Pluggable Authentication System) for its user/group handling. That is a good thing, as PAS is a very flexible system that can do just about anything.

To get LDAP users/groups/authentication, LDAPMultiPlugins need to be installed and configured. After configuration, LDAPMultiPlugins contain an LDAPUserFolder that is used to actually fetch information from LDAP. The different plugins in LDAPMultiPlugins then add functionality such as authentication, user and group enumeration et. al. to PlonePAS.

Configuration of which LDAP server(s) to use, which base to use etc are made by visiting acl_users -> <your LDAPMultiPlugin> -> Contents -> acl_users. A bit awkward to find, if you ask me.


It's very important to pay attention to the LDAP Schema tab under the LDAPUserFolder.
  • The LDAP attribute used to keep the full name of the user must be mapped to fullname. In my case, this means that the LDAP attribute cn should be mapped to fullname. For other directory configurations the attribute may be named differently. Novell eDirectory for example, uses cn as username.
  • The LDAP attributes used to keep the e-mail address of the user must be mapped to email. In most cases this means that the LDAP attribute mail should be mapped to email.
  • Only attributes listed in the LDAP Schema tab are available in the dropdowns used to select which field to use as login name attribute, username etc in the configuration of LDAPUserFolder.
  • All attributes listed as MUST in the LDAP schemas used to create new users (and search for existing) must be listed under the LDAP Schema. If not, user registration will fail due to LDAP schema errors.
It's also very important to pay attention to the list of User Object Classes  in the configure tab. This list is used both to construct the query used when searching for user objects, and to create new user objects at registration. At new user registration, an LDAP object is first created with all attributes (except the RDN attribute) set to [unset] in the LDAP database. As mentioned above, all attributes listed under the LDAP Schemas tab are filled with this value. Later on in the registration codepath, the attributes actually mapped to plone attributes are set (one attribute at a time, in separate LDAP requests).

The order of the PAS Plugins is very important. To get user registration to work, and for other things as well, the LDAP Multi Plugin should be at top of the list of plugins for each type of plugin.

For (much) better performance, add caching by visiting the Caches tab of both ZMI->acl_users and your LDAP Multi Plugin. Adding a cache to source_groups also seems like a good idea (there's no cache tab, so you'll have to find the URL to the cache management yourself - it's something like http://uterus:8080/Plone/acl_users/source_groups/ZCacheable_manage. For me, it seems to work using the RAM Cache Manager that already exist in any Plone 2.5 installation.

That's all the things I can remember as being important from yesterday's late night session :-).


Updated site to Plone 2.5.1

Published: 2006-11-27 19:46 UTC. Tags: plone

I finally have upgraded this site to Plone 2.5.1. There's no big changes for the casual viewer. About the only visual changes are in the blog, which I've upgraded from Quills 0.9 to Quills trunk. In the non-visual department, the syndication feeds now contain category names, which will make technorati happier. Speaking of technorati - I wonder why it doesn't pick up changes to this blog.

The blog software upgrade was not completely painless, so to speak. All entries in the blog were flagged by new in the syndication feeds, not to mention that they were displayed as html code. That problem went away when upgrading the basesyndication product as well.

I honestly don't know if this problem is present in Quills 1.5RC3, as I had some other strange error there. I do however think this was more related to a locally modified template.

Oh well.

Plone Development Experiences

Published: 2006-10-27 22:57 UTC. Tags: plone

For the last days, I've been doing some heavy Plone development for a community site that hopefully will be launched sometime during the next few days. Although I have done a fair amount of Plone development earlier, this time, I did learn a lot, especially about ArchGenXML.

Content Types

When I first started using Plone, I had trouble understanding the concept of "content types". All the documentation was talking about content types. Everybody was speaking about them, but I didn't want content types, I just wanted some scripts to create some users in an LDAP database. I ended up tacking ZPT files to existing content types. Ugly and very hackish.

Now, I think I've understood the concept. In Plone, all content is an instance of a content type. You need a page creating users in an LDAP database? It's a CreateUsersPage Content Type! That's how to do it with Plone. At least that's my current understanding.

For this project however, the idea of content types was very easy to apply to the problem. The community wants to build a database of applications that work in a specific environment (I'm a bit secretive on this project since it's not set in production yet) - that's a perfect match. Each application in the database is modelled as an AppDBApplication content type. There's AppDBCategory objects, and last but not least, the AppDB content type which holds AppDBCategory and AppDBApplication objects.

Working with ArchGenXML

ArchGenXML is a code generator for Plone, or more specifically for Archetypes-based content types. Archetypes is the framework for creating content types that is used in Plone, at least in recent versions.

Basically, you create an UML diagram using some UML editor such as ArgoUML. ArchGenXML then generates code based on the information in the UML diagram. This sounds complicated, and it has a somewhat steep learning curve, but once you get it, it's a very productive way to create Plone Products - A Product is another Plone concept. It's something you install in your Plone instance which keeps a bunch of related code together, for example some content types and their ZPT templates and some tools used by the content types together with for example custom workflows.

ArchGenXML generates all the boilerplate needed to create a product, including code to interact with the product installer inside Plone. Very handy.

If you haven't done so already, you really need to read the ArchGenXML tutorial

In this project, I created a class in the UML diagram for each type of content so there was one AppDB class, one AppDBApplication class and one AppDBCategory class. The AppDBApplication and AppDBCategory classes were then Associated (an UML term) with AppDB, which automatically makes AppDB a folder class that can hold objects of AppDBCategory and AppDBApplication.

Each class is then equipped with attributes and operations. The attributes end up as automatically generated input forms and automatically generated renderings of the data in the end. This is very handy! In my AppDBApplication for example, I added an attribute called 'version' for storing the version of the piece of software that each object in the database refers to. After generating the code with ArchGenXML, I end up with an Archetypes class that automatically creates an input form where for the version attribute, as well as an automatically generated page for viewing all the data, where the version field is included.

Customizing View and Edit Templates

Another thing I understood just recently was how you are supposed to edit the view and edit pages for Archetypes-based content types in a decent way. The HOWTO named How to Customize View or Edit on Archetypes Content Items is really a must read!

Using the templates in the HOWTO as a basis for your view and edit forms makes Archetypes development much easier since it takes care of some of the fuzz, such as making sure there are relevant variables already defined in your template.

Make sure you read the whole HOWTO, including its comments. There is one real goodie in one of the comments - the basis for how to create edit forms that don't look like all other edit forms in Archetypes. Here's how you do it:

  1. Create a new filesystem template named <nameofyourcontenttype> Place it in the skins folder of your product. Use the edit template in the HOWTO as base, or use this stripped-down version:

    <html xmlns=""
      <metal:head define-macro="topslot">
      <metal:head define-macro="javascript_head">
            <!-- body, editform , fields, buttons, the default macro
                 contains a number of slots which usually provide enough
                 ways to customise so often I use that macro and just
                 fill the slots
            <metal:body define-macro="body">
                <metal:default_body use-macro="here/edit_macros/macros/body">
                  <metal:block fill-slot="widgets">
                  <!-- This is where you'll add widgets -->
  2. Inside the <metal:block fill-slot="widgets"> tags, add one of these for each field in your schema that you want to appear in the edit forms:

<metal:fieldMacro use-macro="python:here.widget(<name of your field>, mode='edit')

Of course, replace <name of your field> with the name of the fields for which you want the input field to appear, as defined in the schema of your archetype class. You are free to use any html elements and css to position the widgets where you want them.

Customizing Widgets

In this project, I wanted some javascript to be triggered when one of the input fields is modified. It's a simple thing - I want some other input fields to enabled or disabled based on the value of the first input field (a radio button collection with two alternatives).

I had no idea on how to accomplish this, so I asked on the #archetypes IRC channel on freenode. The trick is to copy the ZPT template used to display the widget you are using to your own skins directory, naming it appropriately, then using the macro attribute on the widget in the archetypes schema, point to the new template. An example:

) I have a field named *operatingsystem in my archetypes

schema. It's defined as follows:

         label="Written for",
         description="The operating system the application originally was written for",

I'm using ATVocabularyManager in this project, hence the NamedVocabulary as vocabulary.

Note the line macro=appdb_widgets/appdbapplication_selection.

) Since the field is using a *SelectionWidget, I copied from <instance home>/Products/Archetypes/skins/archetypes/widgets into the directory appdb_widgets in the skins dir for my product and named the copied file

Note: Do not call the subdirectory in your skins dir widgets, since that will most likely give you an error because Plone will then try to find template files for other widgets in your skins directory, where they will not be available. This has to do with the search order in the plone skins tool.

) Now edit *appdb_widgets/ and add the
call to a javascript function.

The Mystery of the Lost Content Types

Published: 2006-04-19 23:10 UTC. Tags: plone

I was puzzled yesterday when I uploaded a file via WebDAV. Since the file was equipped with a Content-Type header, I expected it to be parsed as reStructured Text. Instead, it appeared as a DTML document. The horror! The horror!

It turned out that the predicate list in the content_type_registry was empty. I don't know why. I recently upgraded the Plone instance from 2.1.0 to 2.1.2, that could be related.

By removing and then reinstalling the ATContentTypes product with the Add/Remove Products tool, the problem went away.



/etc/init.d/zope2.8 restart on Ubuntu

Published: 2006-04-18 18:08 UTC. Tags: plone

/etc/init.d/zope2.8 restart didn't work on my Ubuntu Server 5.10. It turns out that it's using Ubuntu's homebrewn dzhandle script to handle plone instances. You are supposed to create instances using dzhandle. If you do, there'll be a file named debian_policy in the etc directory of the instance, and if that file exists, dzhandle will recognize the instance and happily restart it.

0 comments. - now with nice looking titles on WebDAV-uploaded HTML!

Published: 2006-02-28 21:10 UTC. Tags: plone

Plone 2.1-2.1.2 has an irritating bug - HTML files uploaded via WebDAV gets the filename as page title, which looks very ugly.

I've now created a patch for this that restores the behaviour of Plone 2.0.x, where the title is extracted from the <title> tag.

Check out for the patches. I'm now eagerly awaiting feedback from the Plone developer responsible for the bug.


Sometimes, there's a Product Just For You

Published: 2006-02-23 18:13 UTC. Tags: plone

Today, the marketing person at work came and told me that he wanted a signup form for a usergroup meeting we're planning. Something simple that mailed him with the relevant information.

  • "OK, I'll go see if I can fix something like that.."

I had heard about PloneFormMailer earlier, so I did some quick research on it, including asking on #plone to verify that it works in Plone 2.1, and installed it in my staging instance.

It solved my problem perfectly!

This is one of the things I like about plone - very often, someone else has already solved the web publishing problem you're having right now, and you can use an existing product instead of having to create your own.

PloneFormMailer uses Formulator, which also looks very interesting for some of my needs - for example, I have a custom-written product that fiddles with some LDAP values, and I could probably use Formulator or some other similar product. this HOWTO seems interesting.


Fixed the Comment Problem

Published: 2006-01-15 00:21 UTC. Tags: plone

Finally managed to fix the problem with VisitorComments and Quills, so now it's possible to comment on this blog in a decent manner again.

I've written about the solution to the problem on the Quills mailing list.


Blog-Trouble! Re-post, again!

Published: 2006-01-07 20:43 UTC. Tags: plone


I tried to install VisitorComments to allow anonymous users to leave their name when they commented blog entries.

By some, yet to be known, reason, this f*cked up my something in the blog, so comments are now added to the root of the blog instead of to the relevant entry. Uninstalling VisitorComments didn't help :-(.

This seems to be a known problem according to Olivier Ozoux on the quills mailing list, but his proposed solution - to remove the blog and then re-post all the entries, doesn't work for me, now when I decided to give it a try, even though it's a rather annoying thing to do..


Evaluating Photo Albums for Plone

Published: 2006-01-07 20:26 UTC. Tags: plone
  • ZPhotoSlides: Well, seems rather competent. Documentation hints about ability to read photos from file system, but how? Very hard to understand where to find that functionality. That would be very useful, though.

    Adding a ZPhotoSlidesFolder doesn't seem to work at all, possibly because of trying to use ZPhotoSlides under Plone 2.1.

    Webpage of product seems to be quite outdated. The only "working demo" of version 2.0 gives a 404. Hmm..

  • AT Photo Album: Adding an AtPhotoAlbum object gives me a folder-like object without any possibility to edit anything. I think product is not Plone 2.1-ready.

  • ATPhoto: Doesn't seem to have much functionality. Fails to display the single photo I added in view mode.

  • CMFPhotoAlbum: 0.5.0 fails to install due to missing navigation_properties in Plone 2.1. Trunk from SVN installs, but trying to add a Photo Album gives a 404.

    Trying to find the canonical web page for CMFPhotoAlbum seems impossible.

  • The built in photo album view in Plone 2.1 is not good enough for my demands.

Nah, I'll stick with the album generated by Kofoto for a while. Here's my photos.