Blog Entries tagged noplone
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.