Deciding if Plone would fit our needs for a CMS

Hi. We've been a straight up Drupal shop for many years specializing in e-learning and maintaining an in house LMS/CMS hybrid built on top of Drupal. Each new project require us to set up a new Drupal site based off our custom LMS/CMS. Everything is glued together with a lot of Drupal "proprietary" tech, like a SSO implementation and site management only found in Drupal-land. Since our current infrastructure require a lot of Drupal expertise - all of our developers are often tied to maintaining and administration, which is of course not optimal for keeping developers happy in the long run.

Our new strategy then is to move most of our in house needs to off the shelf products, and focus our development efforts where we don't have off the self products that cover our needs instead. For instance Plone and Moodle could serve our requirements for a CMS and LMS. We will be running several houndred CMS sites down the road, so ease of maintaining, setting up new sites and upgrading without breaking content is critical. We also need good support for standardized SSO infrastructure, like CAS. Preferable we would like to "outsource" most administration tasks to operation or support personnel so our developers can go back to programming. The ideal CMS must fit our needs with as little customization as possible, be user friendly and not require much attention from a developer.

Could Plone fit our needs for a CMS? We also have members in our team that favor WordPress, I haven't had much experience with it and we haven't decided anything so the table is open for ideas. Thanks in advance.

That's a hard question to answer without knowing the specific requirements of your projects.

There are many things that are great about Plone but generally Plone excells in the following areas:

  • Security and Access-Control
  • Workflow-driven, collaborative management of content
  • Limitless Expandability: The modular and open component architecture of Plone allows you to change or extend Plone in every respect

Being able to implement almosty everything with Plone does not mean you should do that. For many requirements there are better systems. So it all comes down to what specifically you want to implement.

About the issues you mention explicitly:

  • CAS: There is a addon for authentication against CAS ( It is now very new but neither is CAS.
  • Upgrades: You can upgrade Plone-Installations between versions while maintaining all your content and settings. Migrationg sites with a lot of custom code and addons can be much harder though.
  • Maintenance is generally low if you have a decent setup, we have sites running for years without any real maintenance (except for the occasional hotfix)
  • Setting up new sites: You can create as many Plone-sites in a Zope instance as you like. If you want to do that or set them up separately depends on your requirements. Mosty people usually setup new sites for each project. Setup of a new site takes only some minutes for us. If you do everything by hand and do not use any templates you can waste hours though.

I suggest you:

If your developers what to get a deeper understanding how developing custom features with Plone is like I suggest they work through

An then you can come back here with more specific questions :slight_smile:


Thank you. I really appreciate your input. We definitively need to do a hands on evaluation and read up to get the proper feel for the CMS. It's possible I am asking you a bit dumb and premature questions here, but.

Do you always upgrade in a dedicated staging environment before upgrading live in production, or are there exceptions for instance with minor updates?

Say we choose multisite in Plone (instead of multiple Plone instances in Zope), do frontend developers still have full flexibility in customizing each sites html, css and javascript? And would a Plone instance with multisites "in the hundreds" still handle well on a single server? We do host an increasing number of sites/projects, but a majority of the sites are low traffic with some exceptions.

From the business and deployment prospective: if you are serious then you don't want to deal with Joomla, Drupal or Wordpress in any way unless you have enough resources for patching your sites every other day or explaining your customers why their sites have been hacked again..and compare this to the security record of Plone.

Regarding your high-level requirements: Plone feels like a fit. You must evaluate Plone or get in touch with Plone people for nailing down your requirements. Philip mentioned already your options.

Apart from that regarding your question about best strategies for testing/staging etc: this question is independent of Plone. A testing/staging/production setup and process should be true for any application, for any setup, for any deployment.

Quick summary

  • seperate zope per site

    • maxium flexibility. Different sofware versions for every site.
    • uses most ram.
  • shared zope, seperate plones

    • same software but can themes and a lot of custom code TTW so sites can be reasonably different
    • uses less RAM overall but each zope instance can start using a lot.
    • if you mount each site in a different DB you can control RAM somewhat.
  • shared zope and shared plone - e.g lineage

    • can have seperate themes but theme management and editing is shared.
    • lots of things shared like site settings, installed plugins and users.
    • uses a shared index so no way to have seperate control over memory usage

I think there are examples of people running hundreds of sites in each of these configurations.


For client-sites we always test a upgrade on a test- or staging-server. When that works fine, we usually do the upgrades in production. For smaller sites there is normally no downtime for visitors.

Big upgrades (like migrating a 100GB site with plenty of addons and custom code from Plone 4 to Plone 5 and Archetypes to Dexterity) can be a different story though.

1 Like

Its security record and fewer yearly updates does goes in favor for less maintenance burden with Plone for sure. Drupal did have a couple of high vulnerabilities just recently, and hot patching in out of office hours is not a pleasure. WordPress does have automatic updating for minor versions enabled by default, but I guess you don't get past having a QA process, staging->production, for updates when maintaining many WordPress installations.

Thanks for the input everyone. :grinning:

… and then, suddenly, they site is broken ( I have fixes a few sites where the user claims: I did nothing).

Yeah, that's a scenario I am fearing about WordPress, and that we ends up with just as much maintenance burden as before. :face_with_head_bandage:

Fun fact:

All apps get automatic updates right.
CMSes sometimes get updates right.

1 Like