Plone 6.0.0 pre alpha available


This is a PRE ALPHA release.
Do NOT use this on production, unless you are a Plone core developer and know what you are doing.

But we are happy when you test a Plone add-on with these versions, or try it out on a local development machine.


You can find the release files in this folder:

This is an experiment.
The folder name may change.
The folder may disappear.
The versions may be updated without notice.
Think of it as a nightly build.

If the experiment works, we might actually add a 5.2-dev as well, to make it easier to test an upcoming Plone 5.2 release.

Why no alpha release?

There is no integration with Volto yet, the new frontend for Plone, built in React.
Since Plone 6 is Volto, the Plone Steering Circle was against an alpha release without Volto integration.

But to make Volto integration easier, some form of a release is useful.
When a pure React developer needs to install the Plone backend with Buildout and several source checkouts, this may be a big hurdle.
Having a central versions/constraints list eases this.

It also eases trying out 'pip install Plone'.


The most important files in the folder are:

  • requirements.txt: pip requirements file to get Buildout working
  • versions.cfg: versions file for Buildout
  • constraints.txt: constraints file for 'pip install Plone'
  • Plone-6.0.0a1.dev0-py3-none-any.whl, Products.CMFPlone-6.0.0a1.dev0.tar.gz, etc: intermediary releases, only available here, NOT on PyPI.

The intermediary releases signal that this is an unofficial, pre-alpha release.
These development version numbers are not accepted when uploading to PyPI, but otherwise they work just fine.


Sample buildout config:

extends =
# find-links is needed for the internal Plone and Products.CMFPlone releases:
find-links =
parts = instance

recipe = plone.recipe.zope2instance
eggs = Plone
user = admin:admin
zodb-temporary-storage = off

Install it with:

python3.9 -m venv .
bin/pip install -r
bin/instance fg


You might need a rather old version of pip.
See discussion here:

python3.9 -m venv .
bin/python -m pip install "pip==19.2.3"
bin/pip install -U setuptools wheel
bin/pip install Plone -c -f

Latest pip can work as well, but you may need to use the legacy resolver:

bin/pip install Plone -c -f --use-deprecated legacy-resolver

Having a dev / pre-alpha release helps in testing this out as well.


Some highlights of this release are:

  • Removed Python 2 and Archetypes compatibility.
  • Support only for Python 3.7, 3.8 and 3.9.
  • Zope 5.3
  • Removed CMFQuickInstallerTool dependency.
  • Removed Products.CMFFormController dependency and removed all remaining form controller scripts (cpy/vpy).
  • Removed dependency on Products.TemporaryFolder.
    Note: in your plone.recipe.zope2instance buildout part, you must set zodb-temporary-storage = off,
    otherwise you get errors when starting Plone.
  • Extensive overhaul of Plone ui elements based on Bootstrap 5 components.
  • Introduction of icon resolver with use of icon_expr definitions.
  • Barceloneta LTS theme
  • Add control panel for relations
  • Add plone.api.relation module to ease using relations.
  • Use Dexterity for the Plone Site root object.

and Plone object is a DX object!

I got it installed with buildout in about 4 minutes.

What about a

curl | bash



Okay, I forgot to parse the CMFPlone changelog, which obviously contains a few interesting items. :slight_smile: I have edited the highlights in my original post.

1 Like

It looks good, i tested it with my custom local Plone 6 Dev System. I run the buildout via instructions above, copy my Data.fs and blobstorage... and voilà, my site is up and running, in less than 5 minutes!
Great Job, Thanks!

I think plone.restapi profile should be installed by default:

1 Like

My opinion: for Volto yes, for Plone Classic no.

Silly me: I forgot to create a release of So you would miss at least the upgrade step for the dexterity site root. Minor detail. :wink:
No problem for a new site, but for existing sites you need it. = 2.0.40 is now available, and the versions/constraints updated (beware of caching).

1 Like

I did a quick test with our long-running project Buildout and migration process worked without issues. Some CSS/JS functionality specific to Plone 5 is possibly broken...requires further investigations...

If Volto is the default UI....
wouldn't that mean plone.restapi by default too?


The idea (not implemented yet) is that when creating a Plone Site you can choose to create either a Volto site or a Plone Classic site. When you choose Plone Classic, plone.restapi is not needed (but it offers opportunities of course, and can be installed later.)

My 2 cents:

  • plone.restapi should be enabled by default, even for Classic sites
  • plone.volto is the one that would not be installed if Classic UI is selected

I think every package that is not needed, should not be installed. Reduce the complexity.


and so the confusion starts.

Just release two downloads "Plone Volto 6.0" and "Plone Classic 6.0" and save the whole community a lot of pain down the track answering questions, and save a lot of confusion for anyone who might want to actually join the community or start a new plone site

You'd only have to have two different start profiles and point to two slightly reordered doc builds. And marketing would be a whole lot easier.

If I am not mistaken plone.restapi will be enabled even if it is not installed in the control panel. Therefore we would either have to put lots of effort into plone.restapi or we should enable it by default. What we have right now does not help either way IMHO.


We may want to split this into a new topic, but I don't know how to do that, or I don't have the enough permissions.

Currently, installing plone.restapi does the following:

  • Set a few permissions, for example allowing anonymous users to use the restapi.
  • Install a PAS plugin, for the JWT authentication token.
  • Register a browser layer. This does... I don't know what it does. Something confusing with the Dexterity types control panel. I expected something else. Seems a detail that we can ignore in this little discussion.

Looks like: when you don't install it, anonymous users cannot use the restapi, and they cannot login to it either. This seems fine for Plone Classic.
The restapi endpoints are still available then, and you can call them from Python code. I just tried with collective.exportimport in 4.3, which uses plone.restapi for exporting, and this works fine even when I don't have plone.restapi installed in the UI. That is interesting to know.

I don't know what the "lots of effort" would be. Maybe keeping the dexterity types control panel working?

I do not think we want plone.restapi a dependecy of Products.CMFPlone (circular dependencies, you know...). So it is part of the Plone package which is in fact only a setup.cfg. So, with our current setup this is not easy possible.

But: Thinking further it would be great to have two profile packages, one for volto (I think this will be plone.volto (correct me if I am wrong) and one for plone.classicui.

Then we can discuss to have it installed by defaut (IMO keep it reduced and do not install it).

1 Like

I wonder why is it like this in the first place. Can't we have a browser layer for plone.restapi and register all the endpoints on it, in order to fully enable/disable restapi TTW?

See [plone.restapi] Default configuration questions

1 Like

We do have. Both:

We just need to figure out, how we make IPloneRestapiLayer the default one, in order not to break backward compatibility / existing custom endpoints within add-ons.

constraints.txt is broken now:

ERROR: Invalid requirement: 'In pre alpha stage we need a find-links, to find internal non-PyPI releases.' (from line 3 of
WARNING: You are using pip version 21.0.1; however, version 21.2.4 is available.
You should consider upgrading via the '/plone/backend/bin/python3 -m pip install --upgrade pip' command.

Plone Foundation Code of Conduct