Support Distributions to be built on top of Plone

[ericof]

PLIP (Plone Improvement Proposal)

Responsible Persons

Proposer: Érico Andrei [@ericof]

Seconder: Timo Stollenwerk [@tisto]

Abstract

Over the years, the Plone community has developed numerous "distributions" of the Plone CMS, even without official support from the core codebase. These include SENAITE, Quaive, Portal Modelo, Portal Padrão, CastleCMS, and ioComune. These distributions often require patching Plone or necessitate manual steps to create a customized Plone site. This PLIP aims to establish a clear protocol for creating and managing new Plone distributions, including the incorporation of example content during site creation.

Talk about plone.distribution at the Plone Conference 2023

Motivation

As one of the creators of Portal Padrão and a contributor to Portal Modelo, I have experience in modifying the Plone site creation process to include additional steps and customize the resulting site. However, each distribution, including Quaive and CastleCMS, has its unique implementation. The absence of a standardized approach and official support can lead to compatibility issues when changes occur in core packages like Products.CMFPlone.

Assumptions

We assume that the existing options in Plone’s Add Site page are basic distributions. Their content creation processes need unification to ensure consistency and ease of use.

Proposal & Implementation

We propose the development of an API to streamline Plone site creation. This API will facilitate site creation through Python code and RESTAPI, enabling the development of frontends for default Plone or SaaS offerings. A standardized method for importing content into new websites will also be introduced to enhance user experience and consistency across distributions.

Deliverables

• A new package, plone.distribution, which:
  • Supports Plone 6.0.
  • Implements basic content distributions, mirroring the content in plone.volto and plone.app.contenttypes, until these packages provide their distributions.
  • Incorporates ZCML support for registering new distributions and managing site creation.
  • Features an extensible "wizard" utilizing JSONSchema to facilitate user input during site creation.
• Elimination of conflicting site creation methods in:
  • Products.CMFPlone: Removal of browser/admin.py.
  • plone-backend: Removal of scripts/create-site.py.
• Modifications to:
  • plone.volto: Introduction of a distribution registration to manage default site creation.
  • plone.classicui: Implementation of a distribution registration to oversee site creation, replacing the existing method in plone.app.contenttypes.
  • plone.app.contenttypes: Removal of the existing content setup implementation.

Risks

Supporting Plone 6.0 necessitates that plone.distribution duplicates content from plone.volto and plone.app.contenttypes. It also requires the implementation of a unified site creation function and RESTAPI services, ideally situated in Products.CMFPlone and plone.restapi, respectively.

Participants

• Érico Andrei

[sneridagh]

+1 to the proposal. I subscribe to every single line.

Maybe it's worth to add the i18n limitation and that we need to find a good way to overcome it.

@ericof maybe you can also point to your Plone Conference talk this year, talking about them? I think there are really good points in there and it does expose the whole picture in an extraordinary way.

[tisto]

@plone/framework-team since this is a PLIP that covers both Classic UI and Volto I guess we need to schedule a call, or at least have a vote if we think that this is a good idea. Since I am seconding this idea, I am +1.

[mauritsvanrees]

I obviously like this idea and would love to have this in Plone 6.1.

Some details are not yet clear to me though, especially around the dependencies, and possibly circular dependencies:

• plone.distribution depends on collective.exportimport, which depends on plone.restapi. plone.restapi is currently not a dependency of Products.CMFPlone. So when you pip install Products.CMFPlone you should not get plone.distribution. But this means there is duplication of code between plone.distribution on one hand, and Products.CMFPlone, plone.volto, and plone.app.contenttypes on the other.
• plone.distribution depends on Plone. But don't we want Plone to depend on plone.distribution?

[ericof]

@mauritsvanrees Excellent points.

Dependencies

My original vision was to move site creation logic to Products.CMFPlone and keep a slim plone.distribution focusing on high-level API to register new distributions and provide a UI and rest endpoints.

Of course, we would need to address how to handle plone.distribution with Plone 6.0 and the code-duplication we would have until 6.1 is out.

Export / Import

I would love to see Products.CMFPlone (or GenericSetup) shipping with a default way to serialize and deserialize content to JSON and collective.exportimport, focusing on handling all possible edge cases and conversions used in migrations.

I want to discuss implementing this and where it should be done.

@pbauer, opinions here?

[MrTango]

+1 for the whole idea could you please explain this point a bit more in detail:

Implements basic content distributions, mirroring the content in plone.volto and plone.app.contenttypes, until these packages provide their distributions.

[ericof]

@MrTango, In Plone 5.2 and 6.0, we have the example content being implemented by setuphandlers in plone.volto and in plone.app.contentypes. To support plone.distribution being usable in Plone 6.0, we need to mirror the content created in plone.volto and plone.app.contenttypes, but for Plone 6.1, both packages should replace their setuphandlers implementation by distributions.

[ericof]

@mauritsvanrees, @fredvd, @pbauer : After some digging, it seems the plone.restapi serializers and deserializers would be very hard to be refactored into another package. Any opinions?

[mauritsvanrees]

• The Classic distribution has portlets.json . This could just be a standard portlets.xml .
• For each distribution automatically register a profile directory as GS profile. Instead of profiles.json you can have a metadata.xml . (But the json also has a content key.) Uninstall should not be needed: you would just delete the Plone Site.
• How would we translate the default content into other languages? One profile per language? Run a translate function over the json right before importing it?
• I doubt ordering.json is needed: we import the items in a specific order, so that should be fine already, at least when we export them in the correct order in the first place.
• Volto/default: is 1.json really enough? Or does other content still need to be added?
• Could we add is_default_page: true to the classic jsons that need it? The importer would then set this as default page of the folder. If two items have this in the same folder: the last one wins. Then we would not need defaultpages.json , at least not in plone.distribution.
• Is the headless option needed? Can’t we support the portlets and defaultpages export steps automatically only when they are needed? Even if they give an empty file, it would be okay. Or we could automatically leave an empty file away from the export.

[jensens]

I added a PLIP configuration to buildout.coredev - @ericof please check the branches!

run buildout -c plips/plip-distributions.cfg in coredev