Plone 4.3.18 soft-released

Plone 4.3.18 has been soft-released. Please give it a try and let me know if there are any critical issues.

For those who haven't run across soft-releases before, this is the
last step before the final release. Because things haven't been
finalized yet, some packages may change between now and the release. It
is not recommended to use soft-releases in production.


Zope2: 2.13.27 β†’ 2.13.28

plone.recipe.zope2instance: 4.3 β†’ 4.4.0
New features:

- Added support for setting `instance-home` option.

- Added support for setting CGI environment variables.

Bug fixes:

- Regard 'parsed_version' of setuptools > 38.7.0 does not return
  iterable anymore, fixes #37.

Plone: 4.3.17 β†’ 4.3.18
New features:

- Release Plone 4.3.18

Products.Archetypes: 1.9.17 β†’ 1.9.18
Bug fixes:

- Make sure the 'at_ordered_refs' dict changes are persisted when setting
  references by manually setting '_p_changed=1'.

Products.CMFPlone: 4.3.17 β†’ 4.3.18
Bug fixes:

- Do not include too new upgrades when upgrading Plone Site.
  Otherwise the Plone Site ends up at a newer version that the filesystem code supports,
  giving an error when upgrading, and resulting in possibly missed upgrades later.
  Fixes `issue 2377 <>`_.

- Unflakied a unit test.

Products.PlonePAS: 5.0.15 β†’ 5.1.0
New features:

- Notify PropertiesUpdated event when member properties are changed

collective.monkeypatcher: 1.1.3 β†’ 1.1.4
Bug fixes:

- Fix import for Python 3
  [pbauer] 2.3.17 β†’ 2.3.18
Bug fixes:

- Do not use ``rel="tag"`` attribute on the keywords viewlet as the referenced document is not a tag definition but a search result;
  use ``rel="nofollow"`` instead to avoid search crawlers hammering our sites backend.
  [hvelarde] 1.2.10 β†’ 1.2.11
Bug fixes:

- Python 3 fixes
  [pbauer] 1.4.4 β†’ 1.4.5

plone.cachepurging: 1.0.14 β†’ 1.0.15
Bug fixes:

- consider purging to be enabled when it's enabled (even if no servers are listed)

plone.folder: 1.0.10 β†’ 1.0.11
New features:

- Improve logging in case ordered index is not consistent

Bug fixes:

- Remove ancient buildout config

- Replace deprecated testing assertion calls

plone.api: 1.8.3 β†’ 1.8.4
Bug fixes:

- Call ``processForm`` with ``{None: None}`` dict as values.
  This prevents ``processForm`` using ``REQUEST.form`` and overwriting
  values already set by ``invokeFactory``.
  Fixes `issue 99 <>`_.

- Simplification/minor speedup:
  Permissions checks now directly use AccessControl.
  Technical its now exact the same as before.
  Before a tool lookup was needed, calling a utility function, calling AccessControl.

I have created a pull request updating various dependencies with bug fix releases:

please review.

@esteele . Updated two sites from 4.3.17, seems to work fine. A few things:

  • the versions.cfg has a 'spurrious' mockup =2.7.3 pin at the end of the file, seems a bit odd there with different = alignment, unsorted and wasn't pinned.

  • plone.portlets has been pinned to 2.3.X , but it should be 2.2.X as it breaks the calendar portlet in Plone 4. See

  • zope.ramcache pin ha increased from 1.0 to 2.2.0 , but this pulls in a not pinned persistent , show-picked-versions says:

Required by:


persistent =

The persistent package on pypi has this in the header:

Use of this standalone persistent release is not recommended or supported with ZODB < 3.11. ZODB 3.10 and earlier bundle their own version of the persistent package.

zope.ramcache 2 seems to have fixes according to the comment in the versions.cfg but this persistent is maybe a bit too high for Plone 4?

is not; we have been using it in production for some time now in many sites.

@esteele I'm almost there; I had to follow a more conservative approach as some tests failed on my first attempt and it seems that Products.CMFCore = 2.2.12 is the one to blame.

I was checking the changelog and I think it could be related to the catalog optimization feature introduced in 2.2.11 by @gforcada, as part of PLIP 1343 (assimilate collective.indexing).

but, never mind, I think we can live with the version unchanged.

zope.testrunner = 4.4.10 caused some regressions also as @gforcada already warned.

the pull request is ready to be merged.

That probably means there are layer leaks in the tests as the major change that induces is mucking with the layer ordering to better reuse layer setups across the layers.

@esteele Any news yet on a 4.3.18 final release?

I've updated the version pins in the pending release (Thanks @hvelarde and @fredvd!).

I would like to add some of the security headers to Plone, so we can serve them out of the box.

I'll try to create a pull request with that soon.

@esteele I think we can leave this for Plone 4.3.19, if we ever get into that version:

tomorrow I'll try to add that for Plone 5.1 and 5.2 also.

I just realized that I'd pushed those last updates to "4.3.18--pending" instead of "4.3.18-pending". Can someone give me a quick sanity check on and I'll push it to final today.

@esteele With zope.ramcache 2.2.0 in the versions.cfg there's still an unpinned dependency now on the Persistent package. If we want to include a newer zope.ramcache we'll also have to add a pin for Persistent, the latest version is 4.3.0 with some more fixes compared to the that was mentionned earlier in this thread.

@hvelarde wrote it runs fine on their production servers, but according to the Persistent stand alone package documentation this version of persistent shouldn't be used with the ZODB<3.11, Plone 4.3.18 uses ZODB3 3.10.7 which has its own version of persistent included.

I asked @mauritsvanrees a while what could be the possible risks even though it seems to work fine at first. What could happen is that once you upgrade to this persistent package and it creates newer persistent structures in your ZODB you cannot go back to the previous Persistent if severe issues with this 4.x version are discovered later on. But we simply don't know (yet).

There's a fine line between essential bug fixes for an maintenance release and 'improvement' fixes that might inflict compatibility issues and new problems on existing Plone 4.3 installations and their maintainers.

I still think this fix might cross that line for the maintenance release cycle we're in with Plone 4.3 and more feedback from others who are knowledgable on what really is in Persistent 4.X is desirable.

1 Like

thanks for your deep analysis, Fred; we've been using zope.ramcache = 2.2.0 for almost 4 months on our busiest sites with absolutely no issues; this includes magazines and important government sites with millions of monthly sessions.

I was not aware of all what you're describing in you comment, and probably I would have not upgrade it if I knew that before; but the reality is that it's working and it solves some issues we saw before with

I left the final decision to our beloved release manager but, yes, I think we must pin persistent.

Thanks, Fred.

[edited because the more I looked at the Persistence notes the less I liked it]

I'm going to back out the zope.ramcache change, purely because of the potential Persistence/ZODB incompatibility. @hvelarde what issues were you seeing in and could the relevant fixes be backported to zope.ramcache 2.1.x?

the statistics tab is completely broken on errors; that is fixed in zope.ramcache = 2.2.0 and that's why added it on first place:

I think you can remove that pinning from the final release; I'll keep it here because it's working for us as I said above: those sites have created thousands of new content items already and if there were any issue, it already had exploded in our faces.


FWIW, we've been running our - reasonably extensive - robot test suite with 4.3.18 for quite a while now. We haven't noticed any new and/or exiting issues occurring. Mostly we're doing in-depth testing for a range of functionality on a number of complex Archetypes products.

We're excited to see the new version released soon.

A big thanks to everyone who makes the magic keep on happening!

I think it's important to pin six = 1.11.0 before the final release.

UPDATE: never mind, it's already there:

I've moved 4.3.18 out of "pending" status on Installers should be out soon.