Eric Steele - Plone Futures

Plone is fifteen years old this year. What does the future hold?

Plone 5.0 has been really positively received. Plone 5.1 is where we apologize for what we did in 5.0. Some stuff:

• Meta bundles generation, so you don't get so many javascript and css files.
• Getting rid of the quick installer, so you don't have two competing ways of installing stuff. We have an @@installer view now that only uses GenericSetup. We will warn when there is no uninstall profile. The default profile is now really the default profile, instead of the quick installer taking the first one alphabetically.
• Configure portal actions through the Plone UI.
• Retina image scaling. Set scaling ratios for higher resolution images. Pretty seamless.

That is definitely going in. Probably several or all of the following as well:

• Conditionally import registry records.
• Merge Products.RedirectionTool into the core, with new control panel.
• Add/edit/delete registry records in the UI.
• Get rid of old resource registries (portal_css, portal_javascript)
• Merge collective.emailconfirmationregistration into core.
• Merge collective.indexing into core, giving queued indexing, which gives performance improvement.
• Some javascript improvements.
• Mosaic, not yet 'plipped' (proposed) for 5.1. This is content layout using tiles, giving you a lot of flexibility over how a page looks. We started similar projects years ago when browsers were not ready for it yet. Let's see a demo. The layout is saved as simple html that you can manually edit if needed.

With Mosaic and Rapido you have very powerful through-the-web development. We were pushing people away from this, to safe them from themselves. But with these two, you can export it to the file system, which makes it much more viable and safe.

For Google Summer of Code:

• Vikas Parashar created several themes.
• Prakhar Joshi worked on collective.easyform, which is dexterity form creation. It now has an upgrade path from PloneFormGen.

Plone 2020 discussion: where do we want to go as community and as software project?

• APIs to hide complexity. plone.api. plone.restapi.
• Improve TTW customisation.
• Improve training and documentation. You can follow a training at http://training.plone.org or use this to give a training yourself. It gives you a jump start to development.
• Cleaner codebase: simplify structure, remove unused functionality and code.
• Update dependencies to latest versions, ztk, Zope 2/4, ZODB3. Most are already Python 3 compatible. That is the step needed for Plone before we can focus on Python 3 ourselves.

CMS traditionally has three layers: content storage, management and presentation. Headless CMS removes the presentation layer. If you have that, you can write your own fronts for it: traditional UI, phone app, other front-end framework. What we are currently building with plone.rest and plone.restapi is more a decoupled CMS, because the original front-end is still always there. In a sprint in Barcelona we worked on several parts of this:

• REST api
• front-end: working with plone.server or plone 5 + restapi, server side rendering via Angular Universal
• back-end: plone.server, aiohttp-based server.

There will be several talks about these today.

So we have two parallel paths to the future:

• server/client with rest api
• back-end Zope and other dependency cleanup

What have we ripped out in the past? Kupu, Archetypes, classic theme, portal_interfaces, plonetestcase, xdv, portal_Css, DTML, NuPlone, etc. The Hello Kitty Theme. And Plone still works. So we can do this.