Plone 6.0.4 released

Announcements
1

Release notes for Plone 6.0.4

If you want to jump straight in, here are two important links:

Highlights

Major changes since 6.0.3:

  • plone.app.event and plone.app.multilingual: Breaking dependency cleanup: move declaration of language independence of IEventBasic fields from plone.app.event to plone.app.multilingual.
  • plone.app.locales: Updated translations for es and eu.
  • plone.base: Check for container field / attribute when trying to create content with same id.
  • plone.restapi:
    • Apply a cache ruleset to the /@querystring-search endpoint.
    • Add UID to relationvalue_converter summary.
    • Add querystring_search GET method.
  • plone.schema:
    • Introduce extras plone.schema[supermodel] and plone.schema[schemaeditor].
    • The package now works in its vanilla installation as an addon for z3c.form, without any other plone dependencies.
  • plone.staticresources: Update to mockup 5.0.10. Fixes pat-recurrence UI issues.
  • Products.CMFPlone:
    • Add a last modification time to the resource registry.
      We update this when changing anything related: when changing the resource registry in its control panel or activating an add-on.
      This avoids needing a restart before seeing changes when you run in production mode.
    • Mockup TinyMCE settings: Fix URLs in TinyMCE external_plugins settings.

Volto frontend

The default frontend for new Plone 6 sites is Volto. Latest release is 16.20.4. See the changelog.
Note that this is a JavaScript frontend that you need to run in a separate process with NodeJS.

Also, existing Plone sites need some or more extensive changes to be upgraded before they can use the Volto Frontend. Please read the guide on migrating from Plone Classic UI to Volto.

Classic UI

The HTML based and server side rendered UI that was present in Plone 5.2 and earlier major Plone releases is still available and has also been updated and improved upon in Plone 6. Our documentation now refers to this frontend as 'Classic UI'. Support for Classic UI is especially relevant for existing Plone sites which for whatever reason or requirements are not yet ready to be upgraded to the Volto frontend.

Python compatibility

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

pip, buildout, setuptools

In Plone core we use these versions to install Plone:

pip==23.0.1
setuptools==67.6.1
wheel==0.40.0
zc.buildout==3.0.1

In general you are free to use whatever versions work for you, but these worked for us.

Note that setuptools 66 or higher is more strict with what versions it can recognize. If you run pip or buildout and it suddenly cannot find a package with a non-standard version, then this may be the cause.

Installation

For installation instructions, see the documentation.

Issues

If you find any issues, please report them in the main issue tracker.

5 Likes
2
3

Just a note: somehow the dependency to the package ZEO is gone since Plone 6.0.4 (or Zope 5.8.1) ... when updating my buildouts to extends=https://dist.plone.org/release/6.0.4/versions.cfg our recipe.plone.zeoserver part doesn't start anymore. I had to explicitely define

[zeoserver]
recipe = plone.recipe.zeoserver
eggs =
    ZEO
    ${buildout:eggs}

to make it work again.

You can test this with the following minimal buildout config:

[buildout]
extends = https://dist.plone.org/release/6.0.3/versions.cfg
parts = zeoserver
eggs = Plone

[zeoserver]
recipe = plone.recipe.zeoserver
eggs = ${buildout:eggs}

with this bin/zeoserver is running. If you bump the extended version to 6.0.4 you get

/home/plone_test/test/parts/zeoserver/bin/runzeo
/home/plone_text/.pyenv/versions/3.11.3/envs/py-3.11-plone_test/bin/python3.11: Error while finding module specification for 'ZEO.runzeo' (ModuleNotFoundError: No module named 'ZEO')

Adding ZEO to the zeoserver:eggs excplicitely fixes that.

4

For me, zeoserver works fine. What is the difference? Ah, I don't explicitly set the eggs. (I maybe should.) When I add an eggs option (in my case eggs = ${instance:eggs}) startup fails for me too. Does the script loose its own eggs?
Wait, no, it is something else. I always use bin/zeoserver in the buildout directory. ZEO is still in the script:

$ less bin/zeoserver 
...
sys.path[0:0] = [
  '/Users/maurits/shared-eggs/cp311/plone.recipe.zeoserver-2.0.3-py3.11.egg',
...
  '/Users/maurits/shared-eggs/cp311/ZEO-5.4.0-py3.11.egg',
...

So something funky is going on.
I wonder if it would help to add ZEO to the setup.py of the recipe. plone.recipe.zope2instance already has this.
Maybe open an issue. The recipe needs some love anyway: has not been updated in almost three years.

5

ZEO is defined in the sys.path[0:0] stuff but its missing in the following os.environ["PYTHONPATH"] section... before it was there.

EDIT: and you're right ... an issue on github would be the best.

6

Technically ZEO is not included in a pip install Zope and this is fine. ZEO is meant to be an additional feature, integrators has to add to a Zope installation.

Before 6.0.4 it was accidentally pulled in by some package. After we did the cleanup of the dependencies of many packages it dropped out.

If one needs ZEO, add ZEO to your projects requirements.txt or to the integration package pyproject.toml (or in older configurations to setup.py or setup.cfg).

At the end I propose to update our docs and that`s it.

It is a bit unfortunate that this happens unintentionally as a side effect in a bugfix release. OTOH the existence of ZEO was pure luck before.

7

@jensens you're absolutely right.

But instead of exlicitely defining ZEO as a dependency in my project I think the recipe plone.recipe.zeoserver should take care of this when I use it. I started fixing this yesterday in the recipe and will come up with a PR today.

2 Likes
8

Search results of tags 2nd page is still wrong ...

9

May you refer to an issue number?

1 Like