[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What's wrong with Plone?



Jonas Smedegaard wrote:
Hi all,

Skolelinux has decided to drop Plone and use eZ Publish instead, both
for the project website and a recommended CMS for schools.

No final decisions made, but we are looking strongly into it.

As I understand it (from the short meeting on the topic I participated
at the Skolelinux gathering in january) some reasons are political (bad
support of Skolelinux from core Plone guys, promise of good support from
eZ guys), and some reasons are technical.

Can anyone please help provide details on the technical shortcomings of
Plone?

Excerpts from "Summary of last week's meeting with eZ", to which you replied:

 First and foremost, the workflow is cumbersome. For several reasons I
 won't dwelve too deep in, translators of content today have to manually
 make a new instance of the page in question, and then send an email to
 one or more mailing lists to inform about the change. This, obviously,
 isn't optimal. It would be way better if the CMS could automatically
 notify the right mailing lists and inform about the changes. eZ
 features this.

 Secondly, to edit a web page, one has to log in with the Plone
 webinterface. (Yes, I know of the FTP-interface. It's way too buggy.)
 This alone scares a lot of potential contributors -- mainly the core
 developers -- from doing changes on the webpage at all. While this
 isn't necessarily true for everyone, it is a nuicance not to be able to
 work with the tools they preffer, which obviously is discouraging. eZ
 has support for WebDAV, and BÂrd Farstad is looking into adding support
 for Subversion in eZ, based on our request.


 Thirdly, eZ has a more sane way to handle content than Plone has. Plone
 gives you -- by default -- three options: to save the document as plain
 text, as HTML or as "structured text" (Zope-thingy). Once you have
 chosen a format, you have to stick to it. eZ saves everything
 internally as XML and offers only a *subset* of the HTML-code to the
 user. This enables them to create various input- and output-filters, so
 a document first edited by Joe in OpenOffice can later be edited by
 Jane in HTML -- and downloaded as a PDF for the web user.


 In addition, it's hard to sync the excellent documentation we have
 available, such as the "ICT-manual" and Klaus's great collection of
 notes, from DocBook in CVS to the web. Obviously, we don't want to
 change their working repository, so we want to be easily able to /sync/
 content from one source to the other.

Since the meeting, I have been busy with exams while letting people discuss the requirement specifications[1] which I posted to the www-int-mailing list. Bård Farstad replied and said "check" to most of the requirements listed, but was a tad vague on a few points -- mainly regarding Subversion support. I replied a few days later to clear things up, but he hasn't replied yet. He just got a daughter, so I guess (hope :) she has his priorities. :-)

I have now begun setting up a testbench to try to learn more of eZ, and to figure out in more detail what we eventually need eZ to do.

Please note that, contrary to what you have expressed several times, we have *not* ultimately decided on eZ, but they are offering their professional help with a system that seems to solve the problems we have. As mentioned earlier; if somebody else want to do so, they are free to come up with an offer.


~

[1] http://developer.skolelinux.no/dokumentasjon/requirement_specifications_ez.txt



Reply to: