Plone 6.0.0rc1 released

The first release candidate of Plone 6 is ready!
For technical wizards who want to jump straight in, here are two important links:


Major changes since 6.0.0b3:

  • Various packages: updates to support Python 3.11. See below.

  • Zope 5.7: This feature release adds full support for Python 3.11 and a ZPublisher encoder for inputting JSON data.
    See the Zope changelog for details.

  • zc.buildout: After long development this has a final release. We use version 3.0.1, which now works nicely with latest pip (using 22.3.1).
    Note that it is usually fine if you use different versions of zc.buildout, pip, setuptools, and wheel. We just pin versions that we know work at the moment.

  • plone.restapi:

    • Added @upgrade endpoint to preview or run an upgrade of a Plone instance.

    • Added @rules endpoint with GET/POST/DELETE/PATCH.

    • Added link integrity support for slate blocks.

  • plone.scale: Add support for animated GIFs.

Volto frontend

The default frontend for Plone 6 is Volto. Latest release is 16.0.0-rc.1.
See the changelog.

Python compatibility

This release supports Python 3.8, 3.9, 3.10, and 3.11.

Python 3.11.0 was released in October and we are proud to already be able to say Plone supports it! All tests pass.
This is expected to be faster than other Python versions.
Note that not all add-ons may work yet on 3.11, but in most cases the needed changes should be small.

A big thank you for this goes to the Zope part of the Plone community, especially Jens Vagelpohl and Michael Howitz.
The trickiest parts of the fixes for 3.11 were needed on the Zope level, for example RestrictedPython and packages with C code.

A word of warning: Plone on 3.11 should work fine on Linux, but you may have trouble installing it on Windows and Mac.
Forgive me for using some technical terms here.
The problem is Python packages that have C code. Not all these packages may have "wheels" (a Python distribution file) available for your operating system and architecture.

  • On Windows you may not be able to install the lxml dependency. A new 4.9.2 release should fix this.

  • On Mac, a package may have a wheel for the Intel architecture and not for ARM, or the other way around, or your Mac may need an unavailable "universal2" wheel.

In all cases, if you have the right compilers and other development tools available, then you should be able to get it working on Windows and Mac, but this can be tricky. If you don't want to spend hours, you may want to wait a bit.


For installation instructions, see the documentation.
This documentation is under development, but this should get you up and running. No worries.


Sorry! My mistake! Except for clicking the tag, the search result on the second page is not working correctly. Everything works.

Many thanks

My Upgrade fails with meaningless hints:

2022-11-21 09:16:28,185 INFO    [Zope:42][MainThread] Ready to handle requests
2022-11-21 09:16:28,187 INFO    [waitress:486][MainThread] Serving on
/devel/migration/venv/lib/python3.10/site-packages/Products/CMFCore/ UserWarning: DirectoryView plone_templates refers to a non-existing path 'Products.CMFPlone:skins/plone_templates'
  warn('DirectoryView %s refers to a non-existing path %r' %
2022-11-21 09:16:55,372 INFO    [][waitress-2] Dry run selected.
2022-11-21 09:16:55,372 INFO    [][waitress-2] Starting the migration from version: 6004
2022-11-21 09:16:55,372 INFO    [][waitress-2] End of upgrade path, main migration has finished.
2022-11-21 09:16:55,372 ERROR   [][waitress-2] The upgrade path did NOT reach current version.
2022-11-21 09:16:55,372 ERROR   [][waitress-2] Migration has failed
2022-11-21 09:16:55,372 INFO    [][waitress-2] Dry run selected, transaction aborted

My Zope/Plone runs in debug mode. Is there a way to enable more infos to get specific informations what fails?

If i use a buildout installation, sidenote: the output above come from a pip installation, then i get a detail traceback:

2022-11-21 10:09:36,166 ERROR   [][waitress-2] Upgrade aborted. Error:
Traceback (most recent call last):
  File "/devel/migration-buildout/.buildout/eggs/cp310/Products.CMFPlone-6.0.0rc1-py3.10.egg/Products/CMFPlone/", line 298, in upgrade
  File "/devel/migration-buildout/.buildout/eggs/cp310/Products.GenericSetup-2.2.0-py3.10.egg/Products/GenericSetup/", line 185, in doStep
  File "/devel/migration-buildout/.buildout/eggs/cp310/", line 350, in update_catalog_for_image_scales
    update_catalog_metadata(context, column=column)
  File "/devel/migration-buildout/.buildout/eggs/cp310/", line 386, in update_catalog_metadata
    obj = brain.getObject()
  File "/devel/migration-buildout/.buildout/eggs/cp310/Products.ZCatalog-6.3-py3.10.egg/Products/ZCatalog/", line 91, in getObject
    return parent.restrictedTraverse(path[-1])
  File "/devel/migration-buildout/.buildout/eggs/cp310/Zope-5.7-py3.10.egg/OFS/", line 364, in restrictedTraverse
    return self.unrestrictedTraverse(path, default, restricted=True)
  File "/devel/migration-buildout/.buildout/eggs/cp310/Zope-5.7-py3.10.egg/OFS/", line 347, in unrestrictedTraverse
    raise e
  File "/devel/migration-buildout/.buildout/eggs/cp310/Zope-5.7-py3.10.egg/OFS/", line 301, in unrestrictedTraverse
    next = obj[name]
  File "/devel/migration-buildout/.buildout/eggs/cp310/plone.folder-3.1.0-py3.10.egg/plone/folder/", line 235, in __getitem__
    raise KeyError(key)
KeyError: 'copy_of_folie4.png'
[8] > /devel/migration-buildout/.buildout/eggs/cp310/plone.folder-3.1.0-py3.10.egg/plone/folder/
-> raise KeyError(key)

Is there a difference between pip and buildout installations?

It was a catalog error. I clear the catalog, run the upgrade and recatalog my portal. Now, all is up-to-date. I will check this procedure for the pip installation.

The upgrade in my pip installation enviroment fails still.

I think the code should catch this KeyError and ignore catalog brains that give problems. I have created a PR: Catch KeyError when getting object from a brain, and ignore this brain. by mauritsvanrees · Pull Request #306 · plone/ · GitHub

But updating the catalog is a good way to solve this. Or try collective.catalogcleanup.

I have no idea why it would still fail in your pip installation. The installation method should not matter. Are you sure pip and buildout use the same Plone database? Or do you need to rebuild the catalog in the pip installation too?

I had copy my Data.fs from original source in both installations. I clear the catalog in both installations. I run portal-upgrade in both installations. Yes, the difference still exists. I will investigate, perhaps a dependecies error from a third-package...


I see a difference in the Upgrade UI between PIP and buildout Installation, the single steps and the description is missing via PIP:

via Buildout:

via PIP

My PIP Installation Steps:

mkdir devfolder && cd devfolder
touch requirements.txt
touch constraints.txt
touch instance.yaml
touch mx.ini
python3 -m venv ./venv
source venv/bin/activate
pip install mxdev

requirements.txt :

-c constraints.txt
-e ../my.addon1
-e ../my.addon2




requirements-in = requirements.txt
requirements-out = requirements-mxdev.txt
contraints-out = constraints-mxdev.txt

version-overrides =


  initial_user_name: "admin"
  initial_user_password: "admin"
  debug_mode: true
  verbose_security: true
    package_includes: [

  environment: {
    "zope_i18n_compile_mo_files": true,
    "TZ": "Europe/Berlin",
    "CHAMELEON_CACHE": "{{ cookiecutter.location_clienthome }}/cache",
    "MAILHOST_QUEUE": "{{ cookiecutter.location_clienthome }}/mailqueue",
    "TMPDIR": "{{ cookiecutter.location_clienthome }}/tmp",
    "TESSDATA_PREFIX" : "/usr/share/tesseract-ocr/4.00/tessdata"

  db_storage: "direct"
  db_blobs_location: "{{ cookiecutter.location_clienthome }}/blobstorage"
mxdev -c mx.ini
pip install -r requirements-mxdev.txt
cookiecutter -f --no-input --config-file instance.yaml
runwsgi -v instance/etc/zope.ini

Buildout produces configs that are different from pip/cookiecutter/zope.mkinstance. Try to replace the various zope.conf and ini and other setting from pip installation to buildout and see if something changes.

Or just find the buildout setting that let the traceback printed out and apply to the pip environment.

I find the mistake. That was my fault. I must explicit include the package Plone in my requirements.txt

-c constraints.txt
-e ../my.addon1
-e ../my.addon2

Would you please let me know where I may report a bug with the tags search result on page two?

I can report having installed Plone-6.0.0rc1 with pip on Windows 10 as well as on Debian 11. Both installed with Python 3.9 as well as with 3.10.

1 Like


I have released plone.namedfile 6.0.0 with a few bug fixes, especially that in some cases image scaling produces a database write every time you request the original. See the changelog. You may want to add a version override in your buildout or constraints.

I have updated this version/constraint in, the "permanent pending" release.

Also, in the frontend you can now use Volto 16.0.0 final! See the complete changelog compared to Volto 15.