When you build a CMS, you might start small, but you end up with a very large stack. For Plone, some of this stack is more than fifteen years old.

What do we want to work on for the future? Zope 4! Guillotina! Headless CMS! Everything! So many challenges and huge projects! In a business situation you would probably say this is bad. So why is Plone still alive? Emotions and culture.

A long time ago, creating a Plone package was as simple as using ZopeSkel and then ZopeSkel sub templates to add for example a new content type. But ZopeSkel is dead.

Plone is using the new mr.bob already for years, with bobtemplates.plone as main template for a new Plone project. But there were only basic templates, no list of templates, no way to add a content type or other things with a sub template, a hard to remember command. So let's fix that!

My vision: give me a tool which helps for:

• creating different projects, like an add-on or a buildout
• extending packages with content types, vocabularies, a theme
• provide best practice skeletons

Something like this:

$ pip instll plonecli
$ plonecli -l
templates:
 - addon
   - content_type
   - portlet
 - buildout
$ plonecli add content_type

Standalone templates:

• addon: basic Plone addon
• buildout: development/project buildout
• theme_package: full stand-alone theme package, based on Barceloneta, with grunt setup

Sub templates:

• content_type: Dexterity CT with XML or zope.schema
• vocabulary: dynamic vocabulary
• theme: advanced theme, including themesitesetup and themefragments
• more to come: tile, behavior, portlet

I have a fork of mr.bob that can list templates.

On plonecli you could use shorter, more easier to remember commands, and I want autocompletion to make it even easier.

We will sprint on this, so please join.

I am currently still the release manager for Zope. There is now a actually a release team.

Plone is built up like this:

• Python is the programming language.
• On top of this is the ZODB and the ZCA (Zope Component Architecture)
• Then the ZTK (Zope ToolKit), just a bunch of packages.
• Above it is Zope (2.x/4.x)
• Then CMF
• Then the Plone CMS

Unrelated to Plone:

• Pyramid sits on top of the ZCA.
• Grok sits on top of the ZTK.

The ZTK (like zope.interface and zope.component) was already mostly Python 3 compatible at the moment when we started working on compatibility for Zope. Jason Madden has done a lot and Marius Gedminas, Tres Seaver, a bunch of others.. There is very little development on the ZTK level, mostly just letting it work on newer Python versions.

Alexander Loechel already gave a talk on this conference about porting RestrictedPython.

We no longer call Zope Zope2, but just Zope. This is version 4. Forget about version 3.

ZODB and the ZTK support Python 2.7, 3.4, 3.5, 3.6, PyPy, PyPy3. Status page of Python 3 compatibility for Zope related packages: https://zope3.pov.lt/py3/ More on the ZTK: https://zopetoolkit.readthedocs.io/

Zope 4.0 beta 2 has been released. That means no new major features should be introduced, focusing on bug fixes. Zope supports Python 2.7, 3.4, 3.5, 3.6. There is no support for PyPy or PyPy3. RestrictedPython is a big reason there, because that is currently just not possible on PyPy. For Acquisition you also have to use a C implementation, so no PyPy.

On https://blog.gocept.com you can find some good reports and stories about the Zope porting sprints.

CMF 2.4 beta is released. It targets Zope 4 compatibility. Currently only Python 2.7, but progress is being made on Python 3 support. The Plone community is also busy with that.

Some other changes in Zope 4, not Python 3 related:

• The distribution name was changed from Zope2 to Zope. Zope2 is now a meta distribution, depending only on Zope. This is similar to ZODB3 being renamed to ZODB. Please keep Zope2 as dependency in your own package, unless it really only works on Zope 4.
• Zope now uses WSGI, and there is a separate ZServer project. ZServer was written in the days of Python 1.5, so really old. We wanted to get rid of that and use WSGI instead. But to not completely lose the old code, we made this new ZServer project. The WSGI server only supports HTTP, not for example FTP. Also not WebDav as that was really to hard, although it is built on top of HTTP. Probably ZServer is never going to be ported to Python 3. So with WSGI you use something like waitress or gunicorn or Apache mod_wsgi to call Zope.

There are more optional projects for Zope now:

• ExternalMethod
• PythonScripts
• MailHost
• TemporaryFolder
• Sessions
• SiteErrorLog (instead just use the standard Python logging and the WSGI solutions for logging)

Some of these have been ported to Python 3, some not.

More changes:

• There now is a WSGI based zope.testbrowser. The old test browser was based on mechanize, which was not maintained and not ported, and that was not going to happen.
• There is full IPv6 support in waitress.
• Chameleon page templates is in Zope, without needing five.pt anymore.
• zope.globalrequest is in Zope, without needing five.globalrequest anymore.
• Upcoming minor change: support for unicode object ids under Python 3.

Zope 4 was started five or six years ago. The idea was first to remove lots of things to make it simpler. This has been partially reverted. But you might miss some features.

Future:

• Expect more Zope 4 beta releases over the next monts.
• Expect a final Zope 4 final release when it is done. :-) That will be when we have the feeling it is stable enough and we are only doing small bug fixes. See the issue tracker.
• There are no plans for Zope 4.1 or 5.0 yet. A nicer ZMI (Zope Management Interface) is being worked on, so it does not look like it was made in the eighties.

Remarks from the audience:

• David: Plone on Zope 4 is being worked on, and is making progress. We will further sprint on it this weekend.
• Eric: We will create a branch for Plone 5.2 this weekend, and try to get an alpha out soon.

The rewrite of the RRs (resource registries) started in 2013 or 2014 and landed in Plone 5.0. I would recommend using Plone 5.1, as various things have been improved there.

With the RR you register and deploy JS and CSS. You can organise dependencies, and optimise resources and number of requests. The resources are grouped into bundles, they are concatenated and minified. Add-ons can easily register their resources. Cache headers are set automatically.

In Plone 4 there were no formally defined dependencies, so that made it hard to manage. You just had a list, and that order was used.

In Plone 5, the RRs are based on plone.registry, RequireJS, LESS and the command line interface of gulp. Instead of LESS, a lot of projects have switched to using SASS now. RequireJS is also less popular. So there is still room for advancement.

The Plone 5 way solves dependency management, but it is complexer and harder to debug. I have had my problems with it, but usually it works quite well, and is a huge improvement over Plone 4.

The js/config.js file in mockup contains configuration on how the javascript in Plone should be built. In Products/CMFPlone/static/plone.js you can see how the plone bundle is defined, and what it requires.

You can still define legacy resources, which work like they did in Plone 4. They are wrapped by some code that temporarily undefines the define and require definitions, otherwise you get errors.

In Products/CMFPlone/static/plone.less all the needed LESS definitions are imported or defined, used for creating our CSS. LESS is very handy for defining for example a text color once and use it in lots of places. [In Plone 4 we did this by using DTML files.]

You can customise and override the plone and plone-loggedin bundles in your code, if you maybe do not need everything that Plone offers by default.

collective.lazysizes has a good example of defining resources and bundles. In its registry.xml it uses condition="have plone-5" to only apply this part on install when the site is Plone 5.

With ./bin/plone-compile-resources -b plone you compile the plone bundle resources. This is also possible TTW, but I recommend the command line tool.

Get a normalised state for your json data. Think about how to structure your data so you don't duplicate data, and you have quick retrieval. For example use the normalizr library.

Use Redux development tools to give you hints or boiler plate for a new test.

Use components. When you use them, make sure they don't block other components: if four other components are not getting shown until a fifth one is ready, that is not a good idea. Give the user the information that is already there. Already show a skeleton on the page of how the component is going to look, so you only need to fill in some extra stuff and the user can already see how the component will look like.

Watch the component life cycle: which part is taking the most time?

Check if repainting is really needed before you do it: maybe a data value gets set but it is the same as the old value. Catch this and save on rendering. Use the Chrome Render Tools.

Use local, non-committed environment files to make differences between local development and production. .env may contain the default values for everyone, committed, and .env.local has your local tweaks, and you let git ignore that.

Use route wrappers to for example ease checking for anonymous or authenticated users, and do some calculations in there, so you don't need to do that in all kinds of places.

Offline first: have some javascript that runs in the background for hijacking netword requests. If you are offline, this should queue the network requests for later. IndexedDB could be more useful here than localstorage.

Use the ESLint command line utility to check the quality of your code, including your fellow developers.

Find me on Twitter: @devonwbernard.