Plone experiences and rants
I’ve been working with Plone for little over a year now, and I would like to share some experiences with this article. First I would just like to say these are my experiences about the CMS/Framework and I’m still fairly new so there might be things I’ve misunderstood or haven’t done “the right way”.
So “Plone?” you say.
Let me tell you about Plone. Plone was the coolest “Python kid” on the block during the first decade of the new millennium. Since then it’s not making a lot of buzz, but still manages to compete against other big CMS/Portal systems like Typo3, Liferay.
It has quite a few good points. A well though through framework, competing with other CMS’s written in C# and Java. I would describe it as a Python CMS with an “enterprisey” feeling to it. Written in the language everyone loves. Underneath the core, Plone is built upon the framework Zope and uses ZODB as its default database. Admirably, ZODB was first released in the 90’s which is pretty unusual for that time.
The good parts
The CMS can practically do anything. You have access to all the functionality you get from Python and thousands of libraries. This makes text processing/parsing a breeze. I don’t know many languages except Perl that handles parsing of text better. Of course this is more of a Python treat than the actual framework. But it’s great since getting into Python is a quite fast ride. The whole database is located in one file “Data.fs”, so just by copying0 that file you have a copy of your entire database.
Setuptools with buildout. Defining what dependencies you have in your project, the buildout script will download everything for you and set the whole thing up. Plone is also very easy to use for the users. Especially to select what content you would like to see on a specific page.
The lesser good parts
That Plone is a complicated CMS is an huge understatement. It takes a lot of time to get into. As much as Python is easy to get into, Plone is hard! I’ve tried two approaches. I bought the book Plone for professionals and gave it a read. The books goes through the process of creating a cinema website. “Neat” I thought. A pretty realistic final product instead of many small tutorials that usually is about blogs…
However the book was pretty much killing the interest of Plone development from the start. A lot of editing XML (or ZCML as the call it) and more XML files. Writing unit-tests against the xml files you wrote. So to summarize the book pretty much killed any slight Plone enjoyment you might have had. On the other hand, the book is very throughout. It has a lot of Plone wisdom in it. But for a beginner it’s not the optimal entrypoint.
The second approach worked much better for me. Trial and error and Internet. One big problem with this Google Driven Development approach, is that when you land on Plone’s website you notice it’s severely broken. You might have thought you found the right link for what you were looking, but instead leads you to a blue white 404 webpage that refers to Plone’s index manual.
So to be completely honest, most of the Plone I’ve learned is from by looking at other peoples code, and trial and error.
The biggest thing that bothers me is that Plone is very fragmented. All the python packages you install are called eggs. Each egg contains it’s certain functionality, so Plone is more of a distribution with hundreds of eggs. This for me feels a bit problematic, when an egg becomes obsolete and defunct. Our website also has dependencies on custom plone eggs, which were maintained by a company that ceased to exists 5 years ago. I am just crossing my fingers they won’t cause problems in the next months.
It’s already happened that I’ve had packages I had to replace that doesn’t exist anymore. It’s bit of a fright pushing out someone else’s packages to the live servers that I don’t know can conflict with anything else. Of course I’ve tried it out on test before but that isn’t 100% bullet proof.
To query the database in Plone you use the “portal_catalog”. It’s a tool that consists of pointers to data with indices. When you do a query you get something called a list of brains back. Each brain has some metadata and you can wake up the full object it points to in the database by calling the method getObject(). You can also incorporate solr with the catalog, for faster searches that also supports full-text search. The catalog is fairly fast in returning its brain results. But waking up an object from the grave (zodb) is not an efficient thing. So when presenting contents as lists, make sure there are meta data on those brains.
The website I’m developing on has a database that is more than 13 GB, it’s closer to 100GB if you include all the images, PDF’s and other binaries. And I’ve experienced that ZODB is pretty error prone and requires a lightning fast harddrive. The catalog tool is not always updated to it tries to access content that is deleted and pages crash, and it’s slow due to the fact digging up objects from zodb is not fast.
But I guess it all bottles down to that you need to be smart when you planning the architecture of a huge website. Some content is better suited in a relational database and some in a object database. ZODB is not a magic bullet. It’s more a rusty blunt shovel that rather would like to have a retirement retreat to Hawaii.
So if you looking for a great framework for you smaller web project don’t look at Plone. It seems to work alright for larger organisations that would like an Intranet or a corporate website and do not want to run Sharepoint. But in most cases it seems to be a fairly stable solution since there are a lot of websites that has been running on Plone for over 10 years.
To be comfortable as a developer in Plone you probably have to give it around 2 years. I also believe you should be active in the community and snoop around source code to become a professional. But I think it’s the same thing whatever huge framework you would like to master.