Plone (6.1+) Architecture and Mental Model

Development Roadmap and Future
1

Over the last few years, we’ve been working hard to untangle the Plone backend, and I wanted to share some updates and future plans.

Major Achievements:

  • Circular Dependencies: Our first goal was to eliminate all circular dependencies. We’re thrilled to report that we’ve successfully removed all circular dependencies in the standard installation. However, we still have some work to do with test extras.

  • Mental Model Development: We’ve developed a clear mental model of Plone’s main components, which helps us understand the system better and make more informed decisions.

    • There are two main borders in the system:

      1. plone.base and its dependencies (like Zope, CMFCore, etc.)
      2. Products.CMFPlone, which offers a core Plone installation. It depends on a plethora of packages in the space between itself and plone.base. It does not include plone.api, plone.restapi, or the distributions.

    • Three Spaces of Plone: Thus, we have three distinct spaces in Plone:

      1. The Foundations of Plone: This includes plone.base and its dependencies.
      2. The Core: This encompasses Products.CMFPlone and everything between it and the foundation.
      3. The Integration Space includes everything above CMFPlone: API, Distributions, Core Add-ons, Release

Developments at Beethoven Sprint 2024:

During the Beethoven Sprint 2024, we discussed the introduction of distributions to make the installation of different Plone flavors easier and more understandable. Érico and his team worked on plone.distribution and integrated it into plone.volto.

Current and Future Distributions:

  • plone.volto (in progress)
  • plone.classicui (to be done)
  • Future possibilities/ideas: plone.edu, plone.intranet, etc. (only rough or no plans yet)

Core Add-ons:

In addition to distributions, we have core add-ons. These packages are maintained by the Plone community and are considered part of the core Plone experience. Core add-ons include:

  • plone.app.caching (Caching support)
  • plone.app.iterate (Working Copy support)
  • plone.app.multilingual (Multilingual support)
  • plone.app.discussion (Commenting support) - PLIP in progress for 6.1
  • plone.app.portlets (for a future release)

plone.app.upgrade (Upgrade support) is also a core add-on with a special role, enabling upgrades to newer Plone versions. While it’s not installed as a profile, having it available in a service instance or globally is crucial.

Core add-ons are not included automatically when you install a distribution, but you can add them separately as needed. Neither plone.api nor plone.restapi must have a hard dependency on those.

Integration Package:

Lastly, we have the integration package "Plone". This meta package pulls in all dependencies for a full Plone installation, including all distributions, core add-ons, and their dependencies.

Diagrams:

I’ve attached diagrams to illustrate the integration space components of Plone and how they are connected. A more detailed diagram shows the actual dependencies among the three spaces.

screenshot_2024-06-05_11:24:45_selection
screenshot_2024-06-05_11:24:45_selection1752×884 103 KB

screenshot_2024-06-05_11:36:50_selection
screenshot_2024-06-05_11:36:50_selection1733×2061 243 KB

We’re excited about these developments and look forward to your feedback and contributions. Let’s keep improving Plone together!

12 Likes
2

That sounds great, thank you all.

I'm interested in what needs to be done for a plone.classicui distribution.
E.g. is the untangling of Page Templates into a central package a requirement?

3

Overall the first step would be the distribution itself, so profile, dependencies on all levels, ....
Moving templates is then the second step.
And no, templates are not a central requirement for 6.1, this can be done later.

4

This is very useful work @jensens it certainly brings a lot of sanity moving forward.
BTW.... what tool was used to do that diagram?

5

I used the https://www.mermaidchart.com sankey diagram

1 Like
6

@stevepiercy if I would write a page for the docs with this information, where would you put it?

7

We don't really have a place for planning documents in Documentation, mostly because they get out of date within a few months. As a general rule, we should never put into Documentation something that has not yet happened.

Once planned work is complete, then I think the best place for now would be Overview — Plone Documentation v6.0.

In the future of Documentation, we would have a Design Document in an Explanation section, in which all the design and architectural decisions (at least those that we can remember) would go, something similar to what Pyramid has in its Defending Pyramid's Design — The Pyramid Web Framework v2.0.2.

1 Like
8

I can rewrite it to only contain the current state of the backend.

1 Like
9

That works for me. Thank you!