Recently I upgraded from Plone 4.2 to Plone 4.3.

Recently at the behest of Liz Leddy, I upgraded from Plone 4.2 to Plone 4.3. It’s been a while since I had the pleasure, so I thought I’d make some notes: for myself, the AI Team and anyone else interested in the process.


  1. is one of the oldest Plone sites in existence, having been launched circa Plone 1 and upgraded in place ever since.
  2. It functions remarkably well, given #1.
  3. It’s not without its issues, but all of them are manageable — for some value of manageable.
  4. It’s often very time consuming to work on.


  1. The first step is always to get a local copy:

    $ git clone
    $ cd Products.PloneOrg
    $ cp buildout.cfg
  2. Edit buildout.cfg to extend the database.cfg:

    # Rename to buildout.cfg and uncomment one of the profiles below
    extends =
    # Plone only, unthemed
    #    conf/develop.cfg
    # Copy data local (with account)
    # Production (for use on server)
    #    conf/production.cfg
    # Staging (for use on server)
    # and Deployment (for use by Jenkins, admins and developers),
    #   fabric can be added to any of primary configurations
    #    conf/staging.cfg
    #    conf/fabric.cfg
    # Developer Database Drop; makes developer-friendly copies
    # of's content.
    #    conf/devdrop.cfg
  3. Bootstrap and run Buildout:

    $ virtualenv-2.7 .
    $ bin/pip install zc.buildout
    $ bin/buildout
  4. Make the appropriate configuration changes i.e. change extends from 4.2 to 4.3:

    develop = .
    extends =
    extensions =
    #    buildout.dumppickedversions
    versions = versions
    sources-dir = sources
    eggs =
    # get us a user and group variable
    recipe = gocept.recipe.env
    recipe = collective.recipe.grp
  5. Run the upgrade locally. With data this takes about 45 minutes to an hour [1].

alternate text
  1. If the upgrade succeeds, you are ready to launch. If it fails, fix the errors before proceeding.


We know from upgrading locally that the process will take about 45 minutes to an hour, so you should allocate about 2 hours to do the upgrade.

  1. Announce the upgrade: preferably a week or two in advance. The plone-developers and plone-users lists are probably sufficient, but you can create a news item too if you are feeling extra-ambitious. I only had a small window to perform this maintenance, so I skipped this step and proceeded directly to the next one.
  2. Add a status message to to indicate a maintenance window is in progress. I chose to customize the main_template to accomplish this, but ideally we’d have some functionality in Plone that allowed site administrators to easily configure status messages.
alternate text
  1. Disable logins. Since the upgrade takes a long time, we don’t want content being edited during this process. I chose to use David Glick’s technique of disabling PAS. I moved the ldap authentication plugin to the Active Plugin list, thus disabling PAS such that only ZODB users could login. But ideally we’d have some feature in Plone to allow site administrators to disable logins.
alternate text
  1. Run the upgrade. I forgot to mention earlier something very important: On, you can’t access Zope from the internet. And you can’t run the upgrade without accessing Zope. Hence run the following command to access the server, then access Plone via http://localhost:8080:

    $ ssh -L 8080:
  2. After the upgrade finishes, click around to make sure you didn’t break anything. In my case, I broke something — I normally move portal_skins/custom out of the way before upgrading, but this time I forgot. And when I experienced minor JavaScript issues, I forgot to examine custom; which currently looks like this:

alternate text

Even if I had remembered, I didn’t want to spend the next few hours examining database customizations. Fortunately, before I realized I had forgotten to check custom, I emailed the plone-developers list — and Nathan Van Gheem to the rescue! He fixed some JavaScript in custom, then I cleared the cache(s). Ideally Plone would report on database customizations during the upgrade process: to indicate the potential for breakage and encourage the site administrator to round-trip those customizations back to the file system.


That’s it! I hope this helps folks wrap their head around the upgrade process. A few closing thoughts:

  • With Cloudflare in front, we probably don’t need Varnish anymore.
  • Leaving a note in portal_skins/custom to encourage folks to “please keep this area clean” — does not work.
  • anyone? I don’t know the future of and I have mixed feelings about it: on the one hand, I’m proud to help maintain such an old and venerable system. On the other hand, I think should be retired in a way similar to What do you think?
[1]It shouldn’t take this long. See: for a discussion about this issue.