What could justify the complexity of Plone?

Question

Plone is very complex. Zope2, Zope3, Five, ZCML, ZODB, ZEO, a whole bunch of acronyms and abbreviations.

It's hard to begin and the current state seems to be undecided. It is mainly based on Zope2, but incorporates Zope3 via Five. And there are XML config files everywhere.

Does the steep learning curve pay of? Is this complexity still justified today?

Background: I need a platform. Customers often need a CMS. I'm currently reading "Professional Plone Development", without prior knowledge of Plone.

The problem: Customers don't always want the same and you can't know beforehand. One thing is sure: They don't want the default theme of Plone. But any additional feature is a risk. You can't just start and say "If you want to see the complexity of Plone, you have to ask for it." when you don't know the system good enough to plan.

Convection

I would've left the "EDIT" label in, actually; it helps people coming in after the fact to know what might not have been present when some of the answers were composed. Without an edited flag, some of the answerers end up looking like they didn't read the question properly. Just a thought! – Bohrer

Answer 1

If you want to see the complexity of Plone, you have to ask for it. For most people, it's just not there. It installs in a couple of minutes through a one-click installer. Then it's one click to log in, one click to create a page, use a WYSYWIG editor, and one click to save. Everything is through an intuitive web GUI. Plone is a product.

If you want to use it as a "platform," then the platform is a stack of over one million lines of code which implements a complete content management suite. No one knows it all. However, all those "acronyms" and "files" are evidence of a software which is factored in components so that no one need know it all. You can get as deep or shallow in it as you need. If there's something you need for some aspect of content management, it's already there, you don't have to create it from scratch, and you can do it in a way that's consistent with a wide practice and review.

Mistrot

Answer 2

It's hard to answer your question without any background information. Is the complexity justified if you just want a blog? No. Is the complexity justified if you're building a company intranet for 400+ people? Yes. Is it a good investment if you're looking to be a consultant? Absolutely! There's a lot of Plone work out there, and it pays much better than the average PHP job.

I'd encourage you to clarify what you're trying to build, and ask the Plone forums for advice. Plone has a very mature and friendly community — and will absolutely let you know if what you're trying to do is a poor fit for Plone. You can of course do whatever you want with Plone, but there are some areas where it's the best solution available, other areas where it'll be a lot of work to change it to do something else.

Some background:

The reason for the complexity of Plone at this point in time is that it's moving to a more modern architecture. It's bridging both the old and the new approach right now, which adds some complexity until the transition is mostly complete.

Plone is doing this to avoid leaving their customers behind by breaking backwards compatibility, which they take very seriously — unlike other systems I could mention (but won't ;).

You care about your data, the Plone community cares about their data — and we'd like you to be able to upgrade to the new and better versions even when we're transitioning to a new architecture. This is one of the Plone community's strengths, but there is of course a penalty to pay for modifying the plane while it's flying, and that's a bit of temporary, extra complexity.

Furthermore, Plone as a community has a strong focus on security (compare it to any other system on the vulnerabilities reported), and a very professional culture that values good architecture, testing and reusability.

As an example, consider the current version of Plone being developed (what will become 4.0):

• It starts up 3-4 times faster than the current version.
• It uses about 20% less memory than the current version.
• There's a much, much easier types system in the works (Dexterity), which will reduce the complexity and speed up the system a lot, while keeping the same level of functionality
• The code base is already 20% smaller than the current shipping version, and getting even smaller.
• Early benchmarks of the new types system show a 5× speedup for content editing, and we haven't really started optimizing this part yet.

— Alexander Limi, Plone co-founder (and slightly biased ;)

Cotinga

Background: I need a platform. Customers often need a CMS. But most CMS are in languages I don't want to support or write additional features in. I'm currently reading "Professional Plone Development", without prior knowledge of Plone. – Convection

Answer 3

I found an anonymous comment here which is much better than that post itself, so I'm reposting it here in full, with a couple of typos corrected.

---

This summer my chess club asked me to make a new website, where the members of the board should be able to add news flashes, articles, ... Sounded like a CMS. Being a Python developer, I looked at Plone and bought the Aspeli book Professional Plone development (excellent written btw).

I took 3 weeks of my holiday the study the book and to setup a first mock up of the site.

After 3 weeks I realized that Plone has some very nice things but also some very frustrating things On the positivie side

• if you don't need to customize Plone, Plone is great in features and layout
• Plone has a good security model
• Plone has good off the shelf workflows
• Plone is multi language (what I needed)

On the downside

1. Plone is terrible slow. On my development platform (a 3 years old Pc with 512 MB RAM) it takes 30 seconds to launch Plone and it takes 10 to 15 seconds to reload a page
2. you need a lot of different technologies to customize or develop even the simplest things
3. TAL and Metal are not state of the art and not adapted to the OO design of Plone.
4. Acquisition by default is wrong. Acquisation can be very useful (for e.g. security) but it should be explicitly defined where needed. This is a design flaw
5. Plone does not distinguish between content and layout. This a serious design flaw. There is no reason to apply security settings and roles on e.g. cascading style sheet or the html that creates a 3 column layout and there is no reason why these elements should be in the ZODB and not on the filesystem
6. Plone does not distinguish between the web designer and the content editor/publisher, again a serious flaw. The content editor/publisher add/reviews content running on the live site. The web designer adds/modifies content types, forms and layout on the test server and ports it to the live server when ready. The security restrictions Plone put in place for the content editor should not be applied for the web designer, who has access to the filesystem on the server.
7. Plone does not distinguish between the graphical aspects and the programming aspects of a web designer. Graphical artists uses tools that only speak html, css and a little bit of javasccript, but no Python, adapters and other advanced programming concepts. As a consequence the complete skinning system in Plone is a nightmare

I assume that Plone is so slow because of points 4, 5, 6 and 7.

Points 6 and 7 made me dropping Plone. I looked around for other options and eventually decided to develop my own CMS on Pylons, which is blazingly fast compared to Plone. On the same development server I have a startup time of 1 second, and a reload page time is not measurable.

The site www.kosk.be is running (it is in Dutch). The CMS behind it, named Red Devil, will be launched as a separate open source project beginning next year

Ningpo

These downsides aren't valid, and weren't valid even in '09 when this answer was posted. – Unmake

@Unmake can you be more specific? Why aren't they valid? This other answer seems to address some of them: https://mcmap.net/q/841464/-what-could-justify-the-complexity-of-plone, but at least 1, 2, 4 and 7 are true, 3 is a matter of opinion, and I'd argue that 5 is mostly true at least "There is no reason to apply security settings and roles on e.g. cascading style sheet or the html that creates a 3 column layout and there is no reason why these elements should be in the ZODB" – Ningpo

1 is moderately true if you take no time to optimize it. But, then again, anything on the web needs careful attention to speed. 2 is true on the web, always. HTML + CSS + JavaScript + server-side language. 3 is horribly invalid, as PT / TAL / TALES is the best way I've ever seen to separate presentation from application logic. 4 is a matter of opinion. 5 is dependent on how you publish your content vs. layout. 6 is also dependent on your administration workflow and level of discipline. 7 is no different than any other web technology that serves dynamic content. – Unmake

@Unmake Some better "hello world" should not need "attention to speed". It should just work. – K

Answer 4

I see four things that can justify an investment of time in using Plone:

• Plone has a large and helpful community. Most of the things you need, somebody else
  already did at some time in the past. He probably asked some questions and got helpful answers, or he wrote a tutorial. Usually that leaves traces easy to find. about how he did it.
• You won't need to understand the whole complexity for many of your customizing needs.
• Plone developers are aware of their complex stack, and are discussing how this can be reduced. Plone has proven in the past that it is able to renew itself and drop old infrastructure in a clean way with defined deprecation phases.
• There are many local user groups with helpful people.

Oh wait, I was told the plone developer meetings are one of the best! Like that one

Ludwick

Answer 5

From a system administrator standpoint, Plone is just shy of being the absolute devil. Upgrading, maintaining, and installing where you want to install things is all more painful than necessary on the Linux platform. That's just my two cents though, and why I typically prefer to avoid the Zope/Plone stack.

Note: it's better with newer releases, but older releases.... ugh

Traweek

Answer 6

Accretion.

Distraint

Answer 7

About the comment here I think Plone doesn't work like that (at least not anymore).

1 - Plone is somehow slower than other CMS solutions indeed, but from the out-of-the-box setup to a Apache-Varnish-Zope-Relstorage solution, there is a lot of optimization space.

2 - That is true. The answer here kind of explains it, but indeed Plone is a complex animal.

3 - Not sure what you mean. TAL Path expressions are based on the concept of object attribute traversal. Seems OO to me.

4 - True. Although after you understand how Acquisition works, it stays out of your way. And in Plone not many things depend on Acquisition, I guess.

5 - Not true. Zope Page Templates are all about separating content from presentation. The fact that content and presentation can be viewed from the ZODB (and actually most of the templates stay in the filesystem, you just see a "view" of them in the ZODB) is more related to the fact that the ZODB is a big object database - which in turn does not mean that they are all content. Everything in "pure" OO system is an object, it is just the kind of object (presentation objects, content object, etc) that matters.

6 - Plone does distinguish between webdesigners and content creators. The designers do all customizations (templates, CSSs, JSs,etc) and then content creators create the content using Plone UI. The point here is that Plone is mainly a CMS, which means that content creators are supposed to be laymen in terms of design.

7 - Partially true. Considering that the UI structure won't change, all presentation specification is contained in CSS files. If the UI structure needs to change, the designer might work with a plogrammer :-) to adequate the templates.

I guess in no system that outputs dynamic pages the designer is completely free to speak only HTML, CSS and JS, and leave out some other technology, be it PHP, Python, ASP or Java. If he does, there will be definitely a programmer that will get the HTML,CSS and JS from the designer and "dynamize it". This model definitely exists in Plone.

Missilery

Answer 8

Don't use it, if you don't have to. The whole ZOPE universe is a dinosaur. Grown for ages, has collected lots of cruft and rust. Many things would be done completely different nowadays. Overly complex for most stuff, hard to handle for complex stuff. It's the opposite of slim and scalable design. And for seriously fixing this, I don't see the necessary manpower involved in the project.

Sorry for the harsh words, I also wish it would be any better.

K