Report from Plone Open Garden 2017, roadmap discussion

Events Sprints
1

A belated report from PLOG - thank you to @chrimba @jensens @fredvd (blame for the delay is all mine!)

3 Likes
2

PLOG2017 Roadmap discussion

(this has been published to https://plone.org/roadmap/)

  • release Plone 5.1 as RC very soon
  • End support for Archetypes before we can go to Python 3
  • When release 5.1, warn about dropping Archetypes support
  • Plone 5.2:
    • Zope 4
    • RESTAPI
  • some add-ons that make use of RESTAPI (e.g. Pastanaga, React/Rob Gietema, Angular)
  • Plone 5.3
    • Mosaic will still be an add-on
    • option to disable portlets? but need Castle CMS slots. slots as an add on? needs investigation
    • plone.app.blocks and plone.tiles
  • Plone 5.4
    • some Castle UI features (recycle bin, image/file/video repositories, quick add, content quality check)
  • Plone 6
    • Pastanaga UI
    • full Mosaic: content editor + site layouts + slots (instead of portlets and viewlets) + turn off Diazo rules
    • Drop Archetypes support
  • Headless CMS is already a thing, so frontend implementations of Pastanaga (in Angular and React) will be released at some point (before Plone 6)
  • Go to Python 3 (since Archetypes has been dropped)
  • Login
1 Like
3

On January 26, 2017, we had published this roadmap document:

4

please don't

2 Likes
5

the roadmap looks pretty interesting but I have a huge concern right now as something is missing from it: when are we expecting to fix the resource registry situation?

also here I have some other comments:

  • we need to release faster with less features
  • Plone 5.2 looks pretty fine as everything seems to be ready
  • Plone 5.3 features still look not well defined
  • Plone 5.4 features look nice, we can probably release this features in 5.3 instead:
    • recycle bin: is a must have, perhaps should be initially in the form of an add-on to make it simpler to maintain
    • image/file/video repositories: can you please elaborate more on what does this means?
    • quick add: can you please elaborate more on what does this means?
    • content quality check: again, pretty interesting but must come also in the form of an extensible add-on; it's pretty important for developers and integrators to be able to extend easily the quality checks; also we need to define which quality checks will be included by default

some other things I want to bring to discussion:

decouple the web syndication code from the core, to make it easier to make this feature optional in the future; let's face it: web syndication as we know it has been slowly dying and RESTAPI will speed this up; this is from the Wikipedia:

Several major sites such as Facebook and Twitter previously offered RSS feeds but have reduced or removed support. Additionally, widely used readers such as Shiira, FeedDemon, and Google Reader have been discontinued having cited declining popularity in RSS. RSS support was removed in OS X Mountain Lion's versions of Mail and Safari, although the features were partially restored in Safari 8. As of August 2015, Mozilla Firefox and Internet Explorer include RSS support by default, while Google Chrome and Microsoft Edge do not. Additionally, reader services such as Feedly provide synchronization between desktop RSS readers and mobile devices.

decouple the social media integration code from the core, to make it easier to maintain; some of you already know that I was against of including this feature in the core from the very beginning. IMO, the feature implementation is naĂŻve, complex (it even depends on the syndication code), not easy to fix or extend, and it even includes support for proprietary "standards" like the so called Twitter Cards.

Social Media integration is not easy (just take a look the code of our sc.social.like add-on) and it also involves content quality checks that are outside from the scope of the current Plone 5 core implementation.

just to give you an example: in the past 2 days I've being working to fix a bug in our code that is caused by a wrong interpretation of what Facebook's Open Graph canonical URL (the og:url property) is meant to be. after reviewing the Plone 5 code, in order to make our add-on compatible with it, I came into the conclusion that I'm just going to hide the viewlets associated with social media in Plone 5 and replace them with our implementation.

besides that, we need to:

to be continued…

6

I also need to understand what "turn off Diazo rules" means and the implications.
I'm speaking as someone very invested in Diazo so I'll need some convincing!

I can imagine that removing Diazo gives Mosaic a more stable target.

7

If there are site layouts we are very flexible already with overall customization of the delivered HTML. In most cases, there is no Diazo needed. So, the idea, it can be switched off by default.

I agree Diazo can be amazingly useful for a wide range of use cases and should stay in core a long time unless we can solve such cases with a better tool.

Btw.: If we have Zope 4 and a WSGI publisher, we can also always use Diazo as a middleware. I did this in a Pyramid project and it works like a charm.

8

I share @djay and @pigeonflight concerns here: layouts and theming are different things; Mosaic is (among other things) about layouts. what's the framework team idea of theming in Plone 6?; please elaborate.

also, deprecation of portlets and viewlets should be done on an orderly way: deprecate them in Plone 6 (with huge warning messages) and remove them in Plone 7 to avoid the same mistakes we made with the resource registry in Plone 5.

9

Hi,

Well, rules.xml is also about layout. As @jensens said, if we have Mosaic site layouts, it can make most of the work we usually do with rules at the moment. The benefit is site layouts are in HTML, it is much easier to understand and to modify for any webmaster (compare to rules.xml which might be very complex).
So it appears we could disable Diazo by default (and still enable it if needed).

agreed

10

Until I try a theme with a site layout it's hard to tell but I can't see how it can replace the need for a transform layer than allows you to take any existing html from tiles, from plugins etc and turn it into the kind of html your designer demands. And does this in a way thats simple to learn, ie anyone with html and css knowledge pick it up. Jbot and associated hacking of the core of plone just aren't options for normal people.
Are site layouts kept in a theme package along with diazo btw?

11

It's not the framework team. They don't set the vision for where plone is going to go, just what isn't allowed. It's whoever happened to be at Sorrento.

12

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.

13

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.

14

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.

3 Likes
15

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.

16

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.

2 Likes
17

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:

18

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
19

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

1 Like
20

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

1 Like