Report from Plone Open Garden 2017, roadmap discussion

You are right, it does not allow that. You can structure your site layout (let's say it is quite similar to our old skin main_template), so you are free to define the markup you want.

The blocks it will display are provided by tiles. So if you want to change the markup produced by the titles on the fly, then yes, you need Diazo.
But I think an easier strategy would be to provide a way to customize the tile markup (and we do not have any tool for that at the moment I think).

Yes, much more simpler than using Diazo I think (you just edit regular HTML).

They are resources, they can be managed using the resource editor. They are not managed in the theme resource directory at the moment (as far as I know), but it should be easy to move them there.

Just keep diazo. It is a very useful tool. Don't go creating something new. It works well. It's easy to learn. What is motivation here? Have a single theme with both site layouts and diazo and let the themer use which one they want.

We definitely keep diazo anyway.

Let me explain how we end up with this idea of removing portlets, viewlets, and diazo rules:

  • the original subject was to integrate Mosaic in the core,
  • consequence 1: Mosaic provides tiles, and tiles could replace viewlets and portlets. As if it is not useful to provide 2 ways to do the same thing, we pick the best option => tiles
  • consequence 2: Mosaic provides site layouts, and it seems to be a very handy way to implement the page markup. CastleCMS uses site layouts, and at the end, they noticed their rules.xml was empty. Same thing here: as if it is not useful to provide 2 ways to do the same thing, we pick the best option => site layouts

It does not mean we will throw away diazo rules, portlets and viewlets for the next version. It just means we think those solutions are not as efficient as the Mosaic approach, so the next version should favor Mosaic.


In Castle we include the site layouts (we decided to call them "site designs" to distinguish them from the tile layouts) in the theme, as .html files at the top level of the theme.

I was also very invested in Diazo, I had rules on my theme for moving, hiding, adding and replacing elements all over the place.

After testing Castle for a few days I had my theme ready without needing a single Diazo rule.


well, then "whoever happened to be at Sorrento" must write a more in-depth roadmap to explain the rest of us that the rationale behind this, what we want to achieve and how are we going to achieve it.

we still need a marketing team instead:

Yes, the above are just the notes that came out of the discussion.

I look forward to the volunteers who are interested in helping! Please contact me. You can see what we are trying to do at

but product management is not part of it, though one similar task the team would like to help with but lacks a dedicated person for, is the writing of more humanly-consumable release notes.

1 Like

we definitely need someone to take over this; let me find out if we can find the right person here.

1 Like

I'm willing to try my hand at the marketing thing. Is there such a thing as a 6-month stint?

1 Like

Of course! We are flexible and would love the help.

I've updated (cleaned up) the roadmap discussion notes at

Here they are for your convenience (but this copy is missing links I have on the page):

These are the results of the roadmap discussion at the Plone Open Garden 2017 sprint held in Sorrento, Italy, in April 2017.

  • Plone 5.1 will be released shortly (currently in beta). See the detailed release notes.
    • We will end support for the old Archetypes content type framework (Dexterity is the current content type framework) as part of moving Plone to Python 3, which must take place by 2020.
  • Beginning with the Plone 5.1 release, we will warn about the impending end of Archetypes support.
  • Plone 5.2 is projected to include:
    • Zope 4 (currently being worked on)
    • RESTAPI, the plone.restapi interface package that allows JavaScript and other web software to use Plone as a back end service
  • Accompanying Plone 5.2, we will have some add-ons that make use of RESTAPI, such as:
    • the new Pastanaga user interface design
    • the React JavaScript reimplementation of the Plone user interface (led by Rob Gietema)
    • an Angular JavaScript client front end for web and mobile applications using Plone as a back end service (part of the Plone Headless CMS initiative)
  • Plone 5.3 is projected to include:
    • and plone.tiles
    • the Mosaic layout editor ( will continue to work with Plone as an add-on (that is, Mosaic will not be in Plone core)
    • possibly the option to disable portlets, but this would require the "slots" feature from Castle CMS, possibly as an add-on, but requires further investigation
  • Plone 5.4 is projected to include:
    • some Castle CMS features (the recycle bin; repositories for images/files/videos; replacing the "Add New" toolbar menu with an "Add" button that presents a popup dialog box allowing editors to add multiple instances of allowed content types in place; the built-in content quality check on state transitions that checks content for various things)
  • Plone 6 is projected to include these major breaking changes:
    • the new Pastanaga user interface design
    • a complete tile layout solution including content editing, site layouts ("site designs" in Castle CMS terminology), slots (instead of portlets and viewlets), and with Diazo rules disabled (replaced by site designs as implemented in Castle CMS)
    • no more Archetypes support
  • The Plone Headless CMS initiative is well under way; implementations of the Pastanaga user interface design (using either Angular or React, or both) will be released probably before Plone 6.
  • Plone will be able to move to Python 3 since legacy Archetypes support will have been dropped.
  • Reimplement Plone logins to work better with modern distributed/centralized authentication solutions.

I agree with @hvelarde, although its great there is some output from this discussion in italy every year, what seems to be missing is the rationale or "why". What input went into these suggestions? What were the pros and cons of the options? what were the other options? What is Pastanaga trying to fix? What user input went into it? What is a react UI angular vs vs Pastanaga and why have all or any? Why disable diazo when is a needed way for themers to adjust plone and plugins html to fit a theme? What problems is site layouts fixing? Is here are strategy here, ie an end goal and idea about how these get us there? What do the quality checks try to fix? Compliance to WCAG for content or is it something else? Is there a fix for default pages ( and the display menu ( in here anywhere? Whats wrong with plone logins? Is there a ticket for this problem?

At least some of the castle ones are based on actual use but it would be good to see anecdotes of how these features did solve problems, ie reduced training time, reduce support requests etc. Why these features and not others from castle? The only one I can see from that list that has a rationale is the add button allowing multiple items at once but how how big a problem was that? I'm guessing for some style of sites it is, but which ones? I believe the castle design for add also solves some of these problems - but is the plan to solve those too? A toolbar that is easy for addons to add items/menus into and has more sensible, shorter list of items (so many tickets).

but you can see how deflating when it's hard to see why or reasons we are going somewhere. I'm sure there are good reasons for each idea and it would be doing the community a big service and help inspire people if what went on at these geographically isolated events was spread out into the global community of plone.

Thanks for the explanation @ebrehault. I suspect what is going on here is that diazo provides two main benefits, and wildcards way of working only needing one of them. I suspect wildcard doesn't reuse a lot of other peoples plugins and when has python developers who create custom tiles and other files system packages. They may also use jbot which requires an experienced developer. We on the other hand use diazo, not just for layout, but to fiddle with html from 3rd party plugins to get what we need for a given them. We do multisite exclusively so never pollute our add-ons with theme specific overrides of html, like you can do if you have one server per site.

The other reason why the diazo approach is still useful is when working with external themes and designers. We recently did a theme that had to get redelivered for various reasons. Each time it cost us almost nothing just reupload that theme overtop. Sometimes a couple of rule adjustments. If you go with dismantling a theme into seperate html parts then you can no longer do that. This only works when you have designers who are very technical and in lots of communication with your plone developers.
That is just our experience. There are probably other ways people theme out there that should be considered.
Do you think its wise to make such a big direction change without wider consultation with people who theme a lot of sites?

It's really important to have the right people in the room when these discussions take place. The way the big boys do things is not the way everyone does things. This is why rationales and wider community outreach is so important.


Dylan asks good questions. It's important to have community members speak their mind and ask questions.

However, I do take issue with Dylan's (frequent?) comments about in-person sprints. Our community recognizes that things get done and progress is made much more quickly (and sometimes "at all") when groups of us gather in person and work in a concentrated way on a task. That is what PLOG has been, and even though we didn't declare it a strategic sprint this year, that's what it has become. Yes, that does not preclude using the conference as a venue for strategy, but we also know that the conferences get so big and busy that it's hard to lock many of us in ONE ROOM for a day or two to focus.

The pros and cons were discussed. I hope others who were in on each discussion point will jump in here or in the relevant GitHub issue to provide you with their perspective, but it was impossible to capture the entire discussion in written form.

I've never said in person sprints are a bad thing. My point is that I'm not sure its a good idea assuming that you will get a good strategy by a process that only includes input from those who can afford a week off work and away from family or who live in europe. From what I can tell, a lot the people who go to sorrento don't even actively engage with users of plone anymore but this year I couldn't see a list of who was there.
I don't think its that hard to find ways to include input before, during and after a sprint. It would certainly increase the value of what comes out of a sprint. Pretty much the only time I can think of where someone tried to get input from the wider community was @zopyx doing an internet survey before his talk in bristol. The only time I've seen a serious attempt at involving remote sprinters was the APAC sprint where teams used hangouts with screen-sharing enabled the whole time.

It's also important to not presume to know the answers but actually research what the needs of the community are. To ask.

Great. A good place to start would be to find out who wrote this and how Plone seems to not really have a key differentiator other than being harder than others to host and "good security record" (which isn't a differentiator).

let me ask this again:

other important stuff that needs to be addressed:

  • deprecation and removal of portal_view_customizations as it can lead to broken sites (according to the 2015 Strategic Summit Summary)
  • we need a canonical way of getting metadata from content to avoid repeating code all over the place (for instance, to discover if a piece of content has a lead image, to get the URL of it, etc.), plone.api?

I actually think that this echos the messages that we've put out there.
Three of the five things emphasized on were addressed to some extent:

  • enterprise integration (they did address integration)
  • industrial strength security (they addressed this)
  • limitless extensibility (they did mention the fact that it isn't average and can address multiple purposes)

What wasn't captured in the write up was

  • flexible workflows
  • robust scalability

I think they were pretty accurate, stating 512MB being the baseline for Plone hosting.
I feel like we're almost there with a trivial deployment story, it could be achieved with a tiny layer on top of ansible.

We did a Foundation membership survey I think in 2015 to try to determine overall strategy.

This discussion is also a mechanism for obtaining feedback on the discussion questions. Nothing is set in stone, certainly not in the roadmap. The results of PLOG discussions are always posted with the intent of getting feedback.