Planet Plone - Where Developers And Integrators Write

Plone Beethoven Sprint 2019

Posted by kitconcept GmbH on September 25, 2019 09:00 AM

beethoven sprint group image

21 developers from nine different countries gathered in Bonn, Germany between June 20th and 24th to work on implementing the upcoming Plone 6. The sprint at the office of the kitconcept GmbH has been declared a “strategic sprint” by the Plone framework team. Sprint topics included working on Volto, the Plone REST API, and Guillotina.


Volto is a new ReactJS-based frontend for Plone. It was started by Rob Gietema in 2017 and it is actively developed since then. Volto will become the default frontend for Plone 6. It implements a complete new user interface called Pastanaga UI, which was developed by Albert Casado.

Victor Fernandez de Alba and Rob Gietema led the efforts to further enhance Volto together with Paul Roeland, Nicola Zambello, Piero Nicolli, Janina Hard, Jakob Kahl, Thomas Kindermann, Maurizio Delmonte, Stefania Trabucchi, Rodrigo Ferreira de Souza, Fred van Dijk, and Steffen Lindner.

Pastanaga UI Toolbar

The new editing toolbar has been part of Volto right from the start. Though, so far we did not fully implement every detail that Albert has imagined for the Pastanaga UI toolbar. Victor has been working on this for quite a while already. During the sprint, he integrated his work and polished it. Victor and Rob also worked on a new sidebar that shows up on the right side of the Volto user interface that holds additional information like page metadata and controls the settings of the individual tiles.

volto toolbar The new Volto edit toolbar

New Tiles: Collection, Slider and Table

At the Plone conference in Tokyo, we came up with a list of tiles for the new Volto composite page editor that we would like to implement. On top of that list were the listing/collection tile, the slider tile and the table tile. Piero, Rodrigo, and Rob started to work on the listing/collection tile that is supposed to become a replacement for the Collection Type in Plone.

Jakob and Janina worked on copying over the code of a slider tile that was developed by kitconcept. Rob implemented the table tile. Before you could ask Rob about the progress, he already finished his work, like always…

volto table The new Volto table tile


Accessibility has always been a first class citizen in the Plone community. Plone is used by many government and public websites where accessibility is a basic requirement. Paul, Thomas, Timo, and Victor worked on improving the accessibility of Volto. Our goal is to fully support the WCAG 2.1 standard with the “AA” level of conformance.

Timo set up ESlint-based static code analysis checks and Cypress-based axe accessibility tests. Paul, Thomas and Victor then started to fix the reported accessibility issues. At the end of the sprint, we were able to fix all the reported violations. Our CI build now fails if new accessibility violations are committed.


Sven Strack, the Plone documentation team leader, joined our sprint remotely from Amsterdam to discuss how to maintain and structure the Volto documentation in the future. We all agreed that we will use Markdown as format for our docs, since this is the de-facto standard in the JavaScript community as well as in most other Open Source communities. As much as we like Restructured Text, it seems that Markdown won that battle.

We currently use MKdocs for the Volto documentation and Styleguidist to document our React components. There are lots of different tools to choose from, Docz, MKDocs, MDX, Gatsby to just name a few. We agreed that we need to do more research to make an educated decision regarding our doc toolchain.

There will be a Google Season of Docs project this year where a technical writer will help us to enhance the Volto docs further. More Volto Features Nicola added a feature to display the currently used Volto version in the Plone control panel, he added animations for page transitions and added an Italian translation for Volto. Together with Victor, he worked on a toast component for user notifications.

More Volto Features

Piero worked on improving and fixing the event type view and added styling for the listing tile.

Victor and Steffen worked on the image sidebar.

Rodrigo added a feature that allows the user to use SHIFT+RETURN to create a new line in a Volto text. By default Volto creates a new text tile on RETURN. Rodrigo also looked into the Add-ons control panel work that Eric Steele started some time ago.

Nilesh joined us remotely from India and continued his work on the users and groups control panel for Volto.

Steffen fixed a bug in the subjects search. Rodrigo and Thomas looked into our Cypress-based acceptance tests.

Fred looked into what consequences it would have for us to get rid of the description tile and how we could customize the domain in Plone to allow to send portal emails via the Volto frontend.

Stefania and Maurizio worked on a product definition of Volto and an elevator pitch for clients and users. Together with Paul, Fred and Timo, they had a longer discussion about how to position Volto and Plone 6 in the market.


The Plone REST API builds the foundation for the new Volto frontend and Plone 6. It has been under active development in the last four years and seen more than 80 releases in that time period. The REST API is stable, battle-tested and production-ready and part of the Plone core since the release of Plone 5.2.

Thomas Buchberger and Lukas Graf led the REST API efforts during the sprint and worked with Carsten Senger, Roel Bruggink, Janina Hard and Timo Stollenwerk to further enhance the REST API, fix bugs, improve the documentation, and the error handling.

API Team in the graden Plone REST API discussion in the garden

Querystring Endpoint for the Collection Type

One of the most important new features, that has been developed during the sprint, is the new querystring endpoint. This endpoint will allow us to implement the Collection type for the Volto frontend. Lukas implemented this essential feature with help from Rob, who took care of the frontend implementation in Volto.

New Features, Bugfixes, and first time contributions

Thomas added support for the retrieval of additional metadata fields in summaries in the same way as in search results. Lukas made the @types endpoint expandable and the @users endpoint easier to customize. Janina fixed setting the effective date on workflow transitions. This was her first contribution to the Plone core. On the same day she signed the contributor agreement, got her fix merged and released, which is quite an accomplishment for a single day. Way to go Janina!

In addition to that, the team fixed lots of smaller bugs (#780, #729, #764, #755, #777, #732, #738) during the sprint. REST API Error handling Carsten, Nathan, Thomas, Lukas and Timo had a longer discussion about error handling in the Plone REST API and about how we can improve things. We considered and discussed implementing RFC7807 and decided against adopting it.

Developer in office Sprint discussions…

The RFC did not see much adoption and it only slightly differs from what we are already doing. A breaking change does not seem to be worth the effort. We decided to create a separate error reporting component unifying the error reporting and ensuring consistency. We also started to fix a few inconsistencies right at the sprint.

API Documentation

Guillotina is using Swagger to document its API. Nathan explained the approach he took for that and Carsten started to integrate Swagger to generate dynamic api docs in plone.restapi.

REST API Releases

Most of the work we did on Plone REST API during the sprint has been released in Plone REST API 4.1.4, 4.2.0, 4.3.0, and 4.4.0.

Dexterity Site Root

Roel Bruggink joined us on Saturday and Sunday to continue his work on turning the Plone site root into a Dexterity content object. He fixed some complex recursion and acquisition problem when migrating the site root to Dexterity. His Plone Improvement Proposal (PLIP #2454) has been accepted by the Plone framework team and it will build the foundation for a new Plone 6 branch that we plan to cut this year.


Guillotina is a new AsyncIO REST data API. It has been written from the scratch by Ramon Navarro Bosch and Nathan van Gheem. It can easily scale billions of objects via its REST API. With the CMS addon, it is compatible with the Plone REST API. Therefore you can run Volto on a Guillotina backend and Guillotina might be able to replace our existing Plone backend in the future.

Guillotina Developer The Guillotina master thinking hard. :)

Nathan and Ramon worked on Guillotina 5. The Guillotina 5 release brought Python 3.7 support and the use of the context vars APIs. They refactored quite a bit, moved parts of addons into core(swagger, caching, pg catalog), implemented OOTB PostgreSQL catalog, added a Helm/Kubernetes/Docker configurations for the Guillotina CMS addon that can be configured to act as a Volto backend, worked on improving caching and filestorage.

Websockets for Plone

At the Plone Open Garden 2019, Asko Soukka started to work on bringing websocket support to Plone. Websockets allow bi-directional communication between the server and the browser. With websockets, the server can send messages and notifications to the browser. This can be used to implement notification systems or collaborative editing to just name a few possible applications.

Asko continued his work during the Beethoven sprint and created an example where comments that are added to Plone automatically pop up as toast notifications for other users. He published a Docker image with a Twisted-based ZServer and implemented the foundation to use that feature for gatsby-source-plone. This will allow us to create an extension that will allow editors to live-preview changes they do in Plone in a GatsbyJS site.

Developer in Office

Karaoke, Barbecue and Garden Parties

A Plone sprint is much more than just programming. Collaborating, meeting old friends, talk, discuss and having a good time together are the ingredients that make a Plone sprint. We started our sprint on Thursday with a free React and Volto training for newbies. At the evening when everybody arrived, we went to a local Karaoke bar for a revival of the epic Karaoke sessions we had in Tokyo last year.

Karaoke Karaoke at the “Nyx”

On Friday evening we ordered Pizza and hacked the night away at the office and our garden. On Saturday we went to the “Arithmeum”, a mathematics museum owned by the Research Institute for Discrete Mathematics at the University of Bonn.

Arithmeum Our tour at the “Arithmeum”

Afterwards we had a garden party with a barbecue and we spend the afternoon sitting in the garden and the office and continued to drink and hack on Plone.

Developer in garden Barbecue in the garden of the kitconcept office


The Beethoven Sprint 2019 was a major success. We were able to start working on the main missing pieces for Volto. The new edit toolbar is in place and the foundation for the new tiles/metadata toolbar on the right side of the UI has been finished. We also implemented a new table tile.

We implemented a proof-of-concept for the new listing / collection tile and implemented the required querystring endpoint in Plone REST API. Both Volto and the Plone REST API got lots of enhancements and bugfixes.

Both the Plone REST API and Volto are stable and used in production. We will use the next month to further enhance Volto and implement the missing bits and pieces. Our plan is to present Volto 4 at the Plone conference in Ferrara at the end of this year and cut a Plone 6 branch afterwards that contains the Dexterity Site root, folderish content types and other enhancements that are needed make Volto the default frontend for Plone 6.

Guillotina and the Websockets support for ZServer together with Gatsby as another frontend for Plone are amazing projects by the smartest folks in our community. Our diversity is one of our main strength and we are looking forward what the future will bring!

We had a great time at the sprint. Thank you to everyone who attended! We thank the Plone and Python community for their ongoing support. The Plone Foundation, the Python Software Foundation, and the German Python Software Verband made this event possible with their sponsorship as well as our company sponsors Abstract, Starzel, Werkbank and Zest.

We are looking forward to see you all in Bonn next year!

Developer in garden The “Hofgarten” near the kitconcept office

Nominations Open for Plone Foundation Board of Directors

Posted by PLONE.ORG on August 28, 2019 09:48 AM

If you have an interest in helping the governance of Plone, and particularly the energy and time to pitch in, please consider nominating yourself to serve on the Plone Foundation board of directors for 2019-2020.

Nomination Process

  1. Log in on and go here:
  2. Add a page there with your name in the title.
  3. For the body, discuss:
    • Who you are
    • Why you're interested
    • What you think you can add to the Plone Foundation
    • Most importantly, the name(s) of one or more Plone Foundation members who "second" your nomination
  4. Once ready, click "submit" in the workflow drop-down menu to get a reviewer to look at your nomination.
  5. Nominations will be accepted until October 20 2019, 23.59, UTC. The election will be conducted in conjunction with the annual meeting, which will take place in Ferrara, Italy at the Plone Conference 2019. All active members of the Plone Foundation will be eligible to vote.

About Board Membership

The Plone Foundation is a not-for-profit, public-benefit corporation with the mission to "promote and protect Plone". That has meant that the board is involved in:

  • protecting the trademark, copyrights and other intellectual property, including considering licensing and usage issues;
  • hiring the release manager;
  • working with other communities like Zope, Guillotina, Pyramid, ...
  • working with various committees, including marketing and membership;
  • handling "other stuff in the community" as needed, e.g. helping craft policy on and about commercial listings
  • but not: directing Plone development. The board facilitates, but does not direct, the development of Plone itself.

While there's lots of work that happens online, much of the critical business of the board is conducted during video meetings every two weeks — typically, board meetings last about an hour to 90 minutes though occasionally they can run over to handle time-critical issues.  Please consider whether this fits your schedule, since missing more than an occasional meeting severely limits the ability of the board to reach quorum and conduct business.

Historically, board meetings have been organized to occur during daytime hours in America and evening hours in Europe, currently at Thursday nights, 19.00 UTC in northern hemisphere summer and 20.00 UTC in northern hemisphere winter. That can always change with new board members.

In addition, there is a board mailing list (private), where we discuss things in addition to the meetings.

This is a working board. Be ready to regularly take on and complete responsibilities for board business.

The board writes no code and makes no development decisions. It is much more concerned with marketing, budgets, fundraising, community process and intellectual property considerations.

You do not need to be a Foundation member to serve on the board (in fact, board leadership is an excellent way to become a Foundation member). All you need is to get an active Foundation member to second your nomination.

The Plone Foundation is interested in broadening the diversity of our leadership, with regards to gender, ethnicity, and geography.

If you have questions about the nomination process, contact the board:

Announcing the Plone Conference 2020 selection process

Posted by PLONE.ORG on August 22, 2019 07:23 AM

It is time to begin planning the 2020 edition of the main Plone event of the year.

The annual Plone Conference brings together users, integrators, developers, designers, and other interested folk from throughout the world for a week of training, talks, and sprinting. Plone conferences are also an expression of community spirit: they are organized by a company, user group, or other entity with ties to and a history with the Plone community and are in essence not-for-profit events.

They tend to cover a wide range of subjects: not just Plone, but also related technologies such as Volto, Guillotina, React, Angular. And of course topics such as accessibility, user experience, documentation, continuous integration, community organizing and others. Past conferences have also been places where special interest groups like universities, NGO's and others have held meetups.

The Plone Foundation is soliciting proposals to host the 2020 Plone Conference. The timeline of the selection process allows groups and organizations interested in hosting the 2020 Plone Conference (or beyond) to work with the Ferrara team for hands on experience during this year's conference.

Previous editions of Plone Conference were held in many places all around the world:

  • 2003: New Orleans, Lousiana, USA
  • 2004: Vienna, Austria
  • 2005: Vienna, Austria
  • 2006: Seattle, Washington, USA
  • 2007: Naples, Italy
  • 2008: Washington, D.C., USA
  • 2009: Budapest, Hungary
  • 2010: Bristol, UK
  • 2011: San Francisco, CA, USA
  • 2012: Arnhem, Netherlands
  • 2013: Brasilia, DF, Brazil
  • 2014: Bristol, UK
  • 2015: Bucharest, Romania
  • 2016: Boston, MA, USA
  • 2017: Barcelona, Catalunya, Spain
  • 2018: Tokyo, Japan

and, for 2019, we will gather at Ferrara, in Italy.

If you have a place in mind, and are willing to host the next edition, don't be shy: submit a proposal! If you want, the Board is of course willing to help you in refining your proposal. So don't hesitate to contact the Board while still developing your proposal; most of the proposals of the last year were developed in cooperation.

The Plone Foundation will accept proposals beginning September 1st through September 30th, 2019. Please submit your proposals to

The Foundation Board of Directors will review proposals and open those that are viable for voting by the Foundation membership between October 14–18, 2019.

Announcement of the winning proposal will happen at the end of Plone Conference 2019 in Ferrara.

Everything you need to know to submit a proposal, including the full schedule for the process and in-depth requirements for hosting, is outlined in the official Plone Conference 2020: Call for Proposals.

On behalf of the entire Plone community, we look forward to your conference proposals!

Looking forward to the Season of Docs!

Posted by PLONE.ORG on August 18, 2019 04:04 PM
Cris Perez is an experienced tech writer who will collaborate with a team of Plonistas to work on the Volto documentation for the next three months
This is made possible by the Google Season of Docs, who have announced the projects that participate.
Volto is a new, modern, React frontend for web content management systems.Through use of a mature REST API, Volto has access to all the features of Plone, one of the most secure, reliable and flexible content management systems, with an almost 20 year track record.
During the Google Season of Docs, we aim to streamline the Volto documentation ffor developers from different backgrounds. The documentation will be extended and reorganized to cater to a more diverse set of developer experiences and backgrounds.
Developers and designers familiar with React need information on how to interact with Plone features so they can create feature-rich websites with custom workflows and permissions, and enjoy Plone's comprehensive backend services such as the built in search engine and its rock-solid content management features.
Developers already familiar with Plone will want to know how to leverage modern JavaScript tools to create better user experiences.
And, given the worldwide and diverse Plone and React/Volto communities, we will pay particular attention to avoid unwanted cultural, gender or other biases, thus ensuring that the documentation is inclusive and accessible for the widest range of readers.
We will use clear, concise language to help the many developers for whom English is not their first, or even second, language.
Cris Perez will be working with the following team: Timo Stollenwerk, Víctor Fernández de Alba, Kim Paulissen, Sven Strack, Paul Roeland.
As always, we thank all volunteers for their contributions!

Three Members Join the Plone Foundation

Posted by PLONE.ORG on August 11, 2019 12:46 PM

The Plone Foundation welcomes 3 new members after unanimous confirmation by the Foundation's Board of Directors on August 1, 2019. Membership in the Foundation is conferred for significant and enduring contributions to the Plone project and community. The Plone Foundation Membership Committee overwhelmingly recommended each applicant for their ongoing contributions to Plone.

Christine Baumgartner

Christine Baumgartner

Christine is the "Partner" in Klein & Partner KG, a founding member of the BlueDynamics Alliance. She has been part of the Plone community since the (second) Vienna Plone Conference in 2005. In 2006 she began organizing the first of many sprints: the Golden Roof Sprint 2006, Castle Sprint 2017, and five (!) Alpine City Sprints in Innsbruck, where for the past two years they have been joined by Zope core contributors. To reward sprinters for their hard work, she has organized noteworthy excursions to promote team building and forge long lasting personal connections in the Plone community and between the Plone and Zope communities. 

Kim Paulissen

Kim Paulissen

Kim is a senior software developer and avid Plone Conference attendee, starting with Plone Conference 2010 in Bristol, then San Francisco (where she gave two talks), Arnhem, Bucharest, Barcelona, and, most recently, she participated in the Plone Open Garden Sprint 2019. She will join the ranks of Plone Conference trainers when she helps give the Mastering Plone Training at the Plone Conference in Ferrara this October. Kim has contributed code and many bug fixes for Plone and its add-ons, and she is co-maintainer of the collective.ckeditor package.

Rikupekka Oksanen

Rikupekka OksanenRikupekka has been using and promoting Plone at the University of Jyväskylä since 2004 (and Zope since 2002) where there is a huge Plone presence. He started at first as a web developer then later took on project management, customer support, and trainer roles, training hundreds of people to use Plone. Rikupekka has been blogging since 2009 about Plone, has presented at Plone conferences since 2014, and organized the renowned 2017 Sauna Sprint.


The Foundation is the trustee for Plone's intellectual property, works to protect and promote Plone, and has over 80 active members.

Released is released

Posted by Andreas Jung/ZOPYX on August 02, 2019 04:52 PM
Should you be allowed to remove your own packages from PyPI or any other public package repository? Short answer: NO!!!

The Guardians of the Zope and Plone Galaxy

Posted by PLONE.ORG on July 24, 2019 11:03 AM

Over the past three years, the Zope and Plone communities have been working hard to prepare both applications for Python 3. The end of the journey is near, and as a result the applications are faster and modern again! This was achieved without sacrificing the long-standing high security standards of Zope and Plone.

Work began in 2016 after the Alpine City Sprint in Innsbruck. PLIP #1351: Update Zope Dependencies  by Johannes Raggam, who with the support of Philip Bauer and Jens Klein, initiated the work on Plone. At the time, the mood among Plone and Zope was fairly negative due to the daunting task at hand.

Momentum started with joint sprints like gocept's "Resurrection" sprints (later named "Saltlabs Sprints") in Halle/Saale on the Zope side and the "Alpine City Sprints" in Innsbruck on the Plone side. Many additional sprints followed: the Buschenschank Sprints, Berlin Strategic Sprints and Plone Conference sprints around the world. The need to modernize both systems brought the developers of the Zope and Plone communities together. The close cooperation of the development teams made the effort a success. Now the communities stand side by side together.

"From the Zope community's point of view, it is very nice to see Plone core developers' vested interest in Zope. It would be wonderful to have regular exchanges between the Zope and Plone communities", said Michael Howitz, Zope release manager and core developer at the Alpine City Strategic Sprint 2017.

In March, just before the release of Plone 5.2, representatives of the Zope and Plone community were so kind to dedicate their time to an interview by Christine Baumgartner. Many thanks to Michael Howitz from Germany (gocept), Davi Lima from Brazil and Alessandro Pisa from Italy (syslab).

How have the worlds of Plone, Zope, and Python changed with Python 3, and what are the old and new goals?

Davi pointed out:

"By moving to Python 3, Plone gets more inline with the current Python community to share its differentials to other available languages and products. With current tooling explosion on the front-end, companies feel the vacuum of a solid back-end on which they can trust. Their projects may grow for many years without hitting basic, but deep rooted system limitations, like workflow not being extensible enough."

Alessandro told me:

"The most positive thing is that the two worlds now seem to be more connected than in the past."

Michael said:

"With Python 3, Zope is back on the cutting edge of technology. Efforts have shown that there is a living Zope community, and that Zope and Plone can benefit from each other."

What changes are relevant for users, or what should users expect?

Alessandro said:

"A better user experience and introduction of up-to-date technologies."

Davi explained to me:

"Developers can expect easier syntax - for example: handy string interpolation and formatting, more predictable behavior for data structures, higher level dynamic structures like context managers, and more performance with the all-around preference for generators and lazy data structures, as opposed to in-memory ones."

Michael pointed out:

"In principle, nothing should change for the end-users. For developers, adapting code and data to be compatible with Python 3 means a lot of work. But this is also an opportunity to modernize existing code."

Are any new and/or other use cases for Zope and Plone? Or, do certain use cases disappear?

Davi explained:

"Most companies adopt React or Angular for their front-end and develop their back-end mostly from scratch, tackling problems as they come instead of preparing a solid set of features (e.g. workflow, permissions, content types, content rules and so on). What happens is these features are invariably requested and refactorings of such size commonly bring companies to the floor, or lead to development paralysis situations from which it's hard to get unbound."

With Plone 5.2 there are changes in the development process. What have developers, administrators and editors paid attention to?

Michael said:

"I can only speak for developers: First, they should upgrade their projects to Plone 5.2 on Python 2, then migrate to Python 3. Zope 4, which is used for Plone 5.2, is intended as an interim release only. Relatively soon after the final Zope 4 release, work will begin on Zope 5, which will no longer support Python 2."

Alessandro explained:

"I will give you a concern about system administrators: the new infrastructural changes in how Zope is served with WSGI will introduce new patterns."

Davi told me:

"It's important to understand how front-end is architected, its basic building blocks are key for a project that only executes goals correctly, but also that feels good while using. Also it's important to learn how to use Plone API and Plone RESTful API to make content operations trivial. Check out the Volto project!"

I know there were a lot of stumbling blocks on the way to the new release. How were they solved? Which stumbling blocks still have to be solved?

Alessandro claimed:

"Porting the code to Python3 was an epic success."

Davi explained:

"Plone has an extensive codebase and also a very fragmented one. This means changes were necessary in dozens of packages, in a coordinated effort touching heterogeneous parts: from database migrations to displaying of widgets. This was solved with a series of community immersion meet-up events, called sprints, in which people from different countries gather to discuss, code and improve. It seems to me that the next steps revolve around making add-ons compatible with Plone 5.2, so a lot of focus is on documentation, talks and getting the word out."

Michael pointed out:

"Stumbling blocks were some subtle differences between Zope 2.13 and Zope 4 that were not noticed within Zope or where Plone expected a very specific behavior, which was not available in Zope 4. The migration of ZODB to existing projects in the real world that go beyond toy applications is still open."

After all this work, can we expect advantages compared to the old Plone and Zope?

Davi said:

"Faster user interface, better integration with current front-end tooling."

Michael expected

"A higher execution speed."

And Alessandro opined

"The adoption of mainstream technologies."

In closing, what advantage do we have compared to other systems?

Alessandro claimed:

"Well, the main one for sure is the way we deal with security."

Michael confirmed:

"There is a current, well-maintained system, which has an active community that supports each other and actively works on the care and development."

Davi Lima was convinced:

"Permissions and workflow systems, contextual editing (as opposed to a separate "Admin Interface"). In Python, everything is an object, in Zope, everything is a component. Decades of accumulated experience and solutions that you have not even realized you already or soon will have. Relying on the same CMS as and ;-) "

These are the Guardians of the Zope and Plone Galaxy:

(At least a whole bunch of them taken from our records. This list is in alphabetical order, but is not complete)

Alessandro Pisa, Alexander Loechel, Andreas Jung, Christian Kreutzer, Christian Theune, Christine Baumgartner, Cillian de Róiste, Davi Lima, Daniel Havlik, David Glick, Fred van Dijk, Georg Bernhard, Gil Forcada, Godfroid Chapelle, Hanno Schlichting, Harald Frissnegger, Jan Mevissen, Jens Klein, Jens Vagepohl, Johannes Raggam, Joni Orponen, Jörg Zell, Jürgen Gmach, Katja Süss, Maik Derstappen, Manuel Reinhardt, Markus Hilbert, Matthew Wilkes, Martin Häcker, Maurits van Rees, Michael Howitz, Michael Töpfl, Nathan Van Gheem, Robert Niederreiter, Patrick Gerken; Paul Roeland, Peter Holzer, Peter Mathis, Phillip Bauer, Roel Bruggink, Stephan Klinger, Steffen Allner, Sune Brøndum Wøller, Thomas Lotze, Thomas Massmann, Thomas Schorr, Tres Seaver, Jens Vagelpohl, …

text by Christine Baumgartner and Jens Klein - 2019-07-24

Plone 5.2, the Future-Proofing Release

Posted by PLONE.ORG on July 21, 2019 04:17 PM

An update to secure the future

Plone 5.2 is the latest version of the most fully-featured, open source web content management system. Plone 5.2 is the culmination of over 3.5 years of development that was driven by the looming deadline of January 1, 2020: the impending end of support for Python 2.x.

Python 3 Compatibility

Plone is written in Python, the programming language that has taken the world by storm and is popular for learners, scientists, web-developers and machine-learning alike. Support for Python 3.6, 3.7, and 3.8 is now included with Plone 5.2, opening up the future for Plone’s continuing 20 year reputation for unrivaled security and stability.

Plone 5.2 ships with Zope 4, which itself comes with Python 3 compatibility, Web Server Gateway Interface (WSGI) support, and a new look.

Work on Plone 5.2 began to take shape in January 2016, with a Plone Improvement Proposal (PLIP) to update its dependencies to use early Zope4 versions and culminated in the completion of the proposal to port to Python 3 in February 2019.


Once available as a separate add-on, a REST API is now also included in Plone 5.2, making it even easier to use Plone with modern JavaScript front ends such as Volto (based on React) and to integrate Plone with other applications.

User-Facing and Developer-Focused Changes

But Plone 5.2 isn’t just a backend upgrade: it includes user-facing features such as new dropdown menus, configurable redirects (customizable URL shortening and content linking).

Developers will also find a more pluggable and customizable login mechanism and a modernized virtualenv-based buildout.

Community-driven development

For almost 20 years now, the Plone software has continued to innovate and evolve with the times, and its world spanning community maintains a dynamic schedule of collaborative sprints and an annual conference bringing together its integrators and users, which include corporations, universities, all levels of governments and well-known government agencies.

Feature-rich and ready-to use

Plone is unsurpassed in the out of the box experience it provides for collaboratively creating, maintaining, and managing large amounts of content. Some of its feature highlights include:

  • customizable workflow for controlling how content gets reviewed and published
  • built in content history and version control
  • content rules that automatically take actions, such as notify users or move content based on customizable conditions
  • sophisticated, fine-grained security through permissions, roles, users, groups, and folder- and object-level sharing authorization
  • accessibility compliance, meeting WCAG 2.1 AAA
  • integration with enterprise authentication and authorization via LDAP/ActiveDirectory
  • deployments that scale, whether Docker, on-premise, or in the cloud

Future Proofing

Plone 5.2 is a must-have as of January 1, 2020, for individuals and organizations with complex content serving needs, a rigorous publishing workflow, a multi-person content creation team, or all of the above.


About Plone:

Demo site:

Download Plone 5.2:

Release notes:


Upgrade guide:



New dropdown menus

screenshot showing mouse hovering over the navigation bar

Configurable Redirects

Redirects Screenshot_2019-07-21 demo plone org.png

Refreshed Zope4 Look

Zope4 Screenshot_2019-07-21 Website.png

About Plone

Released under the GNU Public License (GPL), Plone was created in 2001 as an extension of the groundbreaking Zope web application framework to support the easy creation and management of rich websites and intranets. Plone is among the top 2% of all open source projects worldwide.

About the Plone Foundation

As Plone’s adoption and contributor base grew tremendously the Plone Foundation was established in 2004 and tasked with protecting and promoting Plone. It is a US 501(c)3 non-profit modeled after similar ventures such as the Apache Software Foundation. The Plone Foundation provides support for development and marketing. It is the legal owner of the Plone codebase, trademarks, and domain names. Its goal is to ensure Plone remains the premier open source content management system to broaden its acceptance and visibility.



Q&A with Philip Bauer

Posted by PLONE.ORG on June 30, 2019 07:11 PM
Philip Bauer (Starzel.deis the Munich-based organizer of the effort to create and release Plone 5.2, the version that brings Plone into the modern Python 3 world. 
What follows is a question and answer session with Philip, for which he promised not to make up any new German superlongcompoundwords.

Philip, you’re a pop star!

*plays wicked air guitar solo*

What does Plone 5.2 mean to you?

It's the best thing since sliced bread since I can finally develop in Python 3 while still doing Plone.

How much work did you put into Plone 5.2?

About 8 Quadrillion Mythical Man-Months. Frankly I've grown a lot of grey hair not because of working on it but during.

When did you start working on Python 3 compatibility for Plone?

I started work in October 2017 shortly before the Plone Conference in Barcelona, right after we merged Zope 4 support into Plone – which in turn we began to work on in January 2016. So altogether it took three years. It's been on the roadmap for a good while, I just never thought it would be me doing it but somehow nobody stepped up – so I did. [Interviewer’s note: it helps when you have a bottle of Ardbeg at the ready *cough*] 

What will you do with your free time now that “it’s all done”?

I'll add support for Python 3.8. I actually did that this week, and it only took about 8 hours. See[Interviewer’s note:“Oops, I did it again!”] 
After porting to Python 3 was finally done I really needed to do some paid work since my bank account took a real hit from all the unpaid work. I'm glad to be able to do some exciting new projects now with my company, most of them already on Python 3 or soon to be migrated.

Does your family still recognize you?

The kids loved the beard that I grew during the last months of porting and don't know me now that I’ve shaved it off. [Interviewer’s note: it seemed a rather scary looking beard.]

Was it worth it?

Totally! I had the privilege of working with some of the smartest and nicest people I know. I also learned so much about Python, Plone and Zope which probably made me a better developer. But there are also some things I'd love to unlearn; there are some dragons in our codebase and fighting these can be frustrating.

Has your liver recovered?

Still working on it.

What do you look forward to the most in Ferrara?

It will be weird to see how everyone will take for granted that we now run on Python 3 and have a great new frontend (Voltoin the works. 
Many take it for granted how much time and love is put into Plone. 
I love the new energy that is noticeable in the community. I think it comes from the certainty of having a stable backend without an expiration date and the excitement of developing a new frontend.

When will you finally !@#$#@$ host the Plone Konferenz (note the “K”) in Munich?

In 2030. We'll do a keynote (with “K”) on Python 6. [Interviewer’s note: it does NOT take that many years to make a new major version of Plone!] [Another interviewer’s note: Philip is not going to get off that easily, either.] 

Are you seriously now a Volto believer?

It is amazing to finally have a modern frontend without having to develop the framework for it ourselves. Volto is a huge step into the future, and choosing React for it was a very wise decision. 
I still hate JavaScript as a programming language but since the toolchain has matured so much it is finally fun to develop with it. Also: Most of the heavy lifting is still done in Python.

What has Plone done for you lately?

Plone paid for the beer in my fridge; it also paid for the fridge and for the house the fridge stands in. 
Speaking of beer: I'll have one right now.

Medical guideline portal relaunched - on top of Plone 5.2 and Python 3.7

Posted by Andreas Jung/ZOPYX on June 24, 2019 10:07 AM
In the third major iteration of the Onkopedia project, ZOPYX and partners relaunched the complete portal with a new fully responsive layout and an updated Plone backend based on the latest Plone 5.2 version and finally Python 3.7 under the hood.

Sign up for Plone Conference 2019 in Ferrara!

Posted by PLONE.ORG on June 18, 2019 09:15 PM

Plone Conference 2019 in Ferrara is revving up! 

This is the first ever Plone conference at a UNESCO World Heritage site... not to be missed.

  • Early bird tickets are on sale now
    • (full pass, daily pass, party-only)
  • Sign up for the included training classes
    • see tentative training class list and schedule below
  • Now accepting your talk submissions
    • Deadline for submissions is June 30, 2019

Now is also a good time to begin making travel arrangements.

Our friendly conference organizers have provided a lovely guide to Ferrara that covers getting there, accommodations, places to eat, and things to visit.

We look forward to seeing you there!

Training Classes (tentative)

Become a Plone Power User How to effectively manage your Plone website content and use the full power of Plone Paul Roeland, Kim Nguyen 1/2 day
Mastering Plone 5 Development Learn how to develop custom projects with Plone 5.2 and Python 3 using the latest best-practices Philip Bauer, Thomas Schorr, Kim Paulissen 2 days
Guillotina Getting started with Guillotina: the asyncio REST resource API Nathan 1 day
React Get started with React & Friends Rob Gietema, Roel Bruggink 1 day
Volto Create your own site using Volto Rob Gietema, Roel Bruggink 1 day
Testing Plone Learn what and how to test yout Plone products Andrea Cecchi 1/2 day
Pyramid APIs in the Real World With Pyramid and pyramid_openapi3, will will fire up a demo application. We will then introduce bugs, and demonstrate techniques for troubleshooting, debugging, and testing. From there we will extend the application to include generating reports, working with task queues for long-running processes, importing and exporting data, swapping front-ends, and a few other common use cases. Nejc Zupan and Steve Piercy 1/2 day
Volto theming hands-on: Building in Volto Expand your Volto skills by attending this hands-on training. We will be
building together the next site. We will cover Volto theming,
customization, and the required components and backend plone.restapi
endpoints to match features and look and feel.
Victor Fernandez de Alba 1/2 day
Waitress, there's a Plone in my WSGI. Can I talk to the Supervisor? How to deploy and operate Plone 5.2 on Python 3 using WSGI. Thomas Schorr 1/2 day

Tentative Schedule


Using Glitch for Pyramid Learning

Posted by Jazkarta Blog on May 09, 2019 08:02 PM

Screenshot: Pyramid Quick Tutorials showing pyramid-view-decorators, pyramid-view-predicates, pyramid-view-renderers and pyramid-asset-specifications

At this year’s Jazkarta sprint we decided to invest some time in creating Pyramid learning resources. We are fans of the Pyramid web framework, and we felt that it would be nice to work on something that would make it easier to get started with, especially for novice developers.

Enter Glitch. This is a platform that is designed for letting users explore web apps created by other Glitch users. When you see an application that does something that you want to do, you can “remix” it, which means that an exact copy, with all its code and resources, is created in your own workspace (which is some sort of Docker container). You can then change it in any way you like. This is very powerful, because you get a working application that is hosted for you, and every code change that you make is immediately reflected in the web app page.

This turns out to be really useful for teaching web application development concepts, because students can see the code for the example, read an explanation, and then right away remix the code to try out their changes, which they can see working instantly. No need for setting up a workspace, checking out code, or running a web server. Just try out an idea and see the result right there, or share it with other people. Like “view HTML source” but with code, which is one of Glitch’s goals.

We decided to create a Glitch collection that would showcase a few of Pyramid’s most distinctive features, along with a simple Hello World style tutorial. The first thing was to verify that Pyramid could be installed. Glitch’s main development target is Node.js, but its containers install Python and they allow the user to run pip, so it’s possible to install most PyPI packages including Pyramid. (For those who might be wondering: sorry, Plone is not installable, because it needs system dependencies that are not installed by Glitch.)

Glitch supports a setup file named glitch.json, which is what allowed us to install Pyramid:

 "install": "pip3 install --user pyramid",
 "start": "python3"

In the json above, you can see that we install Pyramid using pip, and we can add any other dependencies for our project there. We can then use the “start” key to tell Glitch how to start our application.

Once we did that, the only other thing needed was to create our Pyramid app, which in this case uses code directly lifted from the site:

from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.response import Response

def hello_world(request):
    return Response('Hello Glitch')

if __name__ == '__main__':
    with Configurator() as config:
       config.add_route('hello', '/')
       config.add_view(hello_world, route_name='hello')
       app = config.make_wsgi_app()
    server = make_server('', 3000, app)

That’s it. Glitch automatically runs the application (the only caveat is that it needs to use port 3000). You can configure it so that any code change automatically restarts the app. After this, if a potential new user sees your project, she can just use the remix button and have a copy made in her workspace. Any change that she makes, like changing the hello text, will be immediately visible on the page.

Overall, we found Glitch to be a very intuitive and easy to use service. You can see the collection of simple tutorials that we created here:

Pyramid Quick Tutorials


Jazkarta Goes To LA

Posted by Jazkarta Blog on May 09, 2019 07:47 PM

The Jazkarta team at LAX-C, a city block sized Asian food distributor and restaurant supply

This year Jazkarta’s annual sprint was held in the city of Los Angeles, graciously hosted by Alec Mitchell who lives a block away from LA’s City Hall.

View of the Los Angeles City Hall from Los Angeles Street

We had fun exploring the city – Union Station, Chinatown, LAX-C (pictured above, a gigantic Asian food distributor and restaurant supply), Grand Central Market, Griffith Observatory, and the Hollywood Farmers’ Market where we bought lots of delicious fruit.

Citrus and strawberries from the Hollywood Farmers' Market

We attended an improv comedy performance at the Upright Citizens Brigade Theater, ate lots of tacos, had original Phillipe’s French Dip sandwiches, visited brew pubs and drank lots of local beer.

The Jazkarta team in front of the Highland Park Brewery.

We even had a private tasting of cheese, beer, and wine pairings.

Plate with five different cheeses and a variety of fruits and nuts

Oh, and we also sprinted on a variety of topics!

Alec and Jesse Snyder ported several of our Plone add-ons to Python 3 and Plone 5.2:

Carlos de la Guardia created a set of Pyramid Quick Tutorials on Glitch – more about that coming in another post.

Matthew Wilkes and Jesse researched the best way to set up Pyramid functional tests using pytest and webtest in an efficient manner. They were unhappy with their previous model, which relied on in-memory databases. They settled on a pattern that switched out private variables of the sessionmaker to join a longer-running transaction for each test. This is more self-contained than adapting the session setup machinery in the app itself, and works transparently on different database backends. Matthew made a gist of the relevant code.

Alec made a prototype of an app to provide faceted search of bibliography references kept in Zotero. The app has a Elasticsearch backend and a React front end. It uses the Zotero API to pull the references into Elasticsearch for querying.

Carlos investigated what it would take to move the CastleCMS quality checking features into a Plone add-on. It’s a work in progress.

Left to right: Carlos, Sally, Matthew, Alec, Jesse and Nate in front of a painting of the Griffith Observatory

It’s wonderful to be able to work together in person, instead of remotely from our home offices spread across 3 countries and 2 continents. We try to do it once a year and always have a fantastic time. This year was no exception.

Sprinting in Sorrento

Posted by Jazkarta Blog on May 08, 2019 10:44 PM

Sunset over the island of Capri, as viewed from the sprint venue

This year I helped organize the annual sprint in Sorrento called the Plone Open Garden. Plone is a highly secure and feature rich open source content management system written in Python. Plone has no single company behind it, its IP is held by a non-profit foundation. Progress on the software happens through the efforts of a self-directed community, whose members sponsor sprints to work on particular problems.

PLOG took place April 12-19 and it was a great success, attended by 18 people from 7 countries. There were two training classes:

  • Porting Plone sites and add-ons to Python 3
  • Creating a web application using the restapi and Volto, the new React front end for Plone

We also accomplished a lot of work:

  • Python 3 ports of over a dozen Plone add-ons
  • Accessibility improvements for classic Plone and Volto front ends
  • New Volto features and documentation
  • Marketing discussions
  • Documentation discussions
  • …and various other Plone improvements

I posted a news item on that describes the details of what we accomplished. But Plone sprints have a social side as well as a technical side. Friendships are renewed, meals and news are shared, and a good time is had by all. This year’s PLOG was true to form. Here are some of the things we enjoyed.

1) Breakfasts at the Hotel Mediterraneo, the sprint venue since 2007. Pictured below is the pastry table; there are also tables for cheeses, meats, fruits, breads, cereals, eggs, and more. You can squeeze your own orange juice and optionally add some Prosecco.

Breakfast buffet at the Hotel Mediterraneo - the pastry table

Dinners, also included, are a wonderful way to end a day of sprinting. First and second course, plus dessert.

A typical dessert at the Hotel Mediterraneo

2) Happy hour at the Mediterraneo. We book the rooftop for happy hour at least once during the sprint, where we enjoy the sunset over Capri (pictured at the top of this post) and the extensive cocktail menu. That’s a Black Mohito at the top and a Negroni at the bottom.

 Drinks from the Hotel Mediterraneo cocktail menu

3) Excursions. One day we walked to Sorrento’s old harbor and had lunch with a view of Mount Vesuvius.

A view looking down at Sorrento's old harbor

4) Being with old friends and meeting new ones. Always the best part.

Sprinters on the rooftop of the Hotel Mediterraneo


Plone Welcomes Students for Google Summer of Code 2019

Posted by PLONE.ORG on May 08, 2019 11:00 AM

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school.

Competition to participate is intense, both for open source projects and for students. While Plone has participated successfully many times, for this year other projects got in. Yet, thanks to the friendly folks at the Python Software Foundation, who function as an 'umbrella' organization, we can still work together with three students. Thanks, PSF!

The students are:

To them: welcome to the Plone community – we wish you a great learning experience over the coming summer. Congratulations!

Mentoring them will be these fine folks:

  • Ramon Navarro Bosch
  • Nathan Van Gheem
  • Kumar Akshay
  • Timo Stollenwerk
  • Asko Soukka
  • Nilesh Gulia
  • Shriyansh Agrawal
  • Oshane Bailey
  • Dylan Jay

with support from Cris Ewing.

Fun fact: an astounding 5 out of those 9 have been GSoC students themselves!

Plone Selected to Participate in First Google Season of Docs

Posted by PLONE.ORG on May 02, 2019 07:54 PM

Google is trying out a new program this year called Season of Docs whose goal is to provide a framework for technical writers and open source projects to work together on improving the project's documentation. Paul Roeland and Sven Strack recognized this as an excellent opportunity to improve Plone documentation, and aided by discussions at PLOG (as described in the sprint report), Paul put together the winning proposal.

We are now listed as a Season of Docs participating organization, which means that tech writers interested in the program will soon be browsing our Season of Docs ideas page where we have two projects listed:

  • Improve the Developer Onboarding Experience for Plone 6
  • Improve Documentation for the React-based Frontend "Volto"

Thank you to everyone who made this happen!

The Return of PLOG

Posted by PLONE.ORG on April 30, 2019 03:29 PM

After taking a break in 2018, the Plone Open Garden sprint took place from April 12-19, 2019. There were 2 big innovations this year - a new sprinting space and 2 free training classes. We also had daily discussions, sprinted on a variety of topics, and one day had an excursion to Sorrento's old harbor. Combined with the Hotel Mediterraneo's outstanding food and amenities this all hit the sweet spot of hard work + fun that our community loves. The 18 attendees, who came from 7 different countries, enthusiastically endorsed doing it again next year.

New Space

Sprinting Space in the Gazebo at the Hotel Mediterraneo

For those who remember the old basement room, this is a welcome change. The basement is now off limits because it's being made into a spa, so the hotel set up a working area for us in the gazebo next to the pool. We had some chilly mornings but the heaters made it comfortable. We even had couches!

Lounges in the gazebo at the Hotel Mediterraneo


PLOG has historically been a relaxed gathering, more focused on sharing ideas and debating the future of Plone than on single-minded sprinting on a single topic. It also falls halfway between Plone Conferences when Plone training is offered. In order to expand Plone training opportunities, this year the Plone Foundation sponsored free training classes at PLOG. Training was scheduled during the mornings, leaving the afternoons free for sprinting. On Saturday, Sunday and Monday Philip Bauer taught everyone how to port Plone add-ons and migrate sites to Python 3. On Tuesday, Wednesday and Thursday Victor Fernandez de Alba and Rob Gietema led attendees through the steps for developing a React front end for Plone using Volto.

Training was from 10 to 1, and before that we started every day with a traditional what-did-you-do-yesterday, what-will-you-do-today standup.

PLOG standup befor Volto training starts

Brainstorming Sprint Topics

The first day of the sprint, we spent some time brainstorming sprint topics and prioritizing them with colored sticky dots. This informed the discussions we had later in the week, as well as specific items people worked on. Erico Andrei and Maik Derstappen are holding up one of 2 sheets of paper we covered with ideas.

PLOG Brainstorming

 Python 3 Porting

 To practice what we'd learned in the training class, sprint participants worked on porting the following add-ons to Python 3:

  • Kim Paulissen - collective.badge, collective.workspace
  • Fulvio Casali - collective.onlogin, atreal.massloader
  • Jeremy Kolbe - collective.embeddedpage
  • Thomas Buchberger - ftw.testing, 4teamwork packages
  • Max Jakob - LMU university package
  • Jan Mevissen and Philipp Hewera - several Interaktiv packages
  • Andrea Cecchi - Red Turtle packages
  • Philip Bauer - collective.roster, plone.z3ctable

Also several databases were successfully migrated to Python 3.

Volto and Restapi Improvements

Maik, Rob, Thomas, and others had several discussions about the restapi. Maik and Rob focused on plone.restapi improvements to make it easier for a client (Volto) to access and interpret schema/widget information, and they created PRs for some of the ideas. Eric Steele did some restapi cleanup.

Victor, Eric, and Paul Roeland worked on Volto documentation. They reviewed the current docs, added placeholders for missing topics, and began writing documentation for the placeholders. Eric implemented the add-ons control panel in Volto.

Andrea began work on a bug with the Event datetime widget, he will continue with that.

Victor worked on a number of other improvements: adapt Volto to the new vocabularies endpoint changes and implement the new widgets based on react-select library, api folder update to use 5.2 and cleanup, worked on the new object navigator for tiles and other UX elements, also fixed hero tile image bug if it was in a private container, merged PR for contact form, upgraded Volto to use Razzle 3 and migrated the existing Robot Framework acceptance tests to use Cypress instead.

Paul and others noted that Volto is very approachable and fun to develop with. Paul tried adding a small library (Isotope) which worked. It's important to note that React newbies and enthusiasts will be able to build sites with it. Everyone at the sprint was impressed with Volto and enjoyed the training.

Volto Positioning

Plone 6 will ship with Volto, as well as the “classic” front end. We discussed the need to start messaging about the upcoming changes. Some ideas:

  • Volto makes Plone fun again - tinkerers like Paul can quickly try things out. It's a fun new front end with the same mature, super secure, industrial strength backend that's been refined for more than a decade to provide serious CMS functionality.
  • kitconcept presented Volto at a Javascript unconference and found that people were very impressed with the functionality - apparently the Javascript crowd is completely unfamiliar with the idea of the basic concepts of a CMS. Victor thinks we could base a sales pitch around CMS functionality, which is not old-fashioned any more, at this point it is completely forgotten… “Robust content management functionality for React developers”
  • The documentation needs to provide a matrix of use cases to help people decide when to use Volto and when to use Classic.
  • We need to start thinking about how to adjust messaging on - perhaps the “Plone 5” tab should be replaced with “Plone 6” and info about what’s coming.

Plone and Volto Accessibility

Paul curated all the Plone accessibility tickets and made a Github project board. Sally Kleinfeldt and Paul made new tickets for accessibility issues in Plone and Volto, including alt text in various contexts, integrating an accessibility checker, and creating an accessibility control panel. We made sure all tickets have full information about what the issue is, how to fix it, relevant standards, etc.

Victor worked on entering contextual alt text in the Volto rich text editor. (Like CMFPlone #2836 but for Volto.) Andrea worked on entering and displaying alt text for Plone images and lead images.

Plone Documentation

We had a good discussion and decided we will apply for 2 Google Season of Docs projects. Paul is working on this.

  1. For help completing the Volto documentation.
  2. For help reorganizing the Plone documentation by reviewing what we have and designing a set of user journeys through it.

We also agreed that ultimately we need 4 types of documentation.

  • Reference Documentation - Technical details (can be auto-generated)
  • Long Trainings - Similar to Mastering Plone (some that we have are good, some need a rewrite, some need to be created, for example one about Volto)
  • Quickstart for Editors -  Story driven, on-boarding material for new editors (we can base this on the “Working with Content” section of the current documentation)
  • Quickstart for Developers - Story driven, on-boarding material for new developers (small chunks of tutorial style information describing best practices - Philip started this: Mastering Plone Lite)

We agreed that from now on either ReST or Markdown can be used for Plone documentation, since Sphinx can handle both. Completely new documentation should probably be written in Markdown, as long as no specific features of ReST are required. Especially for folks not coming from a Python programmer background, Markdown has way more traction.

Mosaic Improvements

The group discussed the benefits of adding Mosaic to the default Plone installer in 5.2. For this to happen, we need to do a bit of polishing. Maik started by evaluating the current state and found several issues. Then he and Asko Soukka worked to fix them, including fixing issues. Maik also spent some time thinking about a better Mosaic default setup with preconfigured Mosaic content types and layouts that would make it easier for users to get started.

Plone Improvements

  • Philip - Fixed the last two blockers for Plone 5.2 (will release an rc2 and rc3-pending), updated dependencies.
  • Eric - Solved Zope crashing issue with templates
  • Maik - Improved plonecli, a tool for creating Plone packages with mrbob

The group also took a look at CastleCMS to see what we can learn or port from it.

Migrating ZServer to Python 3

Asko worked on a “moonshot” project to attempt a ZServer Python 3 port, and explore the possibilities that would allow. His work at the sprint was a success and he will continue to work on completing the port. He expects something stable around the time of the June Beethoven Sprint, where he will work on migrating collective.taskqueue to support the new ZServer. If he continues to progress without issues, he hopes this will be ready for Plone 6. See his Community post for more details.


We discussed Plone/Volto marketing and decided to brainstorm marketing tasks we could accomplish in sprints. Ideas included doc sprints to improve and refocus our documentation, sprints focused on making short videos and screencasts of Plone/Volto features, creating a dockerized Plone to give people to try out, getting Plone featured on popular places like Razzel, Python Bytes and Talk Python, having a React Europe booth, and encouraging more news/blog posts on

Plone YouTube Channel

An idea that came out of the marketing discussion was to have a "Plone" YouTube channel. Erico had previously created a "Plone Conference" YouTube channel and did a great job creating a nice home page and adding conference videos for 2013, 2016, 2017, and 2018. We agreed we should expand that with things like How To videos, so Erico renamed it and now we have our Plone YouTube channel! We made a list of videos and screencasts to create at a future sprint.

Plone Conference

Philip and Andrea discussed what trainings to give at the upcoming Conference in Ferrara, and Andrea released the Conference website which is built with Plone 5.2 on Python 3 and Gatsby!

Plan for Next Year

We talked about the possibility of continuing the April PLOG tradition. All attendees were positive about doing it again next year. Things we liked:

  • Half day training, half day sprinting
  • Daily standups
  • Daily group discussions on various topics
  • Including an excursion to a local attraction such as Vesuvius, Pompeii, Capri or Sorrento
  • Having the flexibility to work on one's own project during the sprint
  • The hotel accommodations and food (very reasonable)
  • The happy hour drinks (expensive, but hey…)

The tentative date is the week before Easter, April 3-10. Mark your calendars!

Capri Sunset


German Language Plone Community’s 2019 Networking Kickoff

Posted by PLONE.ORG on March 15, 2019 09:55 AM

The Plone Tagung took place once again this year under the auspices of the German University Conference. From the 25th to the 27th of February 2019, developers, providers and users within the German-language Plone community met at the Institute for Informatics at the University of Munich to debate the question “What could the future of Plone look like? 

Keynote Address

Timo Stollenwerk presenting at Plone Tagung

Timo Stollenwerk offered an introduction right off the bat with his keynote address "Plone: User Experience Revisited". During his presentation he talked about his vision for a modern Plone editor. He gave us a peek into Volto, a new approach to integrating a modern user interface with a new editor into Plone.


Volto is based on ReactJS and represents an alternative to the classic Plone user interface. It is already available for use and will be a standard offering in Plone 6. The classic interface will also remain available, however. This will not change in the near future, given that many users still depend upon it, and alternative interfaces must first stand the test of time.

Python 3

An important issue for the global Plone community is the expiration of support for Python 2.7 on January 1, 2020. With this in mind, Plone developers and integrators are facing the challenge of upgrading Plone sites to Python 3 over the coming months. In his keynote "Python 3 - So What?", Philip Bauer brought the Plone Tagung participants up to date on the upcoming release of Plone 5.2 with Python 3 support. He offered several practical approaches to the community’s burning questions, such as how ongoing projects and add-ons can be migrated to Python 3, what to do with archetype-based content and add-ons that are not supported under Plone 5.2 and Python 3, as well as the time, effort and complications involved and where help can be found.

Twenty-five Presentations

With participants and speakers from Germany, Austria and Switzerland, the Plone Tagung was an international event. The Plone Tagung is an opportunity for everyone to network with other Plonistas, and the 25 presentations topped it all off with a variety of interesting, relevant and broadly-based themes.


A special subset of participants again this year were representatives of German post-secondary institutions, who attended within the context of the annual University Conference. Many post-secondary institutions use Plone as their content management system, especially the faculties for which performance and security are paramount.

Through presentations and during open discussions, Plone developers, members of the Plone core team, integrators, users, and representatives of post-secondary institutions had the opportunity to exchange ideas and experiences. 

Learning Opportunities

Several of the talks offered learning opportunities and technology demonstrations. Maik Derstappen, for example, demonstrated how a to-do app can be generated as an extension for Plone in under five minutes with the help of PloneCLI. Other presentations focused on case studies in which website projects, intranet projects and other applications have been developed using Plone.

Plone migration was a recurring theme: what challenges are presented by a migration, whether to Plone from other CMSs, or from older to newer versions of Plone, and what tools and approaches should be used? Various editing experiences with Plone – in comparison to those of other open source CMSes, some of whose representatives were also present at the conference – were the subjects of several talks.

Alexander Loechel struck a chord with an emotional appeal to the audience to share upcoming tasks and responsibilities across a wider base, in consideration of the time and emotional well-being of individual community members. An interesting starting point of his personal appeal was the Google Summer of Code project to create an automated listing of all available Plone add-ons on Anyone interested in getting more involved in the Plone community is most welcome and should get in touch over Twitter, Facebook, or through the Plone forum.

Open Spaces – Room for Everyone

Open Spaces are community-tested formats in which everyone is first invited to introduce their topics of interest, whether in presentation, suggestion or request form. Those interested in individual topics then gather in groups for a discussion session. About 10 such sessions took place during the Plone Tagung, focusing not only on technical topics but also on subjects such as cooperative models in software development.

Discussion at Plone Tagung

Quo Vadis Plone?

The conference ended on a positive note with a panel discussion entitled “Quo Vadis Plone?” The discussion seized the reins of the first day’s keynote once again and addressed assumptions relating to the further development and future of Plone. Alexander Pilz, manager of a Munich-based Plone agency, and Jens Klein, member of the Plone Framework Team and manager of an Innsbruck-based Plone agency, answered questions put by Philip Bauer and the audience. Among other topics, the discussion included ideas for how the community might work together more effectively, as well as conceptions of what Plone might look like in 20 years.

For example, it was decided at the Plone Tagung that the Plone brochure is due for a new edition. Assistance on this project is welcome!

Encore: Two Sprint Days

What would a Plone event be without a sprint? Fifteen Plone developers met after the conference to work together on some important issues. Progress was made on the Python 3 migration of add-ons and a prototype was developed of a database for Plone extensions that operates automatically using metadata. In addition, the PloneCLI and its underlying bobtemplates.plone developer tools were optimized for the development of extensions under Python 3 and Python 2.7.

Plone Tagung 2020: Dresden

Of particular importance to the Plone community is promoting community work and giving all members and interested parties the opportunity to get involved during the Plone Tagung while also expanding their networks.

The goal of bringing the German-speaking Plone community from Germany, Austria and Switzerland closer together was successfully realized this year. We want to continue to build on this momentum and we are pleased to announce that the next Plone Tagung will be held in Dresden in 2020.

Let’s make next year an even greater success! We extend our sincerest thanks to all participants, speakers, organizers and sponsors, without whom this event would not have been possible. We hope to see you all again next year at the Plone Tagung 2020 in Dresden. Information on the conference will be published in due time at the Plone Tagung website. Follow us on Twitter, Facebook or in the forum.

View more Plone Tagung photos on Flickr.

Twitter: @plone_de



PloneGov growing in the Basque Country

Posted by CodeSyntax on March 05, 2019 12:59 PM
PloneGov is an international initiative with the goal of getting a powerful on-line eGovernment tool. Most eGovernement needs and requirements are similar and PloneGov wants to satisfy them in a effective and efficient way thanks to its open source project. CodeSyntax is part of PloneGov thanks to its UdalPlone initiative.

Four options to try Plone 5.2 on Python 3

Posted by on January 24, 2019 08:30 AM

Demo pages

There are nightly build of the current Plone 5.2 coredev (the development version) with Python 2 and 3:

Minimal Buildout

Here is a minimal buildout to run Plone 5.2rc1 on Python 3:


parts = instance

extends =


recipe = plone.recipe.zope2instance

eggs =



You set it up like this:

$ python3.7 -m venv .

$ ./bin/pip install -r

$ ./bin/buildout

And start it as usual with ./bin/instance fg

Standalone Development buildout


extends =

parts =






eggs =




test-eggs =

    collective.easyform [test]

auto-checkout =


extensions =


show-picked-versions = true


recipe = plone.recipe.zope2instance

user = admin:admin

eggs = ${buildout:eggs}

debug-mode = on

verbose-security = on


recipe = zc.recipe.egg

eggs =


interpreter = zopepy

scripts =




recipe = collective.recipe.omelette

ignore-develop = False

eggs = ${buildout:eggs}

ignores = roman


recipe = collective.xmltestreport

eggs = ${buildout:test-eggs}

defaults = ['--auto-color', '--auto-progress']


recipe = zc.recipe.egg

eggs =




collective.easyform = git branch=python3


Starzel buildout

The buildout that we at use supports Plone 5.2rc1 with Python 2 and 3.

It has some nice features:

  • It extends to config- and version-files on github shared by all projects that use the same version of Plone.
  • It allows to update a project simply by changing the version it extends.
  • It allows to update all projects of one version by changing remote files (very useful for HotFixes).
  • It is minimal work to setup a new project.
  • It has presets for development, testing, staging and production.
  • It has all the nice development-helpers we use.


$ git clone -b 5.2rc1.x <SOME_PROJECT>


Remove all files that are not needed for a project but are only used for the buildout itself.

$ rm -rf linkto README.rst README.txt .travis.yml secret.cfg_tmpl VERSION.txt local_coredev.cfg CHANGES.rst

If you're not developing the buildout itself you want a create a new git repo.

$ rm -rf .git && git init

Add a file that contains a passwort. Do not use admin as a password in production!

$ echo -e "[buildout]\nlogin = admin\npassword = admin" > secret.cfg

Symlink to the file that best fits you local environment. At first that is usually development. Later you can use production or test. This buildout only uses local.cfg and ignores all local_*.cfg.

$ ln -s local_develop.cfg local.cfg

Create a virtualenv in Python 2.7 or Python 3.7 (Plone 5.2 only).

$ virtualenv .  # for Python 2.7

$ python3.7 -m venv .  # for Python 3 (Plone 5.2 only)

Install and configure Plone

$ ./bin/pip install -r requirements.txt

$ ./bin/buildout


I hope these options help you get started with Python 3. For serious projects you will likely create you own buildout.

Update (4.2.2019)

You should use the Plone coredev for developing Plone itself:

$ git clone coredev
$ cd coredev
$ git checkout 5.2
$ python3.7 -m venv .
$ ./bin/pip install -r requirements.txt
$ ./bin/buildout
$ ./bin/instance fg

Update 2 (24.2.2019)

Since Plone 5.2b2 wsgi is the default, even when running Python 2. See

This means you do not need to enable wsgi = on since it will be enabled automatically. You can still choose to switch wsgi = off in Python 2 if you have a good reason to do so (e.g. you need FTP or WebDAV). I updated the examples accordingly.

Update 3 (8.3.2019)

Release candidate 1 of Plone 5.2 is pending. See I updated the examples accordingly.

Happy New Year, and Thank you, Foundation Sponsors, for a Wonderful 2018!

Posted by PLONE.ORG on January 01, 2019 10:45 PM

Happy new year!

We wanted to take a moment to recognize the organizations and individuals who supported the Plone Foundation with their donations this past year. Without their financial support, we could not have funded the many, many sprints held around the world in 2018, nor could we have continued to run the servers, paid for domains and services such as trademark and legal protection, nor gotten our valiant Google Summer of Code students to present their work in Tokyo.

We also thank Interaktiv for their brilliant Game of Plones t-shirt giveaway, which inspired many donations to the Foundation.

If you or your organization are not yet Foundation sponsors, please consider joining in and helping us continue to promote and protect this wonderful (and growing!) community. Even $10 monthly recurring donations help us help you.

Become a Sponsor

Premium Sponsors

  • Niteoweb
  • Enfold Systems
  • theVirtual
  • PSW Group
  • Syslab
  • Soliton Consulting
  • IMIO
  • Wildcard Corp.
  • Jazkarta
  • Six Feet Up
  • Universitat Politècnica de Catalunya
  • Starzel de

Standard Sponsors

  • Zopyx
  • Affinitic
  • Interaktiv
  • Programmatic
  • derico
  • Webmeisterei
  • Operun
  • Slotenmaker Rotterdam
  • Agile Coach
  • Slotenmaker Amsterdam
  • testalize me
  • Maid2Clean
  • AAHS Slotenservice
  • cloud19

University Sponsors

  • Université de Namur

Foundation Heroes

The Plone community couldn't exist without the continuing contributions of individuals, in both time and money. Thank you to the following individuals for their donations this year:

  • Correa Balier
  • Giuseppe Romagnoli
  • Steve McMahon
  • Lucas Aquino
  • Hector Velarde
  • Elizabeth Leddy
  • Cris Ewing
  • Eric Steele
  • Paul Roeland
  • T. Kim Nguyen
  • Rikupekka Oksanen
  • Alin-Nicolae Voinea
  • Roel Bruggink
  • Andrea Cecchi
  • Frederic Iterbeke
  • Ramiro Batista da Luz
  • Simon Delcourt
  • Bert Vanderbauwhede
  • Gauthier Bastien

Plone finally supports Python 3!

Posted by on November 29, 2018 09:21 AM

At the Plone Conference 2018 in Tokyo I gave a plenary talk in which I told the story how Plone got to support Python 3. Ten minutes before my talk Plone 5.2a1 was released. That release was the culmination of a 3-year long journey (or even 5 years if you start in Brazil). If you want to learn how we got there you should watch the talk.

Where are we now?

Plone 5.2 supports Python 3.7, 3.6 and 2.7. It is currently in alpha but the plan is to release a final version in February 2019 right after the Alpine City Sprint. You should seriously consider joining that sprint if you plan to migrate your own projects. Working together with the people who ported Plone to Python 3 will give you the know-how to succeed in your own migrations!

But in fact you should not wait until February to start working with Plone on Python 3 but start right now so you'll have enough time to migrate to Python 3 before January 1st 2020 (End of Life of Python 2).

To make testing and working with Python 3 easier some tools and addons were already working on Python 3.

The following essential development-tools are already ported:

Also the three addons that achieved the highest ranking during the latest poll at Ploneconf now work on Python 3:

You can also run the new frontend Volto with Plone on Python 3.

Open tasks

Before the final release of Plone 5.2 scheduled for February 2019 there are still a lot of things to do.

Here are the six most pressing issues:

  1. The upgrade- and porting-guide need to be completed.
  2. ZODB migration needs to be finished and documented.
  3. Much more addons need to be ported and released.
  4. We require performance tests.
  5. People who really need a replacement for FTP and/or WebDAV need to figure out how to do that.

There is still a lot to do. You can help Plone by coming to a sprint, testing it and fixing or reporting a bug.

Migrating to Python 3

From 1.1.2020 on you'll have to inform your clients that you are running their super-secure system on an unsupported version of Python. That might be ok if you're running a small website for a friend but for serious projects this simply will not do. Instead you should start to adopt Python 3 in your Plone projects now. You need to start early and plan ahead!

Here are the six steps you have to follow to upgrade to Python 3. Do not attempt to do all steps at once, instead you should work iteratively and even deploy to production in between steps.

1. Upgrade to Plone 5.2

You should still use Python 2.7 for this step. The changes between Plone 5.1 and Plone 5.2 are not huge but you will gain some great features including a new and much faster dropdown-navigation and a bootstrap-based ZMI.

The Upgrade-Guide for 5.2 still needs much more love. So if you encounter any issues please update that document and/or create a ticket in github.

2. Drop Archetypes and only use Dexterity

Archetypes is still supported on Plone 5.2 but only when running with Python 2.7. It is now officially deprecated and is not ported to Python 3. There has been a built-in migration for default types from Archetypes to Dexterity since 2013, and since 2015 there have been helpers and even a form that allows you to migrate your custom content.

3. Migrate your code to Python 3

Follow the documentation in to migrate your custom code and any addons that you need in your packages.

  • Make sure your code works in Python 2 and Python 3. If you are certain that you will not publish that code as a addon or reuse it in another project you can also drop support for Python 2. That will make porting and testing easier.
  • For most addons: Use python-modernize as described in the documentation.
  • For small addons you could even simply try to startup on Python 3 and and fix whatever fails (e.g. relative imports or invalid syntax)
  • Manually fix whatever python-modernize misses (e.g. relative imports)
  • Do the same with tests. You'll need a test-setup with tox and a test-matrix in travis that tests different Python versions. The setup in collective.ifttt is almost done and might be a good example.
  • If you have complex doctests consider migrating them to python tests since these are easier to get to pass in both Python 2 and 3. If you do want to keep them as doctests, change them so that the output for Python 3 is the default and use a Py23DocChecker to make the tests pass in Python 2 as well. See the example in plone.indexer.
  • Once all seems to work you need to test every single feature manually because even a high test coverage is never a guarantee that your code actually does what it should.

4. Migrate Addons and Dependencies

Now migrate any addons you use to Python 3 as explained above. The main difference is that now everyone who uses this addon benefits. You shoud not drop support for Python 2 for those!

I listed the addons that already run on Python 3 above. I'm sure that list will be outdated very soon. Before you start migrating an addon you need to check if there already is a branch that supports Python 3 and check if there is a ticket like the one for collective.easyform. If not create such a ticket and start the process.

5. Migrate your Database

ZODB itself is compatible with Python 3 but a database that was created in Python 2.7 cannot be used in Python 3 without being modified first. I will not go into details about that. You should read the documentation and see David Glick's talk.

The migration will probably require some downtime and in rare cases you might have to write your own mappings to tell zodbupdate how to handle your data.

6. Deploy on Python 3

Plone 5.2 will use WSGI with waitress as the default WSGI server. Alternatively you can use uwsgi or gunicorn. ZServer can only be used with Python 2.7.

Some deployment tools may not ported yet, others like ZRS or RelStorage already support Python 3. You should test your production setup early. There may be changes that you don't want to struggle with a week before a scheduled launch.

Summing up

Start that whole process as early as possible because you may need to deal with unexpected problems and addons that you did not know still used Archetypes. 2019 might be much busier for you than you expect.

Do not wait for a final release of Plone 5.2! Start the process of planning and testing a migration. Consinder hiring experts to help you if necessary.

Again: You can and you should work iteratively. That means you do not have to do everything in one step and one night:

  • Upgrade to 5.2 with Dexterity on Python 2 and deploy that early in 2019.
  • Then take some time to migrate and test your code and addons.
  • You can then deploy the Python 3-compatible code while still running Python 2.7.
  • Then you can migrate your existing database and deploy on Python 3.


Here are some questions you might have:

What about Python 4?

That will not be a big issue since 4.0 will be a upgrade like from 3.7 to 3.8. The Python community simply don't want to release a Python 3.10.

When will Plone drop support for Python 2?

Not before we have a good reason. Maybe Plone 7? It would allow us to remove and clean up some code but we would not gain a lot.

What about Zope 5?

There are no real plans for that yet.

Will Archetypes be migrated to Python 3?

Please don't try to postpone the inevitable. We are too small a community to maintain two Python versions, two frontends and two content type frameworks.

How do we replace FTP/WebDAV?

I don't know, for WebDAV you might be able to use a middleware like WsgiDAV.

Why did you make all that effort and not 'simply' migrate to Guillotina?

Guillotina does not aim to be a replacement for Plone. Also it has no equivalent addon ecosystem, feature equality or migration path.

Can I now use async/await?

You can but it won't really help you since Plone and Zope are still fundamentally synchronous.

Why doesn't the Plone Foundation simply buy support for Python 2.7 from RedHat/IBM for all of us?

Are you kidding me?

Does Python 3 make Plone run faster?

Maybe. We still lack performance tests but my guess is that Plone 5.2 will run faster on Python 3 than on 2.

Can I run the same Database in Python 2 and 3?

No.You can neither use a DB create with py2 in py3 nor use one created with py3 in py2.

Is addon xyz already ported?

Most likely not.

Plone supports the latest two major version. Does that extend to Python?

Plone's security update policy supports the latest two major versions (currently, that means the 5.x series and the 4.3.x series) with security updates. That guarantee does not extend to the programming language, the operating systen or the hardware you are running Plone on.

Will this work on Windows?

Very likely. Someone will have to test it.

I need help with migrating our projects to Python 3. Who can help me?

Talk to us at or ask other professionals with experience.

Warm words

Migrating Plone to Python 3 was quite a ride and a great community effort. I had to cope with some brain-melting changes in Zope, fight heartbreaking test-isolation issues and toil through an endless list of packages and tests. But I had the immense privilege and pleasure to do all of that together with some of the smartest and nicest people I know. Thanks to all of you!

Watch the full talk if you want to learn more about how Plone finally landed on Python 3.

Here are all videos from Ploneconf 2018: Day 1, Day 2, Day 3.

Thank you, Plone Conference 2018 Tokyo!

Posted by PLONE.ORG on November 17, 2018 08:57 PM

It is with a full heart that we bid farewell to the just ended Plone Conference 2018 Tokyo, and we offer our enduring gratitude to organizers Manabu Terada, Takeshi Yamamoto, Zenichiro Yasuda, Takanori Suzuki, Sakai, and Kinofumi for their wonderfully warm welcome and flawless event planning at the PiO conference centre.

Attendees came to Tokyo from 27 countries around the world! (Bangladesh, Belgium, Brazil, Catalonia, Denmark, Finland, France, Germany, India, Italy, Jamaica, Japan, Korea, Luxembourg, Mexico, Netherlands, Philippines, Poland, Romania, Slovenia, South Africa, Spain, Switzerland, Taiwan, Thailand, UK, USA) 

Over half of them took at least one of the free training classes covering beginner, intermediate, and expert topics, from Learn Plone to Mastering Plone Development, with by far the most interest focused on the React and Volto (Plone React) classes. 

Each day began with keynotes by Eric Steele, Jim Fulton, and Torajiro Aida, followed by 44 talks in four streams: three for Plone and one daily stream on Python Web, Database, and Frontend.

As is our tradition, the conference also included two days of sprints where again almost half our attendees worked in self-organizing teams to collaboratively contribute to the Plone project and community. (see the shared sprint document to find out what was worked on). At the sprint, it was with great pleasure that we conferred the Most Productive Sprinter trophy on first time sprinter Paul Grunewald!

Work presented at this year's conference showed that Plone's future is bright, with at least three future paths:

  • traditional Plone: Plone 5.2 running on Python 3 is well on its way, thanks to a huge effort by many, including the Zope community
  • headless Plone: a modern JavaScript Volto (Plone React) frontend with the new Pastanaga UI running against a Plone backend via REST API
  • Async Plone: Guillotina CMS

We are left with indelible memories

  • Plonistas making their way through the labyrinth of Tokyo commuter railway stations, phones in hand with open map apps
  • Akihabara's bright lights and towering stores full of anime and electronic goodies
  • Visiting temples, castles, and shrines
  • Poking our heads into tiny bars, restaurants, and karaoke bars

Look for photos and tweets tagged with #ploneconf2018. (talk videos and slides coming soon)

We look forward to seeing you at sprints and events in 2019!

ありがとうございました Arigatō gozaimashita! 

Plone Conference 2019 will be in Ferrara, Italy

Posted by PLONE.ORG on November 12, 2018 06:37 PM

Following on the heels of the successful, inspiring Tokyo Plone Conference 2018, the Plone Foundation Board is very pleased to announce that Plone Conference 2019 will be in Ferrara, Italy!

Located in northern Italy, near Bologna, Venice, and Milan, Ferrara is the home of RedTurtle, a long time provider of Plone solutions.

Stay tuned for further details!

What next(1).jpg

What next(2).jpg

What next(3).jpg

What next(4).jpg

Plone on Python 3 is Closer to Reality Thanks to Huge Sprint

Posted by PLONE.ORG on November 12, 2018 05:31 PM

In October 2018, 34 Plone developers joined forces for a major push to move Plone to Python 3, implement improvements in Zope 4, and bring Plone 5.2 closer to a final release during a sprint held in the gocept offices in Halle, Gemany. 

Given the large number of people on hand for the sprint, a huge list of achievements were reported:

Read the full report here.

The attendees celebrated Plone's 17th birthday with a barbecue and party in true Plone style. Thank you to Philip Bauer for organizing.

The organizers want to thank gocept for the use of their amazing offices and allowing the community to take advantage of the palace-like salon, cafe Kaffej, and the excellent cappuccino.

Our appreciation also goes out to Plone Foundation, and the German Python Software Foundation (PySV) for their support.

Thank you to the amazing attendees for their hard work during this intense 5 day sprint.

Finally, we could not accomplish these things without the sprinters, so a huge thank you to them on behalf of the entire Plone community!


Sorrento Sprint on Frontend Modernization

Posted by PLONE.ORG on November 07, 2018 08:12 AM

Our perennial Plone Open Garden sprint returns for 2019!

Date: April 7-14, 2019

Location: Hotel Mediterraneo

Registration deadline: February 28, 2019

Price per day (includes breakfast and dinner):

  • Double room for 1 person: 150 €
  • Double room for 2 people: 160 €
  • Triple room for 3 people: 180 €

The focus of this sprint will be to bring Plone more in line with what front end developers and content editors expect in a CMS these days. We will emphasize efforts that will improve the experience for both traditional Plone (5) and future Plone (Volto, Guillotina, etc.) Wherever possible, we will strive to make features available in both ecosystems. We hope to attract both traditional Plone and future Plone developers and provide a venue and topics that will encourage cross-fertilization. The goal of the sprint is to focus on efforts that will have high impact for both developers/integrators and non-technical users.


  • Volto aka plone-react
  • Content quality checking
  • Accessibility improvements
  • Contextual image alt text
  • Improved accessibility for overlays, dialogs, and menus
  • ATAG 2.0 Part B compliance: single page and site-wide compliance checkers
  • Incorporate a11y checking into travis/jenkins process
  • Parity between Plone 5 and Volto for accessibility features
  • Supporting service workers for improved performance
  • Plone 5 UX improvements

Additional topic suggestions from the community are welcome!

Follow up discussion will be in our community forum

Help Oshane get to the Tokyo Plone Conference

Posted by David "Pigeonflight" Bain on October 24, 2018 03:38 AM


Oshane Bailey, a talented Plone developer with loads of Plone experience has been selected as a presenter for the 2018 Tokyo Plone Conference. His Japanese visa was just approved.
He will share a streamlined approach to Plone development that he is applying on a Plone project targeted at Jamaican Developers. At the time of writing he has raised about 17% of the funds he needs to get to Tokyo. You can help him get to Japan by contributing to his crowd-funding campaign.

Oct 29, 2018 update
Thanks to generous contributions, Oshane's trip is now 70% funded. You are welcome to join the crowdfund and cover the rest of his trip.

Oct 30, 2018 update

Oshane's trip is now 89% funded. The plane ticket and conference ticket have been purchased. you can still pitch in by joining the crowdfund to cover the rest of his trip.

Since at least 2015, Oshane has worked on Plone projects for teams around the world and in the process has been exposed to varied approaches to the development and ongoing management of Plone sites. Over recent months he has poured his, hard earned, experience, into a side project -- the Jamaican Developers site.  Through this project he has refined a continuous development pipeline based on some of the best techniques used in the Plone community and enhanced with some of his own innovations.

Last year Oshane participated as a Plone Google Summer of Code student and presented his work at the Barcelona conference. He also participated in the after-conference sprints, contributing to efforts to port Plone to Python 3 and also looking into the WebSauna project.

Supporting his trip to Tokyo will serve to enrich PloneConf 2018 in many ways. Here are three that spring immediately to mind:
1) As part of his talk he will share the techniques he is using on the Jamaican Developers site
2) He plans to participate in the after conference sprints.
3) He will bring an important perspective to discussions influenced by constraints common to Jamaican developers.

How to Support Oshane

Appropriately, his crowdfunding campaign is running on the Jamaican Developers site that he built with Plone. His goal is to raise enough to cover his travel and expenses related to the Japan trip.

As we say in Jamaica... "Follow back a me" as I support Oshane's trip to PloneConf2018 in Tokyo.

Python 3, Plone 5.2, Zope 4 and more

Posted by on October 19, 2018 09:14 AM

With over 30 attendees the SaltLabs Sprint was among the bigger sprints in the history of Plone and Zope.

Fortunately, our host Gocept just moved into a new office and had plenty of space to spare. Stylish as we are, the Plone crowd quickly congregated in the palace-like salon with red walls and renaissance paintings. Even better: Throughout the week the cafe Kaffej downstairs was open for us to eat breakfast, lunch and for work. We tried to keep the barista busy producing excellent Cappuccino. Thanks!

Zope 4

The sprint split in two groups, one working on Zope and one working on Plone. A short report on about what happened at the Zope can be found at . Zope 4.0b6 was released just after the sprint. The new Beta 6 includes the new bootstrap-styled ZMI, support for Python 3.7 and a metric ton of bug fixes compared to 4.0b5 which was released in May this year. By the way: Zope can now be installed without buildout using pipenv

Python 3

The Plone crowd was huge and worked on several tasks. The biggest task - and the main reason to join the sprint - was continuing to port Plone to Python 3. Jens Klein, Peter Mathis, Alessandro Pisa, David Glick (remote) and Philip Bauer as lead worked mainly on fixing all remaining failing tests and getting the jenkins-builds to pass. We dove deep into crazy test-isolation-issues but also added a couple of missing features to Dexterity that were so far only tested with Archetypes.

During the sprint we got very close to a green build but a couple of really nasty test-isolation issues prevented a green build. A week after the sprint we finally got that done and all tests of Plone now pass in Python 2.7, Python 3.6 and Python 3.7 with the same code-base!

With the test passing we're now merging that work and preparing the release of Plone 5.2a1. The tasks for this are discussed in this ticket

Deprecate Archetypes

Archetypes will not be ported to Python 3 but still has to work when running Plone 5.2 in Python 2.7. Since all tests that used PloneTestCase were still using Archetypes Philip changed that to use Dexterity now and created a new testlayer ( that is now used by all the packages using the Archetypes-stack. See You could use this layer in your archetypes-based addon-packages that you want to port to Plone 5.2.


Yes, Plone is now able to run on Python 3. But without the huge ecosystem of addons that would be of limited real-world use. Jan Mevissen, Franco Pellegrini (remote) and Philip Bauer ported a couple of addons to Python 3 that Plone developers use all the time:

Being able to run tests against Plone in Python 3, and with these development-tools now available also, it is now viable to start porting other addons to Python 3. To find out how hard that is I started porting collective.easyform. The work is only 97% finished since some tests need more work but it is now useable in Python 3!

ZODB Migration

Harald Friesenegger and Robert Buchholz worked on defining a default migration-story for existing databases using zodbupdate. To discuss the details of this approach we had a hangout with Jim Fulton, David Glick and Sylvain Viollon. They solved a couple of tricky issues and wrote enough documentation. This approach seems to work well enough and the documentation points out some caveats but the ZODB migration will require some more work.

Relevant links:

ZODB Issues

Sune Broendum Woeller worked on a very nasty and complex issue with KeyErrors raising while releasing resources of a connection when closing the ZODB. That happened pretty frequently in our test-suites but was so far unexplained. He analyzed the code and finally was able to add a failing test to prove his theory. Then Jim Fulton realized the problem and wrote a fix for it. This will allow us to update to the newest ZODB-version once it is released. See for details.


Thomas Schorr added the zconsole module to Zope for running scripts and an interactive mode. Using WSGI works in Python 2 and Python 3 and will replace ZServer in Python 3.

Frontend and Theming

Thomas Massman, Fred van Dijk, Johannes Raggam and Maik Derstappen looked into various front-end issues, mainly with the Barceloneta theme. They closed some obsolete tickets and fixed a couple of bugs.

They also fixed some structural issues within the Barceloneta theme. The generated HTML markup now has the correct order of the content columns (main, then left portlets, then right portlets) which allows better styling for mobile devices. Also in the footer area we are now able to add more portlets to generate a nice looking doormat. See the ticket for screenshots and details.

They also discussed a possible enhancement of the Diazo based theming experience by including some functionality of spirit.plone.theming into and cleaning up the Theming Control Panel. A PLIP will follow for that.

New navigation with dropdown support

Peter Holzer (remote) continued to work on the new nativation with dropdown-support which was started on collective.navigation by Johannes Raggam. Due to the new exclude_from_nav index and optimized data structures the new navigation is also much faster than other tree based navigation solutions (10x-30x faster based on some quick tests).

Static Resource Refactoring

Johannes Raggam finished work on his PLIP to restructure static resources. With this we no longer carry 60MB of static resources in the CMFPlone repository, it allows to use different versions of mockup in Plone, enable us to release our libraries on npm and will make it easier to switch to a different framework. Skin scripts removal Katja Süss, Thomas Lotze, Maurits van Rees and Manuel Reinhardt worked hard at removing the remaining python_scripts. The work is still ongoing and it would be great to get rid of the last of these before a final Plone 5.2 release. See for details. Katja also worked on finally removing the old resource registry (for js and css).

Test parallelization

Joni Orponen made a lot of progress on speeding up our test-runs by running different test-layers in parallel. The plan is to get them from 30-60 minutes (depending on server and test-setup) to less than 10 minutes. For a regularly updated status of this work see

Documentation and User-Testing

Paul Roeland fought with robot-tests creating the screenshots for our documentation. And won. A upgrade guide to Plone 5.2 and Python 3 was started by several people. Jörg Zell did some user-testing of Plone on Python 3 and documented some errors that need to be triaged.


Jörg Zell worked on the german translations for Plone and nearly got to 100%. After the sprint Katja Süß did an overall review of the german translation and found some wording issues with need for a discussion

Plone React

Rob Gietema and Roel Bruggink mostly worked on their trainings for React and Plone-react, now renamed to “Volto”. Both will be giving these trainings at Plone Conference in Tokyo. On the second day of the sprint Rob demoed the current state of the new react-based frontend for Plone.

Assorted highlights

  • In a commit from 2016 an invisible whitespace was added to the doctests of plone.api. That now broke our test in very obscure ways. Alessandro used some dark magic to search and destroy.
  • The __repr__ for persistent objects changed breaking a lot of doctests. We still have to figure out how to deal with that. See for details.
  • There was an elaborate setup to control the port during robot-tests. By not setting a port at all the OS actually takes care of this to makes sure the ports do not conflict. See Less is sometimes more.
  • Better late than never: We now have a method safe_nativestring in Products.CMFPlone.utils besides our all-time favorites safe_unicode and safe_encode. It transforms to string (which is bytes in Python 2 and text in Python 3). By the way: There is also zope.schema.NativeString and zope.schema.NativeStringLine.
  • We celebrated the 17th birthday of Plone with a barbecue and a generous helping of drinks.

Tokyo Plone Conference 2018 Talks and Training Classes

Posted by PLONE.ORG on October 18, 2018 07:35 PM

See the Tokyo Plone Conference 2018 talks list, covering a wide range of topics:

  • modern JavaScript frontends, including ReactJS, Angular, Volto, GatsbyJS
  • Zope
  • Pyramid
  • Plone on Python 3
  • headless Plone / Plone API / Guillotina / Guillotina CMS
  • testing and continuous integration
  • current practices for Plone development and deployment
  • Plone theming

Training classes are included with your conference registration – see the training class schedule and class descriptions

Join us in Tokyo next month! Registration and details at

A conference sponsorship would be a great way to show your support for Plone and to enhance your visibility in the community! Find out more about conference sponsorships

Hello Kitty

Photo by Miguel Á. Padriñán from Pexels

Plone 5.1.4 has been released

Posted by PLONE.ORG on October 17, 2018 02:29 PM

Plone 5.1.4 has been released, containing bug fixes and updated packages.

To download it, please see the download page.


plone.recipe.alltests: 1.5 → 1.5.1

Bug fixes:
  • Fix imports when buildout was installed using pip. [davisagli]

plone.recipe.zope2instance: 4.4.0 → 4.4.1

Bug fixes:
  • Make comments in zcml values work, even if not starting at the beginning of the line; before, we had a confusing error message. Fixes #46 [tobiasherp]

plone.releaser: 1.6.0 → 1.7.0

plone.versioncheck: 1.6.5 → 1.6.10

Bug fixes:
  • Better handling of relative paths as entry, like project/foo/dev.cfg. [jensens]

  • If a file does not extend any other file, the return statement was returning only one parameter, while callers expected 2. [gforcada]

  • Fix: Do not trust on setuptools internals. Works now with newest setuptools. [jensens]

  • Fixes another bug in find_relative. [jensens]

  • Fixes bug in find_relative introducued in last release. [jensens]

  • Fixed: Inherited extends with same name showed up as same. Now show relative to basedir if possible, else full. [jensens]

  • Fixed: Relative extends in urls were broken. [jensens] 1.2.1 → 1.3.0

Breaking changes:
  • Remove compatibility code for Plone 4.x. [hvelarde]

  • Skip Support for Plone 4.x. [jensens]

Bug fixes:
  • Add support for Python 3. [davisagli]

  • Support for Plone 5.x toolbar, i18n, ... [jensens]

  • Fix RemoteLibrary i18n to work proper with registry based settings. [jensens]

  • Make robotframework work with merged plone.login. [jensens]

  • Fix Travis CI setup. [jensens]

Pillow: 4.3.0 → 5.2.0

python-dateutil: 2.6.1 → 2.7.3

borg.localrole: 3.1.5 → 3.1.6

Bug fixes:
  • Python 2 / 3 compatibility. [ale-rt, pbauer]

  • Fix issue StopIteration raising a Runtimeerror in Python 3.7 See [pbauer]

diazo: 1.2.9 → 1.2.10

Bug fixes:
  • Fix diazo.debug console with Python 2.7. [pbauer]

icalendar: 4.0.2 → 4.0.3

Bug fixes:
  • Categories are comma separated not 1 per line #265. [cleder]

  • mark test with mixed timezoneaware and naive datetimes as an expected failure. [cleder]

mockup: 2.7.4 → 2.7.6

New features:
  • pat-structure: Use more tooltips in the actions menu. [thet]

  • pat-structure: Move breadcrumbs out of folder contents table. [thet]

  • pat-structure: Use the datatables pattern for sorting columns.

  • Include TinyMCE 4.7.13 [erral]

  • pat-structure: Use the datatables pattern for sorting columns [frapell]

  • pat-structure: Add a '250' option for the pagination. [frapell]

  • Add a new pattern, to provide the DataTables functionality. [frapell]

  • Add package-lock.json to git. See [sunew]

Bug fixes:
  • Structure pattern: Fix URL for current path for popovers. Refs: [thet]

  • Structure pattern: Fix spacing for attribute-columns popover. [tmassman]

  • TinyMCE: Do not fail if initializing with another language or external script [frapell]

  • Get rid of obsolete X-UA-Compatible header. [hvelarde]

  • Fix small message typos. [tkimnguyen]

  • Remove patternslib "This pattern without a name attribute will not be registered!" warnings by setting dummy name and trigger properties. [sunew]

  • Fix error when running tests: "Some of your tests did a full page reload!", due to a form submit with no preventDefault. [sunew]

  • Fix WARN [watcher]: Pattern "..../patterns/foo.js" does not match any file, by excluding all requirements ending with '-url', since they point to a folder and not to a .js file. The folder contents are already included by 'patterns/*/'. [sunew]

  • Move installation and config of sinon from bower+requirejs to karma-sinon. [sunew]

  • Remove chai - it is unused. The assertions being used are from 'expect', installed via bower.json [sunew]

  • Upgrade some build and testing tools: grunt, karma, mocha, their plugins, coveralls, and browser launchers. [sunew]

Plone: 5.1.3 → 5.1.4

New features:
  • Release Plone 5.1.4 [esteele]

plone.api: 1.8.4 → 1.9.0

New features:
  • Python 2/3 support. [pbauer]
Bug fixes:
  • Removed allow-hosts from base.cfg, so we can use the new pypi warehouse. Refs [jaroel]

  • fix typos in doc strings [tkimnguyen]

  • Fix failing AT Collection creation when using api.content.create. [gbastien] 1.2.21 → 1.2.22

New features:
  • Python 3 support [pbauer, MatthewWilkes, ale-rt] 3.5.3 → 3.5.4

Bug fixes:
  • Fix namechooser encoding issue [tomgross]

  • fc_workflow view now reindex the object after state change. This fix the problem that some index dates (effective and modified for example) was updated only when the state was changed from the toolbar. [cekk]

  • Fix various issues in with py3. [pbauer] 2.2.3 → 2.2.4

Bug fixes:
  • Fix sorting of portletmanager-menuitems in py3. [pbauer] 1.4.11 → 1.4.15

Bug fixes:
  • Really revert breaking behavior marker interface changes in 1.4.12. [maurits]

  • The Format accessor should actually return the format attribute (see plone/Products.CMFPlone#2540) [ale-rt]

  • Revert breaking changes in 1.4.12 and move them to 2.0.0 branch of [esteele]

  • Fix folder layout property migration. The default listing_view layout was always set if a folder didn't have a layout property. Also a default_page property could be inherited from parent folders or the Plone Siteroot, causing 'front-page' default_pages on many folders. Now only a direct layout property is copied and in that case on the local default_page if set is copied again. see issue 444 <> [fredvd]

  • Fixed false implemented Factories and Markers for ILeadImage and IRichText. see issue 457 <> [iham]

  • Fixed Tests for collection and migration. see issue <> [iham]

  • Pinned pydocstyle as it broke buildout. [iham]

  • pep8 cleanup. [iham]

  • Fix various issues in py3 [pbauer] 2.4.10 → 2.5.1

New features:
  • Add plone.schema>=1.1.0 as minimal dependency in [timo]

  • Add JSONField that has been added to plone.schema 1.1.0 to ALLOWED_FIELDS in [timo]

Bug fixes:
  • Remove bbb for MessageFactory import. [jensens]

  • Python 3 fixes. [jensens, pbauer] 3.0.6 → 3.0.8

Bug fixes:
  • Reverted test fix for richtext behavior. The related change was reverted in 1.4.15. [maurits]

  • Fixed tests when IRichText behavior is used. IRichText -> IRichTextBehavior This is a follow up to issue 476 <>_. [iham] 3.1.1 → 3.2.0

New features:
  • Remove Pragma: no-cache header for icalendar exports. The Pragma header is HTTP 1.0 and the caching strategy on icalendar exports should better be defined by integrators. [thet]
Bug fixes:
  • Python 3 compatibility. [pbauer]

  • Make sure to include the 'Content-Length' header for ical exports [frapell]

  • Update resources. Requires plonetheme.barceloneta >= 1.9. [agitator] 1.2.5 → 1.2.6 3.0.4 → 3.0.5

Bug fixes:
  • Fix tests with py3. [pbauer] 3.3.8 → 3.3.9

Bug fixes:
  • Some Python 3 fixes. [pbauer] 2.8.1 → 2.8.2

New features:
  • Add test for Revert to Revision action in History Viewlet [davilima6]
Bug fixes:
  • Show document byline for logged-in users. Fixes #160 [erral]

  • Get rid of obsolete X-UA-Compatible header. [hvelarde] 3.3.6 → 3.3.7

Bug fixes:
  • Fix tests in Python 3 [pbauer] 5.1.9 → 5.1.10

  • Update Traditional Chinese translations. [l34marr]

  • Save Lithuanian plonelocales with utf-8 encoding. Refs #234 [pysailor] 5.2.1 → 5.2.3

New features:
  • Make optional (no longer there in Plone 5.2). [jensens]
Bug fixes:
  • Rerelease, as 5.2.1 was somehow released twice, once in June, once in September. [maurits]

  • Upgrade step to profile version 3 was lost and now recreated. [jensens, 2silver]

  • Do not show deprecation warning when loading migrator code, as it is intended to load old LRF there. [jensens]

  • Don't fail, if multilingual selector is called without query [tomgross]

  • Fix connecting of documents [tomgross] 4.3.3 → 4.3.4

Bug fixes:
  • Portlet add and edit forms already extend AutoExtensibleForm from plone.autoform. But some portlet addforms fail on creating the Assignment, if there is a FormExtender for the form, and the addform uses Assignment(**data) for creation instead of explicit parameters. Fix this by filtering away data values that does not come from the 'core' schema. [sunew] 1.4.8 → 1.4.9

Bug fixes:
  • Fix a case, where objects id starts with roots id [eikichi18] 5.0.8 → 5.0.9

Bug fixes:
  • Amended the doctests to work with automatical layer port picking from plone.testing. [Rotonen] 2.0.4 → 2.0.5

New features:
  • Recompiled resource bundles with latest mockup [sunew] 2.0.15 → 2.0.17 4.0.6 → 4.0.7

Bug fixes:
  • Python 3 support [ale-rt, pbauer] 3.0.5 → 3.0.6

Bug fixes:
  • Prepare for Python 2 / 3 compatibility [pbauer, MatthewWilkes, ale-rt]

plone.autoform: 1.7.5 → 1.8.0

New features:
  • Add support for python 3 [pbauer]

plone.batching: 1.1.3 → 1.1.4

Bug fixes:
  • Fix navlist different in Python2 and Python 3 (Refs. #21) [ale-rt]

  • Python 3 fixes. [thet]

plone.browserlayer: 2.2.1 → 2.2.2

Bug fixes:
  • Fix tests for py3 [pbauer]

plone.cachepurging: 1.0.15 → 1.0.16

Bug fixes:
  • Set default purger backlog size to 0 (infinity) in order to fully invalidate Varnish cache [avoinea refs #11]

  • Tests and Code are Python 3 compatible [pbauer, ale-rt, jensens]

plone.caching: 1.1.2 → 1.2.0

New features:
  • Add support for Python 3. [pbauer]
Bug fixes:
  • Fix caching and tests in python 3 [ale-rt, pbauer]

plone.contentrules: 2.0.7 → 2.0.8

Bug fixes:
  • Fix tests in py3. [pbauer]

plone.dexterity: 2.6.0 → 2.6.1

New features:
  • ZServer is now optional [pbauer]
Bug fixes:
  • Other Python 3 compatibility fixes [ale-rt, pbauer, jensens]

plone.folder: 2.0.0 → 2.0.1

Bug fixes:
  • Stabilize order of unordered items in partial ordering. [davisagli]

  • Fix ordering of content in folder in python 3. [pbauer]

  • Fix tests in py3. [pbauer]

plone.formwidget.namedfile: 2.0.5 → 2.0.6

Bug fixes:
  • Prepare for Python 2 / 3 compatibility [ale-rt, pbauer]

  • On form validation errors after submitting, keep the already uploaded image. [thet]

plone.indexer: 1.0.4 → 1.0.5

Bug fixes:
  • fix "Subobjects are indexing attributes of parent". Allow only direct attributes and acquired PythonScripts, but not acquired attributes. Indexers and PythonScripts are able to handle this explicitly, because they get the acquisition-wrapped object. [jensens]

  • Fix tests to work in Python 3 [pbauer]

plone.locking: 2.2.2 → 2.2.3

Bug fixes:
  • More Python 2 / 3 compatibility fixes. [thet]

plone.memoize: 1.2.2 → 1.2.3

Bug fixes:
  • Re-enable Travis-CI. This package can be used outside Plone so it should be tested outside, too. [howitz]

plone.portlet.static: 3.1.2 → 3.1.3

Bug fixes:
  • Fix static portlet for py3 [pbauer]

plone.resourceeditor: 2.1.1 → 2.1.2

Bug fixes:
  • Fix functionality and tests in py3 [pbauer]

plone.scale: 3.0.1 → 3.0.2

Bug fixes:
  • Fix cleanup of image scales in py3 [pbauer]

plone.schema: 1.0.0 → 1.2.0

New features:
  • Improve and complete Plone integration of the JSONField (z3c.form, plone.supermodel, plone.schemaeditor) [sneridagh]

  • Add new JSONField field and JSONSchema auto validation. [sneridagh]

plone.schemaeditor: 2.0.19 → 2.0.20

Bug fixes:
  • Fix issue where serializing vocabulary terms into '|' syntax failed when values contained non-ascii characters [datakurre]

  • Allow defaults to be set on dexterity type fields via the web UI (@@fields) [ezvirtual]

  • Fix tests in py3 and some py3 issues. [pbauer]

plone.session: 3.7.0 → 3.7.1

Bug fixes:
  • Python3 compatibility [ale-rt, pbauer]

plone.stringinterp: 1.2.1 → 1.3.0

New features:
  • Add support for Python 3. [pbauer]

plone.subrequest: 1.8.5 → 1.8.6

New features:
  • Fix importsi without ZServer [pbauer]
Bug fixes:
  • More Python 3 compatibility. [ale-rt, thet]

  • Make test dependency on Archetypes optional. [davisagli]

plone.supermodel: 1.3.4 → 1.4.0

New features:
  • Python 3 compatibility. [pbauer, davilima6, dhavlik, ale-rt]

plone.testing: 4.3.1 → 4.3.2

Breaking changes:
  • Default to picking a dynamical port for ZServer layers instead of a static default port. [Rotonen]

plonetheme.barceloneta: 1.8.1 → 1.9.1

New features:
  • Integrated styles and further cleanup. [agitator]
Bug fixes:
  • Do not strip the #edit-bar section from the toolbar. Refs: [thet]

  • Fix nested navigation tree and icon visibility [petschki]

Products.CMFDiffTool: 3.2.0 → 3.2.1

Bug fixes:
  • Fix diff and tests in py3 [pbauer, hverlarde, jensens]

Products.CMFEditions: 3.2.1 → 3.2.2

Bug fixes:
  • Fix Unauthorized error due to importing six inside Restricted Python Plone issue 2463 <>_ [davilima6]

Products.CMFPlone: 5.1.3 → 5.1.4rc5

New features:
  • Added utils.human_readable_size. [reinhardt]

  • Update mockup. [thet]

  • Upgrade grunt + plugins to same versions as in mockup [sunew]

  • Include TinyMCE 4.7.13 [erral]

  • Update mockup to latest version. [frapell]

Bug fixes:
  • Fix profile version. [esteele]

  • Reverted test fix for richtext behavior. [maurits]

  • Fix multiple nested #edit-bar section when navigating in folder contents. Fixes: [thet]

  • added CSS hyphenation support for toolbar for avoiding ugly text wrapping Fixes issue 723 <> and issue 2315 [ajung]

  • Remove the devdependencies from bower.json - they are just used for running tests in mockup, not here. [sunew]

  • Let the combine-bundles import step also work when the IBundleRegistry keyword is not in registry.xml, but in a registry directory. Issue 2520 <>_. [maurits]

  • Get rid of obsolete X-UA-Compatible header. [hvelarde]

  • Fix registration of robots.txt browser view to avoid AttributeError on Zope's root (fixes #2052 <>_). [hvelarde]

  • Fixed tests when IRichText behavior is used. IRichText -> IRichTextBehavior This is a follow up to issue 476 <>_. [iham]

  • Fix support for JSON/unspecified requests. [rpatterson]

  • 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 <>_. [maurits]

  • Add test for issue #2469. [jensens]

  • Fix toolbar on mobile:

    • Clicking on menu links, submenus are not shown
    • With a opened submenu, html has huge margins and page content disappears [nzambello]
  • Clicking on menu links, submenus are not shown

  • With a opened submenu, html has huge margins and page content disappears

  • Remove last legacy Javascript highlight-searchterms.js. Removes also the skins folder plone_ecmascript. It was broken for almost all use cases (Google, other search engines, own live search); JS worked only when coming from Plone detailed search page. [jensens]

  • Fix failing thememapper robot test after rebuild of thememapper bundle in p.a.theming PR 147 [sunew]

  • Fix Datatables CSS not available #2512 via PR mockup #863 [sunew, thet]

Products.ExtendedPathIndex: 3.3.0 → 3.3.1

Bug fixes:
  • Fix dependencies defined in [gforcada]

Products.GenericSetup: 1.8.9 → 1.8.10

Bug fixes:
  • Do not mask KeyError in 'getProfileDependencies' from missing dependency profiles. Refs: [ida]

Products.MimetypesRegistry: 2.1.4 → 2.1.5

New features:
  • Python 3 compatibility. [rnix]

Products.PortalTransforms: 3.1.3 → 3.1.4

Bug fixes:
  • fix test for python 3 [petschki]

Products.statusmessages: 5.0.3 → 5.0.4

Bug fixes:
  • Use Umlaut ä in tests in order to check string/bytes handling. Refactor test_encoding to unittest. [jensens]

Products.Archetypes: 1.15.3 → 1.15.4

Bug fixes:
  • Switch to new TestCase using AT after PloneTestcase is now DX. Fall back to the old TestCase in case of an older [pbauer, maurits] 1.4.1 → 1.4.2

Bug fixes:
  • Change import of message factory from dx to non-deprecated way. [jensens]

  • Fix tests in py3 [pbauer] 1.3.3 → 1.3.4

Bug fixes:
  • Migrate tests away from PloneTestCase [pbauer]

  • Fix imports for py3 [pbauer] 4.1.1 → 4.2.0 2.1.0 → 2.1.1 2.3.0 → 2.3.1 3.0.3 → 3.1.0

plone.tiles: 2.0.0 → 2.1.0

Project resources

Learn about Plone

Plone Goes To Pycon

Posted by Jazkarta Blog on September 12, 2018 09:50 PM

Plone booth at Pycon

I’ve just returned from Pycon where I had a great time staffing the Plone Foundation’s booth. It was fun to see old friends and introduce new people to Plone, Python’s open source, enterprise-grade content management system. Pycon attendees are wonderfully friendly and curious, always interested in learning new things. The venue – Cleveland’s downtown convention center – was lovely and the rain mostly held off. We gave away dozens and dozens of Plone-branded neck pillows and water bottles and multi-tools and pins and magnets, not to mention blue M&Ms arranged in the shape of the Plone logo. I arrived with 2 suitcases full of swag and left with 2 empties. Thanks to Witek and Nate from Jazkarta and to Chrissy, Anthony and Carol from Six Feet Up for helping set up and run the booth, and to the Plone Foundation for sponsoring Pycon. Open source rocks!

Announcing collective.siteimprove

Posted by Jazkarta Blog on September 12, 2018 09:47 PM

Screenshot of collective.siteimprove UI, expanded

As I reported back in May, at our last Jazkarta sprint Witek and Alec began work on a Plone add-on, collective.siteimprove, that provides integration with the Siteimprove content quality checking service. I’m pleased to announce that the add-on has now been thoroughly vetted by the folks at Siteimprove and the resulting version is available from Pypi!

What Is Siteimprove

Siteimprove is a respected service for maintaining and improving web content quality. Customers who sign up for the service get automated scans of their websites which check for content quality, accessibility compliance, SEO, data privacy, and performance. Site rollups and per page reports are available via email and from a customizable dashboard at

Siteimprove also provides an API which allows for the development of CMS plugins – integrations of the Siteimprove service within content management systems. This allows content editors to get immediate feedback on pages that they publish. This is great because it lets editors see problems while they are in the process of editing a page, instead of getting a report after the fact and needing to click through links to fix things.

Graphic explaining how Siteimprove works


Why Siteimprove for Plone

Plone, the premier Python-based open source content management system, is an enterprise scale CMS that is widely used by large organizations with large websites. These are just the types of organizations that can benefit from a tool like Siteimprove, which has a reputation for being an excellent service for maintaining and improving website content.

The Jazkarta team was delighted to be able to contribute to the Plone community by creating an add-on that integrates Siteimprove’s CMS plugin features into the Plone editing process. Now anyone with a Plone website can easily integrate with Siteimprove simply by installing an add-on – all the integration work has been done.


After collective.siteimprove is installed on a Plone site, there will be a new control panel where Siteimprove customers can request and save a token that registers the domain with After that, authorized users will see an overlaid Siteimprove button on each page that shows the number of issues found.

Screenshot of the collective.siteimprove UI, collapsed


When clicked, the overlay expands to show a summary report of page errors and an overall score, as shown in the image at the top of this post. After an edit, users can click a button on the overlay to request that Siteimprove recheck the page. They can also follow a link to the full page report at

Plone+Siteimprove FTW

Now anyone who has a Plone website can easily integrate with the Siteimprove service and take advantage of all of Siteimprove’s enterprise-scale features while they are working on their content!

Auch bei Vodafone sind nur Sicherheitsdilletanten am Werk

Posted by Andreas Jung/ZOPYX on August 24, 2018 03:35 PM
Offenbar hat auch bei großen Konzernen niemand Ahnung von Security oder man ist ignorant. Wieviele Datenlecks, wieviele Hacks müssen noch passieren bis man wach und sensitiv wird?

Pastanaga Editor Status Report - Plone Beethoven Sprint 2018

Posted by kitconcept GmbH on July 20, 2018 11:24 AM

During the Plone Beethoven Sprint in Bonn, we worked hard on creating a first version of a new content editor for Plone-React.

Here is a short demo of what the editor looks like right now:

Demo of the Pastanaga Editor with tiles

We already had a first implementation based on DraftJS that allows inline styles (e.g. bold, italic), block styles (headlines, (un)ordered lists), and links to remote URLs.

The new version of the editor is based on a “tiles” backend, that is build by Victor Fernandez de Alba during the sprint and released with plone.restapi 3.2.0.

This allows us adding more complex content elements such as images, videos, and in the future more complex layout elements.

With the new backend in place, Rob Gietema went ahead and implemented the basic editor that Albert Casado designed as part of the new Pastanaga UI for Plone.

pastanaga editor Mobile Pastanaga Editor design by Albert Casado

The user can type in the title, description and the text content of the document without worrying about form fields or be distracted by tabs and fieldsets.

In addition to the standard text editing it is now possible to add an image tile that can be placed on the left or right side, on the center of the page or in full page width.

Rob also added a YouTube tile that allows the editor to add a YouTube video URL and then displays the video within the editor and the page view.

Text, image, and video tiles can be added to a page. They can be deleted and moved up and down to change the order of the elements.

Next Steps

The new editor is a great accomplishment. The tiles endpoint in plone.restapi allows us to further enhance the current version of the editor with more advanced layout variants and tiles.

We plan to continue with our iterative and agile approach of building a useful, fully functional version of the editor with each step, that allows Plone companies to use the editor and Plone-React today in their client projects.

The next steps are polishing the editor and the existing tiles. Work out some UX issues that we found when working with the editor and building more advanced tiles.

Stay tuned for more news and features after the Costa Brava sprint…

Plone Beethoven Sprint 2018 - Sprint Report - Day 3

Posted by kitconcept GmbH on June 30, 2018 06:24 PM
Report of the third day of the Plone Beethoven Sprint 2018 in Bonn, Germany.

The Beethoven Sprint was a “strategic” sprint that took place June 21-25 at the kitconcept office in Bonn, Germany. The focus of the sprint was to work on the Pastanaga editor, Plone-React, plone.restapi, and Guillotina. This is the report of the third day of the sprint.

day3 wrap up all Day three wrap-up meeting at the kitconcept office

UTC DateTime Discussion

After having breakfast and doing a quick stand-up, we started a discussion about how to store datetimes in Plone. This was a discussion that came up when we implemented plone.restapi. Though, this question is more related to As seen many times in the Plone community, when it comes to complex technical matters, offline discussions work way better than discussing issues back and forth via github comments.

Since we had all the experts at the sprint, we decided to schedule a discussion to solve the issue. In the end we reached an agreement that dates should be stored as UTC and that the local time zone should be stored separately in an additional field, for instance to calculate recurring dates.


Thomas Buchberger worked on the workflow endpoint and added a feature to change the workflow state recursively, to set the effective and expiration date and to allow workflow comment.

Lukas Graf finished his work on implementing redirects in based on The redirects do not only work for simple GET requests but also redirects POST, PATCH, und DELETE requests.

Sune Brøndum Wøller finished the portlets endpoint for plone.restapi.

Mikel Larreategi made plone.restapi return cachable image resources to improve the caching of images in plone.restapi.

Roel finally wrote a PLIP for the IPloneSiteRoot and fixed edge cases and a few bugs in the current implementation.


Victor completed his work on plone.schema, allowing to use a JSON field in Plone that validates the JSON structure within the field and also allows through-the-web editing. He also finished the backend behavior for tiles and blocks to store the tiles and the tiles layout on a Plone content object.

Eric Steele added a backend implementation for the add-ons control panel that he wrote for Plone-React. Eric presented a fully working add-ons control panel that allows to install add-ons via Plone-React by the end of the day.

day3 wrap up eric add ons control panel Plone-React add-ons control panel presented by Eric Steele

David completed his work on the vocabularies endpoint by implementing the frontend widgets that rely on those vocabularies to make sure the endpoint serves its purpose.

Davi Lima and Victor continued to work on the override mechanism for Plone-React (JBOT) to customize widgets and views in a config.js file using a babel plugin.

Pastanaga Editor

day3 wrap up rob editor video Rob presenting the new video tile for the Pastanaga editor

As always, Rob did not give us any time to breath and added a YouTube video tile to the Pastanaga Editor, that shows a YouTube video in the editor itself and on the content view.

Of course that wasn’t enough for a day, so he fixed a few other smaller issues and worked on exposing the sitemap.xml via Plone-React.

Dinner and some late night hacking

Dinner Hans im Glueck Dinner at “Hans im Glück”

Rob might not admit it, but after claiming he could fix all those issues mentioned above in one day, he continued to work on the sitemap during our dinner at a local burger restaurant in the inner part of the city. We’ve been there ourselves, so we didn’t mind, while we were enjoying our tasteful cocktails. After a good meal, some drinks, and having to say good by to Eric, we went back to the office.

We said good bye again to our fantastic Dutch Plone-React team Rob and Roel and then went on to hack a little bit more on the stuff we were (and still are) so enthousiastic about.

Plone Beethoven Sprint 2018 - Sprint Report - Day 2

Posted by kitconcept GmbH on June 29, 2018 06:24 PM
Report of the second day of the Plone Beethoven Sprint 2018 in Bonn, Germany.

The Beethoven Sprint was a “strategic” sprint that took place June 21-25 at the kitconcept office in Bonn, Germany. The focus of the sprint was to work on the Pastanaga editor, Plone-React, plone.restapi, and Guillotina. This is the report of the second day of the sprint.


After having breakfast at the office, we started the day with a stand-up/wrap-up meeting with Ramon Navarro Bosch presenting Plone-React running on Guillotina. The user can add new content, edit existing content, and browse the content with Plone-React and Guillotina, which is a huge acomplishment and a promise for the future of Plone. After the stand-up Ramon had to say good bye to the other sprinters and head home to Barcelona.

Pastanaga Editor

Rob Gietema continued his work on the Pastanaga editor. At the end of the day, he was able to present a working version where the user can add a title and a description tile as well as a text tile with inline styles such as bold, italic, headlines, links, and lists.

IMG 6754 6b052ccf7a9ed291599dc6a7047a71cc Pastanaga Editor with basic text editing

Rob also added an image tile that allows you to upload images. The uploaded images then can be aligned left, right, in the middle and in full width or just be deleted.

IMG 6756 abcbc897d406fc882d25dca889402298 Image tile that can be aligned left, right, center and displayed with full width.

Victor Fernandez de Alba finished his work on the tiles backend for the Pastanaga editor (, so Rob could present a fully functional editor that actually stores the content (text and images) in Plone tiles.


Eric Steele continued his work on the add-on control panel and was able to present a first version at the wrap-up at the end of the day.

IMG 6758 144f319424d81d358e6410f2aea3d41f Add-ons control panel written in React by Eric Steele

Carsten Senger worked on implementing the users and groups control panel in Plone-React which now allows to add and delete users.

Victor worked on being able to use Plone-React as a library that allows developers to override React components. The system is supposed to work the same way as JBOT (just-a-bunch-of-templates) works in Plone.

Johannes Raggam and Andrea Cecchi continued their work on the reference widget and were able to present a first prototype. We agreed that we have to put some effort into the UX/UI of that widget, but that was beyond the scope of a sprint and requires the help of a UX specialist.


Thomas Buchberger finished the pull request for the object create order and started to to work on the workflow endpoint enhancements.

David Glick worked on enhancing the vocabularies endpoint with batching and filtering.

Sune Brøndum Wøller fixed some nasty bugs with time freezing and transactions errors in the Plone 5.2 of plone.restapi (e.g.,

Lukas Graf continued his work on the translations of the REST response data, fixed a few bugs and wrote a script that tests the Sphinx-based documentation for warnings and errors and fails the Travis build if there is a problem.

Mikel Larreategi finished the pull request for the history endpoint and documented the Accept-Language headers in plone.restapi. He also started working on making the image scales that plone.restapi returns cachable.

Roel Bruggink continued his quest on the folderish site root and fixed errors in CMFPlone,, and in

We were able to release 1.1.1 and plone.restapi 2.1.0 as well as plone.schema 1.2.0 with a JSON field that is required for the tiles endpoint in plone.restapi.

Hacking Night

Germany was playing at the soccer world cup in the evening, so we decided to order Pizza for dinner and then split up between people that wanted to code and people that wanted to watch the game. As you might have guessed the latter group was rather small. We ended up in a bar because the public viewing was already full. Though I guess the sprinters got a taste of the German soccer culture. After the game we went back to the office to join forces with the others again to wrap up the day and hack the night away.

Plone Beethoven Sprint 2018 - Sprint Report - Day 1

Posted by kitconcept GmbH on June 28, 2018 06:24 PM
Report of the first day of the Plone Beethoven Sprint 2018 in Bonn, Germany

The Beethoven Sprint was a “strategic” sprint that took place June 21-25 at the kitconcept office in Bonn, Germany. The focus of the sprint was to work on the Pastanaga editor, Plone-React, plone.restapi, and Guillotina. This is the report of the first day of the sprint.


day1 standup Stand-up of the first day

We started the day with a stand-up meeting giving people a heads up on the current state of affairs of plone.restapi, plone-react, and Guillotina.

I started with plone.restapi, which is considered stable and battle tested in production.

Victor Fernandez de Alba then gave a brief introduction to our first Plone-React based project VHS-Ehrenamtsportal, that we successfully shipped to our client a few weeks ago and run without any issues since then.

IMG 4031 565f311943de0d1be7694a4b1c0e79a8 Victor introducing VHS Ehrenamtsportal

After this, Rob Gietema gave a short introduction to the current state of Plone-React.

Last but not least, Ramon Navarro Bosch presented “Guillotina”, an async server written in Python with a Cockroach DB / ElasticSearch backend that adopts some of the core concepts of Zope and Plone.

With a group of 15 sprinters, we decided to split up in four different groups for the main sprint topic. Thomas Buchberger led the plone.restapi group, Rob the Plone-React group, Victor the Pastanaga Editor group, and Ramon the Guillotina group.

Pastanaga Editor

22 06 18 4 Rob Gietema going though the different approaches we discussed during the Tiles planning meeting

Right after the stand-up, we had a longer discussion about the “tiles” endpoint in plone.restapi and the editor implementation in Plone-React. We already reached an agreement of the API design at the Plone-React sprint a few months ago. Though, it turned out that implementing that on top of the existing plone.tiles implementation was harder than we thought and we did not anticipated all the problems that came along with that.

We decided to keep the API design and to write a simple Dexterity behavior that adds a “tiles_layout” field for the layout information and a “tiles” field that holds the actual data of the tiles. Ramon already wrote a JSON-field in the Guillotina code that we decided to re-use for our implementation.

Rob Gietema already wrote a first prototype of the new editor at the Plone-React sprint and he was waiting for the backend code to be implemented. While we were working on the backend implementation, he focused on the prototype.


22 06 18 24 Planning board with plone.restapi issues

Lukas Graf added missing translations in plone.restapi responses and simplified the test setup and did some clean up on the code (

Thomas Buchberger worked on fixing the plone.restapi object creation logic to behave more like through-the-web object creation ( and separated the object creation from firing the events.

Sune Brøndum Wøller cleaned up and upgraded multiple Plone versions in plone.restapi (, worked on portlets and portletmanager serialization and fixed a ReadConflictError in the plone.restapi tests for the documentation that was bugging us for quite some time (

David Glick and me worked on Zope 4 compatibility for and plone.restapi. It turned out that one of my fixes on was already sufficient and that the test failures in plone.restapi were caused by a plone.testing issue that David found and fixed (

Roel Bruggink continued his efforts on turning the Plone site root into a Dexterity object. He worked on making the IPloneSiteRoot interface / content object behave more like content and he attached behaviours to the IPloneSiteRoot to edit them without relying on a default page.

Mikel Larreategi finished his work on the translation of the content-type names on the @types endpoint ( and the translation of the actions and workflow state and transitions on the @history endpoint (


Rob gave an introduction to the Plone-React codebase and explained the basic concepts and libraries that we use in Plone-React.

Eric Steele started to work on creating the add-ons control panel in React. Carsten Senger took over the work that Rob started before the sprint to bring the users and groups control panel to Plone-React.

Andrea Cecchi. and Johannes Raggam worked on the React-based widget for references in Plone.


After giving an introduction to Guillotina to the sprinters, Ramon went ahead and made Plone-React work on top of Guillotina. Since it origins, plone.restapi and Guillotina were supposed to share the same API to allow us to switch the backend for our new frontend at some point in the future. Ramon was also heavily involved in the API design of plone.restapi and wrote the first version of before he decided to invent Guillotina. Over the time both APIs differed because of differences in the underlying implementation.

Ramon and Rob worked on this and by the end of the day they could present a working version that allows basic content editing and browsing.

Roadmap / Plone 6

We had a hangout with Philip Bauer from Munich who is leading the efforts to migrate Plone to Python 3 and Zope 4.

Hangout with Philip Bauer

Philip and I already had a longer discussion about a possible roadmap for Plone 6 and how to bring our efforts on the frontend together with the efforts of the group that works on Python 3 and Zope 4. We discussed the outlined roadmap and the upcoming sprints where we plan the implementation of the roadmap.

Lunch / Dinner / Evening

We went to have lunch in a Vegan cafe (Black Veg) and to a traditional brewery in the old part of the town for dinner (Bierhaus Machold). After dinner and a few drinks, we decided to head back to the office for some late night hacking. Not without stopping by at a local “Kiosk” for some customary buying of beverages for the evening.

World Plone Day 2014: manufacturing internationalization strategy

Posted by CodeSyntax on June 22, 2018 08:47 AM
World Plone Day was last wednesday, april the 30th, and as in previous occasions, we did celebrate it at CodeSyntax's offices, with some customers and Plone users of the Basque Country.

Presenting Buildout at PySS 14

Posted by CodeSyntax on May 29, 2018 01:10 PM
Buildout is a tool we use in all of the development and deployments of our applications, and we have given a talk about it at PySS 14.

Porting Plone to Python 3

Posted by on May 23, 2018 07:26 PM

Since I wrote the proposal to Port Plone to Python 3, so much has happened that a status update is needed.

Let's step back a little: The first steps towards Python 3 were taken during the sprint at the Plone conference in Barcelona. The epic PLIP to update to Zope 4 was merged and we started porting individual packages to Python 3 without being able to run any tests. With the help of sixer and python-modernize we tried to get the most obvious import and syntax issues out of the way. That work was continued at the Alpine City Sprint in Innsbruck and in the end, we treated more than 150 packages like this. Some of this work is documented in the Plone tracker.

Along the way I wrote a best-practice guide on how to port Plone packages this way.

As the PLIP states, there are several approaches to porting Plone to Python 3:

  1. Migrate and test packages that have no dependency to CMFPlone and test them in Python 2 and 3.
  2. Prepare packages for Python 3 without being able to test them in Python 3.
  3. Start up Plone on Python 3 and fix whatever breaks. When start-up works, create a Plone Site and again, fix whatever breaks.
  4. Port plone.testing and to Python 3 and start running tests. Fix what breaks during the setup of the layers.
  5. Run the tests with Python 3 and fix all broken tests.

At the sprint in Innbruck I started with #3 and kept going after the sprint until I was able to create an instance. At the Plone Tagung in Berlin I was able to demo the creation of a site but nothing was rendered yet.

After that, I kept going and I was finally able to create a site and manage content, which is what a CMS is about. It looked a bit raw but I was able to add and edit some content - yay!

early screenshot of plone with python 3

Work continued at an unsteady pace, and with important contributions from Michael Howitz, Alessandro Pisa and David Glick, things started to get better. Even the theme and js started working. Slowly broken features became the exception, not the rule.

Last week at the Zope 4 Welcome Sprint in Halle we removed all feature blockers that we had found so far. Plone with Python 3 looks and feels like it used to in Python 2. During the sprint there was also a lot of progress on:

  • the wsgi setup
  • logging and tracebacks when using wsgi
  • porting plone.testing
  • a new theme for the ZMI
  • beta releases for many packages.

There was also some progress on the difficult issue of database migrations. It seems like zodbupdate is the best tool to do that but there is probably a lot of work ahead.

Read more about the sprints outcome in the blogpost by Michael Howitz.

There is a Jenkins job and as of today, it is running (not passing) tests for all packages (except Archetypes) with Python 3.

At the moment we run 6594 tests from 115 packages with 257 failures and 315 errors - not bad when you keep in mind that we still focus on features, not on tests. Tests for a couple of packages are green, including plone.api which is great since plone.api uses most of our stack one way or another. Jenkins runs every three hours and here you can see the progress over time.

Here is a screenshot from today that shows Plone doing some pretty non-trivial things: Editing a recurring Event and also Richtext with Images and Links:

screenshot today

Next steps:

  • Create a demo site running on Python 3 that people can use to find broken features. This will happen at the Plonator Sprint in Munich.
  • Fix all tests that look like they fail because of a broken feature.
  • Fix all remaining tests to pass in Python 2 and Python 3. Since there are a gazillion doctests that will take some time.
  • Port to python 3 and fix robottests.
  • Experiment with porting a ZODB with Plone to Python 3.

If you want to participate you can simply look at the failing tests and start fixing them. You can also try to fix one of the open issues.
The setup of a coredev environment with Python 3 is really simple and documented.

Rural Sprinting: Two New Plone Add-ons and Progress on Python 3

Posted by Jazkarta Blog on May 17, 2018 06:56 PM

Jazkarta Team

We returned to my house in rural Massachusetts for our annual sprint this year and had a great time sampling local beers and ciders,

Buying supplies for the sprint

eating big meals together,

Making pizzas at the sprint

admiring the Milky Way,

Nightime view at Sally's house

and working on some fun projects. Normally we work remotely – everyone in their own home office, spread across 3 countries and 2 continents. But it’s really nice to get together in person, and we try to do it once a year.

Here’s what we worked on.

Witek and Alec created 2 new Plone add-ons and released them to Pypi.

  • jazkarta.abtesttile Provides a new Mosaic tile type that can be used for A/B testing parts of a page layout. Managers can define 2 rich text fields on one tile, and a ratio for how often each should be displayed (for example, 70%/30% or 50%/50%). Plone will randomly show users one field or the other in that ratio. Managers can optionally specify Javascript snippets for use in analytics tracking. Managers can also optionally enable a query string variable, which is added in the rendered HTML to links in the rich text fields. This will indicate whether option A’s or B’s rich text was the source of a page visit. A custom permission allows usage of the add-on to be restricted to privileged users.
  • collective.siteimprove Provides integration with There is a control panel for requesting and saving a token that registers the domain with Siteimprove. (You must first sign up for a Siteimprove account.) A Siteimprove button is shown to authorized users on all default views. Publicly visible content shows authorized users a Siteimprove recheck action in the Plone toolbar that checks the individual page. This add-on is essentially done but untested since we have not yet met with the Siteimprove sales person who will provide an account for us to test with. We hope to be able to do that next week.

David, Matthew and Jesse decided to contribute to the ongoing effort to port Plone – Python’s open source enterprise CMS – to Python 3. They were in the porting groove because we recently ported our Dallinger project to Python 3. They made some good progress:

  • David made it possible to run Plone tests without including Archetypes, so that developers can run the tests in Python 3 without worrying about porting Plone’s old content type system. After that he investigated why cookies on Python 3 are preventing logins from staying logged in. He traced it to PAS and create a branch with all tests passing on both Python 2 and 3. Hopefully it will get merged during the Halle sprint this week.
  • Matthew found and fixed some Chameleon problems. This included an old error that had nothing to do with Python 3 where Chameleon puts spurious context into error messages. He also converted plone.namedfile to Python 3 and fixed some tests in plone.protect (CSRF protection). His work resulted in a fairly large pull request, which was approved and merged.
  • Jesse got all tests running for and made a bit of progress on the test failures for

Thanks to all these fixes, we got to the point of being able to save a Plone page on Python 3 and it “sort of” works. (At least it didn’t give an error!)

David also did some evaluation of plone-react with Nate. This is a React-based front-end for Plone that is built on plone.restapi. It’s in early stages of development but looks promising. In the process, Nate ran into a bug in Plone’s unified installer, tested it in Plone 5.1.2 and and filed a ticket for it. Back to his Plone roots!

Plone-React Sprint Bonn 2018

Posted by kitconcept GmbH on April 23, 2018 04:46 PM

From March 12th to 15th, we hosted a Plone-React sprint at our office in Bonn. The main goal of this three day sprint was to contribute back the work we did for a recent client project. We also planned to upgrade Plone-React to React 16 and improving the error handling.

A small and very focused sprint with the core contributors of Plone-React was the perfect opportunity to do so. Participants were Rob Gietema, Roel Bruggink, Asko Soukka, Victor Fernandez de Alba, Carsten Senger and me.

Sprint Day 1

We started the first day of the sprint by doing a quick stand up and planning meeting. We used the days before the sprint to outline our main goals and objectives, so we could get started right away.

IMG 2572 725ac0c3d0acdf94e31efebb6c23f318 Planning board after the stand up

React 16

On the first day Rob and Victor worked on upgrading plone-react to use React 16 and Webpack 4.

We postponed the upgrade to React router version 4, because some of the dependencies that we need, are still in alpha phase and staying with the old version does not hurt right now.

IMG 2576 4ffa46024dfcc49456d639f9059e5581 Card to upgrade to React 16

Error Boundaries

The main reason why we were eager to upgrade to React 16, was a new feature called “error boundaries”, which allows catching errors in React components and handle them gracefully, without failing the entire app.

Victor implemented error boundaries for client and server side components and for the Redux middleware. It is also possible to pass those errors to Sentry for aggregation and further error handling.

Since we are about to launch our first Plone-React-based project in the next weeks, this was something that was especially important for us.

IMG 2580 d0283e182b2c866ad960a1d3c3a44de3 Error message in plone-react

Token Expiration Middleware

Rob added a token expiration middleware to plone-react that improves the handling of JWT auth token in Plone-React. Working with plone-react on a daily basis revealed a few edge cases where the current authentication failed. The new middleware solves those issues.


Roel and Carsten focused on plone.restapi. Even though this was not planned to be a major topic for the sprint, we had to fix some issues that were causing troubles in the Plone-React frontend.

Carsten worked on fixing an issue that was preventing to allow the API consumer to reset field values to “None”.

Roel started to work on exposing widgets with tagged values via plone.restapi. This is necessary to support autocomplete or reference widgets in Plone-React.

Test Setup

Asko, who joined the sprint remotely, worked on a brand new end-to-end testing setup with Robot Framework. Because this would be way to easy for a super-smart guy like Asko, he decided to wrap the components into a Docker containers, to make it easier for non-Python devs to set it up. Making Plone PIP-installable is also something that we want to have for quite a while. Asko decided to also mix that in. To make this fun, he decided to add support for Jupyter notebook, which makes it super easy to write Robot Framework tests.

IMG 2579 7764cc8777f896ebb057573f308488c1 Hangout with Asko

I started the day discussing the acceptance testing setup with Asko, quietly listening to Rob and Victor and discussing the plone.restapi issues with Roel and Carsten.

Pastanaga Toolbar

During the first day, we started a discussion how plone.restapi could support a toolbar that automatically adapts to the permissions of the logged in users and shows only the actions that this particular user has permission for.

Before the sprint Victor worked on implementing the new super fancy adaptable Pastanaga toolbar, and we were eager to build a proper backend implementation for this.

Victor's tweet with a short demo of the new Pastanaga toolbar

Sprint Day 2


On the second day of the sprint, Rob and Victor started to look into building a “create-react-app”-like functionality for Plone-React. create-react-app is a widely popular code skeleton generator by the React team at Facebook. It hides lots of complexity from the user (e.g. Webpack, libraries, configuration) and makes it easy to get started with React. This is super important for the adoption of Plone-React because it also allows to use Plone-React as a library and basis for custom client projects.

Rob and Victor created a proof-of-concept that kind of works but it became clear that this requires a lot more effort before this becomes ready-to-use.

Pastanaga Editor

We scheduled a time slot for a discussion and planning session about the new “Pastanaga editor” user experience. We already implemented basic text editing based on the DraftJS editor from Facebook. The current editor allows basic text editing as well as inline (italic, bold, etc.) and block styles (e.g. headlines, bullet points) and external links.

The next step on our agenda to make this editor based on Tiles to make it extendable and allow the user to add images, videos and other media objects.

We agreed on moving forward with an agile approach of building something useful step-by-step, making sure to build a fully functional and useful editor at any point of the development stage, rather than building the full Mosaic-like functionality at once.

Right after this was settled, we started to draft a tiles endpoint that would build the basis for the next iteration of the Pastanaga editor.


Rob started to work on implementing the context-aware toolbar. This was a challenge because the toolbar needs to adapt to the content that is shown in the main column. This means a component deep down the component hierarchy (content) needs to be able to update a component that lives outside of the DOM hierarchy of the parent component. Luckily for us, “Portals” in React support exactly that use case.

Victor worked on the flexbox styling of the toolbar as well as on optimizations of the Webpack configuration.

plone.restapi, Tiles, and Testing

Roel and Carsten continued to work on plone.restapi issues. Roel continued to work on the tagged values representations and Carsten finished the actions endpoint for the context-aware toolbar.

I followed our established documentation-first approach on plone.restapi and wrote the docs for the new tiles endpoint.

With the basic test setup already in place, Asko struggled with the Travis CI setup running different versions of Node and Python at the same time. Problem is that the ZEO version requires the latest Python 2.7.13 which is not shipped by default with Travis CI.

He also worked on a Docker compose option to support an option to run the API server. This would allow faster development of Robot Framework tests since the API server does not need to restart for each test (iteration).

Sprint Day Three

We started the last day of our sprint discussing the create-react-app use case we worked on the day before. Afterwards, we did a hangout with a student who is interested in working on this during the Google Summer of Code 2018.

IMG 2583 f900eaa919019cf508c8a20e6313de48 Hangout with a possible Google Summer of Code student

Right after this call, Asko gave me a tour of the new, Docker compose based, PIP-installable, Jupyter notebook enhanced test setup.

My head was still spinning from Asko’s amazing work, when Rob asked me for a minute to show me a prototype of the new Medium-like Pastanaga editor.


The sprint was extremely productive and fun. Having a small and dedicated group of developers with a clear goal and focus really worked well for us.

IMG 6425 1 Group photo in front of the kitconcept office

We contributed back all our re-usable code from our client project, upgraded Plone-React to React 16. We fixed some important issues in plone.restapi and build a super fancy test setup that will allow us to further improve the software quality of Plone-React.

We also laid the groundwork for the next important steps forward: Building the new Pastanaga editor with a tiles-based backend and allowing to use Plone-React as an extensible library with a “create-react-app”-like functionality.

We are already looking forward to the upcoming Beethoven Sprint and the Costa Brava sprint where we will continue to push Plone-React, Pastanaga and plone.restapi.

The Mountaineers Keep Climbing

Posted by Jazkarta Blog on February 22, 2018 04:40 PM

The Mountaineers' Website's New Look

Some non-profits fund raise for major technology upgrades, then breathe a sigh of relief and ignore technology until things start breaking. Rinse and repeat. Other non-profits avoid this feast-or-famine approach to technology spending by budgeting for continuous improvements. The Mountaineers is in the latter camp. In 2014 they completed a major technology upgrade and launched a new Plone+Salesforce website. Every year since, they have budgeted for significant improvements to their website and its back end. They did this through modest support contracts with their technology partners (Jazkarta and Percolator Consulting), plus focused spikes of work that were done through a series of agile iterations. Over the last 3 years we have released enhanced versions of the website 10 times, with an overwhelming number of improvements – you can read all about that on their technology blog. These changes have allowed members, staff, volunteers, instructors, and the organization to get better and better at what they do.

The latest update is the biggest one yet. It has brought and together into one, integrated website. The new and improved header and main navigation helps users know where they are and get to where they’re going. It looks great! We’re really proud to have helped bring it into the world.


Pastanaga icon system

Posted by kitconcept GmbH on January 25, 2018 07:24 PM

The way we deal with icons in the web has evolved over the years. Images, images sprites, fonts, SVG, SVG sprites… I’ve been looking lately for the current best practice in order to include it in Pastanaga and I wanted to share with you my results. Please note that it’s not closed and I’m open to suggestions. PRs are welcome too!

Abandon font-based systems

It was clear to me that font-based icon systems are a no longer an option today. For several reasons:

  • The font is loaded every single time on the page, regardless if we use all the icons or none of them. This bloats the application size and forces an additional request (in the best case scenario).
  • An existing font is difficult to create, maintain and update. You can use some online (free) services to do that and even you can forge your custom icon font with them but it’s cumbersome and not practical.
  • Forces you to maintain a parallel CSS that maps the icon name with its actual character in the font (which is obscure). The font creation tool helps you with that, but…
  • Extending them with new icons is also complex, especially for newbies, and you need access to the source and reload the source in the same tool that was created.

only to name a few.

Time to move on: inlining SVG

The rise of SVG in modern web developing is for a good reason:

  • SVG is a vector format, so it looks great in HiDPI displays
  • It’s lightweight and portable, since it’s not a binary file
  • It can be styled (and animated) easily using CSS (provided they are inlined, not used with the <img /> tag
  • You can control it via JS

My initial feeling was that using a SVG sprite based system would be the best approach, but I soon was discouraged, after reading to Chris Coyier, CSSTricks: A Pretty Good SVG Icon System

All in to inlining SVGs, then.

So, we need an SVG icon system. Luckily for us, Pastanaga already has a complete set of icons based on SVG organized in one file per icon.


Our main goal is to provide inline SVGs in our applications, having in mind:

  • It should be performant and small in size
  • Only the used icons should be loaded in the given view, compatible with lazy loading
  • Has to be a no-brainer and clutter-less from the developer point of view
  • You should be able to extend (or override) the default icon set with your own icons easily
  • Valid for all modern frameworks, with focus on Angular and React

Harnessing the power of Webpack and modern JS

As developers we want to use the tooling that we have at our hands in the best possible way. So our icon system should use simple ES6/7/* and TypeScript conventions.

import myIcon from './icons/my-nice-icon.svg';
import Icon from './components/Icon';

and the from JSX:

<Icon name={myIcon} />

or angular template:

<Icon [name]="myIcon"></icon>


<div icon [name]="myIcon"></div>

Deconstructing the SVG and put it back together again

According to all the use cases shown in this interesting article by Amelia Bellamy-Royds in CSSTricks: How to Scale SVG the most sensible approach when inlining SVGs is to simply just set the viewBox on your <svg> tag, and set one of height or width to auto. The browser will adjust it so that the overall aspect ratio matches the viewBox. As Amelia points out, that would work for all modern browsers back until 2014. If we have to support older ones, we will need to apply for those the famous padding-bottom hack. Let’s keep things simple for now.

Let’s assume that our SVG is not perfect, and we want to have the all the flexibility that a modern browser can achieve handling SVGs. We will take the existing SVG, deconstruct it and get all the SVG attributes, then the content. We will then put it all together in our components, exactly the way we want it.

The Webpack part

We can accomplish all our goals by using a Webpack loaders combo for loading SVG:

    test: /\.svg$/,
    include: path.join(paths.appSrc, 'icons'),
    use: [
        loader: 'svg-loader',
        loader: 'svgo-loader',
        options: {
            plugins: [
            { removeTitle: true },
            { convertPathData: false },
            { removeUselessStrokeAndFill: true },
            { removeViewBox: false },

We will use svg-loader a super simple inline svg loader that provides you extra flexibility when handling your SVG. Initially I tried the popular Webpack Team’s svg-inline-loader but it was not that flexible at the end. svg-loader returns an object with the contents and the attributes of the svg separatedly that we can later manipulate in our components. We are also filtering the SVG using the well known SVGO utility svgo-loader, we can extend or add more filtering options to optimize our SVGs thanks to it.

We are also restricting this loader to the icons folder, just in case we are handling the other SVGs in our app differently, but of course, you can use it for all SVGs removing the include key.


Make it work in React is very straight forward. We need to add the loader to our Webpack config, then add an icons folder and the Icon component.

import React from 'react';
import PropTypes from 'prop-types';

const defaultSize = '100%';

const Icon = ({ name, size, color }) => (
    style={{ height: size, width: 'auto', fill: color }}
    dangerouslySetInnerHTML={{ __html: name.content }}

Icon.propTypes = {
  name: PropTypes.shape({
    xmlns: PropTypes.string,
    viewBox: PropTypes.string,
    content: PropTypes.string,
  size: PropTypes.string,
  color: PropTypes.string,

Icon.defaultProps = {
  size: defaultSize,
  color: null,

export default Icon;

That’s it. Our React component takes as props: the name of the imported module of the SVG, the size, and the color. If not given, the SVG will inherit the fill color set in the parent element (or itself). Also, if not specified, the SVG will scale to the parent container height.

Take a look into the JSX of the example

<div style={{ height: '100px' }}>
    <Icon name={Add} />
<Icon name={Add} size="45px" />
<Icon name={Add} size="45px" color="red" />
<Icon name={Plone} size="60px" color="#1782BE" />
<Icon name={Guillotina} size="60px" color="#EC5528" />


For the angular icon component we needed the same recipe for the Webpack config and this icon component.

import {
    ChangeDetectionStrategy } from '@angular/core';

import { DomSanitizer, SafeHtml } from '@angular/platform-browser';
import { OnInit } from '@angular/core';

const defaultSize = '100%';

  // tslint:disable-next-line:component-selector
  selector: '[icon], icon',
  template: `
  encapsulation: ViewEncapsulation.None,
  changeDetection: ChangeDetectionStrategy.OnPush
export class IconComponent implements OnInit {

  constructor(private sanitizer: DomSanitizer) {}

  svgContent: SafeHtml;
  defaultSize = defaultSize;
  height: string;

  @Input() color: string;
  @Input() size: string;
  @Input() name;

  ngOnInit() {
    this.svgContent = this.sanitizer.bypassSecurityTrustHtml(;
    this.height = this.size ? this.size : defaultSize;


We also use the same approach using the component, the Angular template way:

<div icon [name]="Add"></div>
<div icon [name]="Add" color="green"></div>
<icon [name]="Add" color="red" size="45px"></icon>
<icon [name]="Plone" color="#1782BE" size="60px"></icon>
<icon [name]="Guillotina" color="#EC5528" size="60px"></icon>

Our Angular component takes the same three properties as the React one.

In addition, Typescript forces us to overcome some tiny things.


In order to be able to import the SVG as a module, we need to add this typing to our app:

declare module "*.svg" {
  const content: any;
  export default content;

Add the imported SVG object as a Class member

The Angular template won’t be able to use it if the imported SVG object is not a Class member, like:

import { Component } from '@angular/core';
import Add from '../icons/add.svg';
import Plone from '../icons/plone.svg';
import Guillotina from '../icons/guillotina.svg';

  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
export class AppComponent {
  Add = Add;
  Plone = Plone;
  Guillotina = Guillotina;


While there are other approaches out there like the Icon component that @angular/material has, they all feel to me like too much and all of them are bloated with lots of options that we don’t really need. I’d like to use a more lightweight and approachable solution like the exposed here that only does what we really need. At the end, it’s not rocket science.

If you have any suggestion, please contact me or open an issue on Github. PRs are welcome!

collective.recipe.backup version 4

Posted by Maurits van Rees on January 25, 2018 12:48 PM

Since the end of 2017, there is a new version 4.0 of collective.recipe.backup. There are lots of changes since version 3.1. Let's see some of the highlights.

Safety and exactness of restore

  • When restoring, first run checks for all filestorages and blobstorages. When one of the backups is missing, we quit with an error. This avoids restoring a filestorage and then getting into trouble due to a missing blobstorage backup.
  • When restoring to a specific date, find the first blob backup at or before the specified date. Otherwise fail. The repozo script does the same. We used to pick the first blob backup after the specified date, because we assumed that the user would specify the exact date that is in the filestorage backup. Note that the timestamp of the filestorage and blobstorage backups may be a few seconds or minutes apart. So now the user should pick the date of the blob backup or slightly later. This date will give the same result with 3.1 and 4.0. But: when you use the new blob_timestamps == true option, these dates are the same.

Blob timestamps

  • Added blob_timestamps option. Default is false. By default we create blobstorage.0. The next time, we rotate this to blobstorage.1 and create a new blobstorage.0. With blob_timestamps = true, we create stable directory names that we do not rotate. They get a timestamp, just like the repozo backup. For example: blobstorage.1972-12-25-01-02-03.
  • When backing up a blobstorage, use the timestamp of the latest filestorage backup. If a blob backup with that name is already there, then there were no database changes, so we do not make a backup.
  • Automatically remove old blobs backups that have no corresponding filestorage backup. We compare the timestamp of the oldest filestorage backup with the timestamps of the blob backups. This can be the name, if you use blob_timestamps = true, or the modification date of the blob backup. This means that the keep_blob_days option is ignored, unless you use only_blobs = true.
  • Note: it is fine to switch to blob_timestamps even when you already have 'old' backups. Restoring those will still work.
  • blob_timestamps = true may become the new default later (maybe 4.1). This may even become the only valid value later (maybe 5.0), removing the creation of blobstorage.0. This would simplify the code. If you don't like this, please speak up and create an issue.

Archiving and compressing blobs

  • Renamed gzip_blob option to archive_blob. Kept the old name as alias for backwards compatibility. This makes room for letting this create an archive without zipping it.
  • Added compress_blob option. Default is false. This is only used when the archive_blob option is true. When switched on, it will compress the archive, resulting in a .tar.gz instead of a tar file. When restoring, we always look for both compressed and normal archives. We used to always compress them, but in most cases it hardly decreases the size and it takes a long time anyway. I have seen archiving take 15 seconds, and compressing take an additional 45 seconds. The result was an archive of 5.0 GB instead of 5.1 GB.
  • Note that with both archive_blob and blob_timestamps set to true, you get filenames like blobstorage.1972-12-25-01-02-03.tar.
  • Added incremental_blobs option. This creates tarballs with only the changes compared to the previous blob backups. This option is ignored when the archive_blob option is false.


  • No longer create the fullbackup script by default. You can still enable it by setting enable_fullbackup to true.
  • Added Python 3 support. The integration with plone.recipe.zope2instance is not tested there, because there is no Python 3 compatible release of it yet.


  • In most cases you can simply use the new version without changes.
  • Adding blob_timestamps = true is highly recommended. If you do this, you can remove the keep_blob_days option, unless you use only_blobs = true.
  • If you want the fullbackup script, enable it by setting enable_fullbackup to true.
  • When you used the gzip_blob option, you should rename this to archive_blob. Maybe enable the compress_blob option, but you are probably better off without this.

plone.restapi 1.0.0 released - A Story of Successful Open Source Collaboration

Posted by kitconcept GmbH on January 19, 2018 07:24 PM

After more than three years of development and 25 alpha and one beta release, we are very happy and proud to announce the release of plone.restapi 1.0.0.

plone.restapi is a RESTful hypermedia API for the Plone Open Source Content Management System. It exposes the unique and powerful features of Plone, including the core content management features as well as dynamic content type creation, workflows, permissions, versioning and more.

plone.restapi builds a bridge between a stable and mature Open Source CMS that has been around for more than 15 years and modern state-of-the-art JavaScript-based solutions like React, Angular, Vue and others.

A Little Bit of History

PLOG 2014

The development of plone.restapi started in beautiful Sorrento, Italy at the Plone Open Garden in 2014 after I gave a talk about building an AngularJS application on top of Plone.


A long discussion with Simone Deponti under the Italian sun, about REST API design principles and hypermedia (of course), led to the first commit and the development of a first proof-of-concept implementation. and PLOG 2015

One year later we gathered in Sorrento again. Laurence Rowe, Ramon Navarro Bosch and I spent our days and nights discussing the details of the REST API design and drafted multiple endpoints.


One of the main obstacles to building a RESTful API on top of Plone was the missing ZPublisher support for HTTP verbs such as PATCH, PUT or DELETE. In 2015, I sat together with Ramon Navarro Bosch in Sorrento (again) and we (he really did all the heavy lifting) started to build, a small package that adds support for HTTP verbs to Plone.

Archetypes and Serializers

We never planned to support Archetypes in plone.restapi. Though, when Thomas Buchberger and Lukas Graf came along and offered to build it, we did not object (of course not, this is Open Source). Their company 4teamwork planned to build a REST api on top of Plone for their OneGov GEVER platform.

Instead of building something on their own, they decided to join forces and share their work and code with the community. Along the way, they heavily refactored the code, added tons of adapters for loose coupling and the ability to customize the JSON serialization.

After this, we were confident to do a first alpha release of plone.restapi on June 14th 2016.

Beethoven Sprint

In March 2017, fourteen Plone developers from eight different countries gathered in Bonn, at the kitconcept office, for the Beethoven Sprint to work on plone.restapi and related topics. In addition to sorting out the last remaining design decision, many exciting new projects were started and announced.



At the Beethoven sprint, Eric Brehault started to work on an Angular SDK for plone.restapi. A release followed soon and Eric gave a very successful and crowded training at the Plone Conference 2017 in Barcelona.

Today, Angular SDK is a mature package for Angular 2 that makes it really easy for front-end developers to interact with Plone and a fantastic starting point for newbies.

Eric and I mentored Noel Varghese during last year’s Google Summer of Code to build a Progressive Web App for Plone in Angular 2. Noel gave a nice presentation of his successful project at the Plone Conference in Barcelona.


Rob Gietema and Roel Bruggink started to build a React-based front-end on top of plone.restapi at the Beethoven sprint in Bonn. Later that year, they went to Toulouse in September 2017 to implement the Pastanaga CSS together with the Plone Angular team.

In November they visited Bonn again for the Pastanaga Sprint where we started to implement the new Pastanaga UI for plone-react.


At kitconcept, we started to use plone-react with Pastanaga for an ongoing project. We can’t wait to release our work and contribute it back to the community.


Inspired by the Angular SDK and plone-react, Kevin Bieri started to build a VueJS plone-vuejs implementation on top of Plone at the Plone Conference 2017 in Bareclona.


Ramon Navarro Bosch and Nathan van Gheem revelead the name of “Guillotina”, a blazing fast async Python framework that shares the public API with plone.restapi at the Beethoven sprint in Bonn.

Successful Open Source Collaboration

plone.restapi started with an idea and discussions. People and companies jumped in and contributed in many ways that haven’t been dreaming about at first.

Simone, Laurence, Ramon and other helped to shape the initial idea. Lukas, Thomas, Roel, Carsten, Victor, Mikel and many others contributed new endpoints, bugfixes, etc.

Eric, Rob, Noel, Kevin, and others started to build frameworks and solutions on top of plone.restapi.

Many companies such as 4teamwork, Code Syntax, Markina Corpus, VNC invested and contributed to plone.restapi.

The Plone Foundation always supported our efforts by funding sprints.

plone.restapi is a true community effort and the joy that we feel when collaborating with wonderful people pays us back for the countless hours we spend on hacking on code.

Future Plans

A Plone Improvement Proportal (PLIP) to ship Plone 5.2 with plone.restapi has been accepted by the Plone Framework Team:

With plone.restapi considered stable and close to being feature complete, we will continue working on what could become the next Plone…stay tuned.

Continuous Performance Analysis with Lighthouse and Jenkins

Posted by kitconcept GmbH on December 22, 2017 06:11 AM

Lighthouse is an open-source, automated tool for improving the quality of web pages by Google. It measures the performance of a website and provides metrics for accessibility, best practices for modern web apps, search engine optimization, and assess web applications for adherence to Progressive Web App standards.

Lighthouse Logo Lighthouse Logo

Together with WebPageTest and Google Page Speed Insights it is an indispensable tool to optimize your website performance.


Lighthouse can be installed in any JavaScript-based project by just running ‘npm install’:

$ npm install lighthouse -g

If you don’t have a package.json in your project, just install npm and run ‘npm init’ before installing.

Running Lighthouse

You can check the performance of any website by calling the ‘lighthouse’ command with the URL of the website you want to test. Append the --view parameter to show the HTML report, right after the command has finished:

$ lighthouse --view

The report will give you five different ratings about PWA, performance, accessibility, performance best practices, and SEO.

Lighthouse Results Lighthouse Results

Continuous Performance Measurements

If you run your performance test every now and then, you always risk to hurt your website performance without noticing. If a performance regression happens unnoticed, it is usually very hard and time consuming to figure out which change caused the performance regression.

You can easily fix this and save lots of time when you run your performance tests and analysis continuously.

Unfortunately Lighthouse does not allow you to set performance test specifications that your CI system can test against, like WebPageTest or Google Page Speed Insights do (we will cover those tools in later blog posts). Though, it is still very convenient to run the performance test on a regular basis for each commit and include them into your CI report.

Install Lighthouse locally for CI

When it comes to a Continuous Integration, a local installation is prefered over a global one, which is usually harder to manage and to maintain. Especially if you have multiple projects with different sets of package versions on your CI.

Therefore we install Lighthouse locally in our project directory:

$ npm install lighthouse --save-dev

This command will install Lighthouse to your local package.json file. We recommend to use yarn or npm package-lock.json to lock down the package version you are using for a repeatable and stable project build.

For convenience, we add a “lighthouse” script to our package.json:

"scripts": {
  "lighthouse:ci": "node_modules/lighthouse/lighthouse-cli/index.js \
  --output-path=./lighthouse-report.html --quiet \

We call the locally installed lighthouse binary and set a static output path (by default, Lighthouse creates a file with the current date/time in the filename which makes it harder to publish on your CI).

We also include the --quiet option and run it on headless chrome, so we don’t need to install and run an X server on our CI system.

At the end, we hard-code our project URL into the command so we do not have to type it manually each time we run this command.

Now we can just run:

$ npm run lighthouse:ci

and it will create a nice HTML report that we can publish in our CI.

Configure Lighthouse for your local development environment

For convenience, we also add a command that you can run locally:

"scripts": {
  "lighthouse": "node_modules/lighthouse/lighthouse-cli/index.js \
  --output-path=./lighthouse-report.html --quiet \

The --view parameter will fire up a browser with the report at the end of the performance analysis. This is something we clearly don’t want on our CI system.

Publish Lighthouse Reports in Jenkins CI

Travis and other lightweight CI system usually lack the option to publish any reports except the command line output. Though, if you are using Jenkins CI, you can use the HTML publisher plugin to publish your Lighthouse report.

sh 'npm install'
sh 'npm run lighthouse'
publishHTML (target: [
  allowMissing: false,
  alwaysLinkToLastBuild: false,
  keepAll: true,
  reportDir: '.',
  reportFiles: 'lighthouse-report.html',
  reportName: "Lighthouse"

After adding publishHTML to your Jenkins pipeline, you will see a “Lighthouse” link under the ‘Artifacts’ tab:

Link to Lighthouse report in Jenkins Link to Lighthouse report in Jenkins

There is a caveat though. Jenkins 1.641 / 1652.3 introduce the Content-Security-Policy header to static files served by Jenkins. The default header is set to a very restrictive set of permissions to protect Jenkins users from malicious HTML/JS files in workspaces.

To allow Jenkins to display the Lighthouse reports, we have to add the following JAVA_ARGS to the Jenkins startup (for instance by adding the following line to your /etc/default/jenkins file):

allow-scripts; default-src 'unsafe-inline'; img-src * data:\""

For more details see the Content Security Policy Reference and the Jenkins docs on configuring Content Security Policy.

After you fixed the Content Security Policy of your Jenkins you will see the full report when clicking on the ‘Lighthouse’ link on the ‘Artifacts’ tab on your Jenkins build:

Lighthouse full report in Jenkins Lighthouse Report in Jenkins

Jenkins Declarative Pipeline Stage for Performance Tests

A full declarative pipeline stage for lighthouse looks like this:

stage('Performance Tests') {
  agent {
    label 'master'
  when {
    branch 'master'
  steps {
    checkout scm
    sh 'npm install'
    sh 'npm run lighthouse'
  post {
    always {
      publishHTML (target: [
        allowMissing: false,
        alwaysLinkToLastBuild: false,
        keepAll: true,
        reportDir: '.',
        reportFiles: 'lighthouse-report.html',
        reportName: "Lighthouse"

We run the performance test stage on ‘master’ agents and only on the master branch. The steps performed are a simple “npm install” to set up the project build and then we run ‘npm run lighthouse’ to produce the HTML report. If you already have an npm build from a previous step you can of course just unstash the build artifact.

Jenkins pipeline with lighthouse performance tests Jenkins pipeline with Lighthouse performance tests stage


Lighthouse is a valuable and indispensable tool if you want to deliver a fast and user friendly website. Running the analysis on a continuous basis on your CI is a good idea if you take performance seriously. Setting it up is fast and easy. Maybe in the future Lighthouse will also provide a testspec feature that will allow us to fail a CI build (or mark it as unstable) on performance regressions. Though, if you run WebPageTest or Google Page Speed Insights additionally, this is not really needed.