Paul Roeland: An omnivore's perspective

published Oct 18, 2017

Talk by Paul Roeland at the Plone Conference 2017 in Barcelona.

This is an opinionated view on where we can learn, what we should stop doing, and how choices play out.

What do I mean with an omnivore's perspective? I work for a non-profit organisation. I have used Plone from version 0.99. I build sites, maintain them, renovate them, revive them, keep them, put them to sleep. So I do not build sites and then let someone else handle it. Some sites have content of over twelve years old. Some survive for three years even though the client promised me it would only be there for a year.

What systems do I use? Plone, Wordpress, Drupal, Wagtail, Mezzanine, Ghost, Pagekit, Sulu, Grav, Hugo. Those were the CMSes, well, sort of. I also use CiviVRM, Mailchimp, Odoo. These are ones that I have used in the last twelve months alone.

Some are very good. It helps that some are very new, so they have no balast.

Some good trends that I like:

  • design is getting simpler and simpler
  • designers got into their heads that there are mobile users
  • testing is done better
  • staging and production are known words for most systems

There is also the bad:

  • developer centric consultantware, where for any change you need to ask a developer, instead of having a lot of power already in your hands like in Plone
  • Some are so simple that it is basically brochureware. It works and looks fine as long as you have at most ten pages. So for a larger NGO: maybe not. 'Does it scale?' is really a good question here. Does it survive three years with 300 new pages a year, including several restructurings.

And of course the ugly:

  • The worst ideas resurface, like the inline editing that we had in Plone.
  • Once you publish it, you cannot change the url ever... Do you work in a real organisation?
  • One way street, also known as data grave. Please give me a way to export the data without resorting to crawling the site.
  • Security as an afterthought.

What Plone has that is really awesome and mostly not anywhere else:

  • placeful content: folders with stuff in them. This means you can find it. You can move a folder somewhere else including all its stuff. Again, a flat structure is fine for ten pages, but not for more.
  • collections: show a list of content somewhere else. Awesome, I want more and better of those.
  • workflow: just unrivalled. Others may have a bit, but not good.
  • content rules: if you do not use them, you are missing out.

Plone's happy place, where it shines, according to me:

  • long term content, that you are supposed to keep for years and years. Overkill for a site that is just there for a short term action.
  • skilled editors. They do not need to be full time editors, but they should be happy to at least spend half an hour to learn how the system works.
  • commitment from the organisation
  • where you can trust and empower your power users. They are your ambassadors.

Where can Plone approve? In the way that we approach content management as a whole. We often get bogged down in details in our daily work. But you are a captain and should act like it: Captain Janeway said 'there is coffee in that nebula, go for it,' instead of 'point the ship at direction 180.53 and warp 4.623.' Get the big picture. Tell developers (or Plone) what you want, not how exactly you want it.

Content life:

  • 20 percent is spent writing the content outside of the CMS. Say Word or an email or Google docs.
  • 5 percent of time is spent getting it into the CMS.
  • 75 percent is spent to re-arrange it, re-use, refer, tag, archive. In other words: content management. It is annoying if it takes twenty clicks to get anything done.

Content types:

  • Forget dexterity versus Archetypes for a moment.
  • You have text and images.
  • Embed: youtube, twitter, etc. It is there on basically every site.
  • Snippets and results. Extra things like 'people you bought this article, also bought these other three, so please by them as well'.
  • Office and PDF. People expect to see it this in the site. People do not see what the difference is between a Word file and an html page. Why is one opening in Word and another in the site? Make it easy for them with some integration. There are ways.
  • Composite pages. This is a hard problem. We had at least seven attempts, the last one Mosaic, which is on its way, but good be better. Remember: be a captain. Make it possible to say: item A is the most important, show items B and C if you have room, drop item D and E when you are on a phone. What if we all get extremely large screens or extremely small screens in your glasses? Do you really need to go through all your pages then?

Sub sites:

  • Folder, Composite and Theme.
  • limited navigation
  • handmade is good enough
  • If the sub site is too big, with too many non standard options, make it a separate site.


  • What You See Is What You Get?
  • Actually: What I See Is Most Likely Not What You Get
  • Instead, Markdown is fine for most sites. It is limited, but that is a strength. The editors are less tempted to paste a Word doc into it. A preview is nice.

Stop assuming that something will appear in the left column, because on mobile there may be only one column, or it will not appear at all.


  • Basically all form frameworks are sh*t.
  • PloneFormGen is Archetypes and no one is going to keep fixing the fields, so use collective.easyform.
  • A quick edit drag and drop page is nice, but form creation is for power editors, so it is fine if the interface is geeky. So focus on the end user, that the end result looks good.

System setup:

  • should be repeatable
  • containers are here to stay, whether Docker or something else. If you want to do it in a different way, we can say in docs that you are on your own. We should stop supporting all the different deployment strategies in the world.


  • Readability counts. It does not need to be shiny: I don't configure a site every day for hours.
  • TTW: allow theming override. A different color should be possible. Allow overriding the translation strings through the web, let the marketing people do that.
  • I don't want to do Javascript TTW, just on the command line with webpack or whatever. I was always in favour of TTW, but here: no.

Don't reinvent wheels. For example, one of the biggest problems in computer science: writing responsive emails. Integrate something like mosaico that has solved this.

My practical wishlist for users:

  • TinyMCE: use Markdown and raw
  • tiles and layout recipes
  • Make 'embed' easy.

Give me more:

  • smart media handling, without letting me handle it manually
  • consistency in UI
  • clevererer collections: can we have something that says: these three items are relevant for you?

Team player:

  • Good import and export should be in core. JSON dump is fine.
  • REST and GraphQL: good if we can have both.
  • Office integration when needed for intranet sites
  • although security is hard


  • For configuration can we move from XML to YAML? No, not JSON, as that is unreadable and unwritable too.
  • One Plone per Zope would be much easier.
  • A command line interface to do basic maintenance would be great.
  • roundtrip configuration: export config and import in another container. We sort of have this, but it is hard to find.
  • For power users, function is more important than form.
  • Warn me when updates are needed. Should be configurable. Probably not web downloadable updates, for security reasons.

Make it so!

Maybe you totally disagree, that is fine. Come talk to me and we can start a discussion. I am deeply partial to Plone and let's make it better.