Here are the slides.

A talk about the essence of Plone. What does Plone mean for somebody?

Plone is an awesome combination of vision, software and community. But what defines Plone, what is the essence, and how does it change over time.

At the Plone Conference 2019 I had the feeling of realizing why we sometimes speak of very different things and why the Plone of today is not the Plone we know from the years.

This talk wants to summarize this feeling of realizing, explain why we may have a problem of misconception. It is a mix of technological questions, the overall vision, branding and community topics in depth.

Plone is a software, an api, a community, a foundation. Plone core is an API, but there are more than one: plone.api, plone.restapi, the Plone UI, none is complete. Every Plone company has a different point of view of what Plone is or should be.

Plone is a mature open source Python CMS. As said earlier today, implementations change, but values do not. We want to simplify Plone.

What is or was Plone for me? The CMS product, the framework/toolkit, the vision, the community, the foundation. Plone is an umbrella for a lot of frameworks.

Anish Kapoor: "All ideas grow out of other ideas."

Plone was the User Interface that gave users the power of Zope and CMF. It is a layered system. Layers hide complexity, make complex things easier, you have a defined API between the layers. It should be possible to switch out one layer for another. For  example we switched out the Archetypes layer for the Dexterity layer.

We are the Plone community, not the Zope community. Values and ideas are more important to us than technology.

Problem for API: there are always undocumented features without API definition.

At Plone conference 2013, Paul Everitt showed a lesson from Zope 3: rename the beast. Zope 3 was very different from Zope 2, so it should have been renamed.

The vision lives on. Volto is the future of Plone UI. It is the essence of the Plone vision.

I want to thank all the active Plone community members.

The Plone Foundation has a mission: protect and promote Plone. Lots of decision making, but no coding.

Wishes for the future:

• Endorse Volto, the Plone vision of simplifying CMS work
• Attract new developers, keep the community vital
• There is overlap with the Pyramid and Pylons family, we could absorb them.
• Stay commented and learn from each other. There are no rock stars, everyone started small and is still learning from each other.

Most important milestone for Volto this year: we went from a small number of people to a critical mass of developers who work on Volto.

Plone has evolved from a product to a contract. Implementations may change, but values do not. Tiberiu Ichim: "Through the freedom that they provide,Volto blocks are a foundation for innovation that enables Plone to step in line with the latest state of the art for web development."

Volto is not only UI and UX for Plone, but it is a framework. We have design principles, like approachability, do not overengineer things, frontend and backend are meant to be decoupled, use semantic versioning.

Where are we in Volto today? 203 releases, 58 contributors, closed 1253 pull requests, 3024 commits. In which areas is Plone 6 better than Plone 5 today? Blocks engine, authoring experience, we have a schema and layout editor, the listing block, direct access to the full JavaScript and React ecosystem, performance. Bonus: Volto still works with Plone 4 as API backend. So if a customer is not ready to jump to Plone 5 or 6, you can give them a new UI on top of Plone 4. Every last Friday of the month we have the Volto Early Adopters Meeting. It is open for everyone interested.

We call Volto 4.0.0, from March 2020, the maturity release. And in nine months we went to Volto 10. We have huge improvements in extensibility. A new generator based on Yeoman will replace create-volto-app.

• There is a new add-on architecture, using the mrs.developer tool.
• API Block Transforms are great. You can serialize and deserialize input and output. We use this for example to handle resolveuid links.
• Lazy loading
• You can force a layout in the blocks editor, so Editors have to stick to this layout.
• You can copy and paste blocks now, even on a different page in a different window.
• Listing blocks: we talk about adding support for variations, removal of the listing container object from the results.

Future:

• We want to bring back slots in Volto, a mix between viewlets and portlets, evolution of the Plone and Mosaic tiles concept.
• Adoption of the Slate editor.
• Albert Casado worked in UI improvements for us.

Plan:

• Brief introduction to each framework
• Followed by discussion focused on use cases
• Maurits will live blog (thanks!)
• Framework vs. Product - let’s not worry about that!

For each system:

• What use cases is it well suited to
• What use cases is it poorly suited to

Discussion:

• Focus on client use cases and what frameworks would be a good or poor fit
• You can also ask questions!

Live blogging.

Use cases:

• Non-profit with custom forms and import/export
• Concert venue with strict event listing and advanced settings.
• NGO needs a database application for their highly confidential data.
• Generate a map out of data, and store extra information, like images for the data.
• Three-person company with basically static pages, non-technical users.
• Real-time application with websockets.
• A large company wants to monitor how well their customer service staff are doing. Strict form with statistics on it.

Pyramid:

• Best for APIs, not really CMS or websites, but applications
• Start small, grow
• Complex non-profit use case: you would have to build everything yourself.
• Event listing: we have a site that manages stuff for music bands as example, you just need some endpoints. Maybe websauna on top.
• NGO privacy: security really good, and simple enough to understand the full system. You can fully build your own fine grained security system. UI is a lot of work.
• 100 person company wants intranet with various content, installable by local IT team.
• Intranet: try to create a good solution for multiple clients, not tailored to one in a consulting project. Pyramid is good for building such products.
• Map: pyramid does not care which database you use. In a project we are mapping electical grids. In Guillotina they think they are nice with AsyncIO, but it makes their whole codebase harder to understand.
• Real-time: we had websockets for a year, but it was too slow, so we rewrote it in Go-Lang.
• Form statistics: you can create a form, store it in a database, export it, fine.

Django:

• Aimed at 80% of use cases, simple auth system
• Good for CRUD apps, smooth beginning
• Non-profit: export/import is good, we can do forms. Sharing access gets tricky
• Event listing: Django can do it, but just use Wordpress. But the technical user can do this in the admin interface.
• NGO privacy: permissions are too simple OOTB, not per object. You may want end-to-end encryption, which no framework offers. Limited built-in audit log, nice start.
• Intranet: not good fit for Plone for the people who do not often work with it. Django has easier CMSes for this. The expenses claim form could be easier to integrate into Django. Deployment just needs Postgres. DjangoCMS is Plone Light. Wagtail is WordPress Plus.
• Map: any of the frameworks except Plone can do the geo stuff in postgres. Images just on the file system. Static and uploaded files are handled fine by Django, can also be in the cloud.
• Real-time: not many Django users will care about websockets, will never be the focus.
• Form statistics: you can but I would not do it. This feels like a custom web application. Do it in any framework.

Guillotina:

• Small framework, scale from small to big
• Non-profit with forms: decent fit, use JSON schema
• Event listing: go to wix.com or something, it seems too simple
• NGO privacy: Good fit, permissions are no problem for this. You need to build the full UI. Okay, you may be able to start with Volto as UI, but that needs integration in the backend.
• Intranet: backend can handle it, need to build UI, deployment can be with docker and kubernetes.
• Map: for the large files, Guillotina wins because of AsyncIO.
• Real-time: we use websockets just fine.
• Form statistics: you can build an app, depending on your UI skills.

Plone:

• Good when you have different use groups with complex requirements for security.
• Edit interface is doable, but less so on mobile.
• Import/export complicated, but you can hire Jens.
• Difficult to find skilled people.
• Non-profit with forms: really good fit, end-users can create the forms. The import/export would need help from a provider.
• Event listing: do not bother with Plone. It sounds more relational, Plone would be overkill.
• NGO privacy: you need deep understanding of Plone security, hierarchy for storing data. Audit logging with add-on.
• Intranet: Plone is fine. You may need to help with installing at first, but it will keep running once installed.
• Small almost static site: none of us.
• Real-time: once Asko is done with his ZServer improvements, we can do it.
• Form statistics: do not use Plone. Use sed, awk, perl. Technically you could use some add-ons.

What is PAS? It is the Pluggable Authentication Service from Zope and Plone. It manages everything related to users and groups, like authentication, permissions, searching. It can get or set information from your site or the request or an external service like LDAP.

It uses plugins, so you can register your own. You can see a lot of those in the ZMI at the Zope root, at http://localhost:8080/acl_users/plugins/manage_active.

There are about twenty different plugin types, and they interact with each other.

In Plone we have Products.PlonePAS. It adds Plone-specific plugins and types in PAS, for example the local roles plugins. Local roles are regular parts of Zope, but not pluggable there. So this is at http://localhost:8080/Plone/acl_users/plugins/manage_active

So this is the basis to manage security, users and groups, using plugins that can be activated, deactivated, and ordered, and these plugins interact with each other.

Now let's go to the kitchen and make a plugin. We want our Plone Intranet to use an LDAP plugin. At the time, we started using Products.PloneLDAP, which builds on a few other Zope packages. (Currently pas.plugins.ldap is the more modern choice.)

We also wanted Products.membrane: this allows to create content that works as user or group. It uses a separate membrane_catalog, a sort-of copy of the portal_catalog, for better or worse.

We wanted collective.workspace to manage roles through groups instead of sharing.

And Plone Intranet itself had some extra sauce (plugins) on top. And important: caching, for performance.

It worked fine! But after a while it slowed down. We had many calls to LDAP, in the wrong way, even with the cache in place. We were using the membrane catalog too much, causing the catalog queue to flush, causing a slowdown in the standard portal_catalog search. We were also writing on SOLR, again external, which did not help for performance.

So what was the reason of the bottleneck? The big deal is when PAS does not find what it is looking for. It then tries all relevant plugins, which are intertwined. For example it finds a workspace group, and needlessly goes to LDAP to search for this group there, where it will not be found, etcetera.

So maybe we could store the LDAP information in Plone. We decided to sync LDAP in the Plone objects.

And then we also patched PAS. Finding a group results in trying to get the properties, parent groups, roles. Our patched PAS skipped plugins that looked unrelated.

There was another problem: a custom local role manager. There were users that belonged to lots of workspaces. So also to lots of groups. So role assignment was slow: you need to get all roles of all groups. We replaced Plone's local role manager with a custom one.

Another plugin is the recursive groups plugin. Standard in Plone. This can be really expensive. For each of those thousands of groups you would check if they have a parent group. We replaced this with a utility that could handle this fast, using graphs with networkx. With this, we could replace all our group plugins, especially the recursive groups plugin.

Possible problem: in the graph we had 20.000 nodes, 25.000 edges, 25 relations. But creating the graph took 50 milliseconds, so that was okay. The nodes are strings like principal_type:UID, for example collective.workspaces:Admins. We stored the information in OOBTrees: uid2path, path2name, name2uid, and an OOTreeSet called edges. And then nx.DiGraph(uid2path) to create the graph. This helped speed things up a lot.

To keep the data structure up to date, we use events.

To recap:

• remove external connections when possible
• know the limitations of your plugins
• you can patch PAS to avoid some plugins
• you can use a custom group plugin

Further ideas:

• lazily create collective.workspace groups
• lazily fetch group and user properties and roles

Takeaways:

• PAS is great, but mixing and abusing plugins can be deadly
• Sometimes replace plugins with a new one that does exactly what you need.