PLIP: Start separating Classic UI code from the core

[tisto]

PLIP (Plone Improvement Proposal)

Responsible Persons

Proposer: @jensens

Seconder: @mauritsvanrees

Abstract

Step by step move classic ui templates and view-logic to plone.app.layout, while keeping the API/business logic in core packages.

Motivation

• Cleaner, easier to maintain code.
• Separation of view-logic and API/business logic makes it easier to re-use code and reduce duplication.
• Smaller core, less memory/disk footprint for users of the Volto frontend which does not need the Classic UI code.

Assumptions

In Plone 6, when you use only Products.CMFPlone, we still want you to get the complete Classic UI, or at least most of it.
In Plone 7 the Classic UI is still included with the Plone package, but not with the Products.CMFPlone package. See PLIP #3955 for that part.

Proposal & Implementation

• Have a plone.classicui package.
• This will define the Classic UI Plone distribution, so it will have the code to create a standard Classic UI site.
• Begin moving code that is only for Classic UI (so useless for Volto) to plone.app.layout, with backwards compatibility in place, also for page templates. Update: move the code to plone.app.layout instead, which will become a core add-on. We keep plone.classicui small: only the distribution plus the dependencies.
• The dependency chain is: Plone -> plone.classicui -> plone.distribution -> Products.CMFPlone.
• When you install only Products.CMFPlone the "Create a new Plone site" will create a Classic UI site in the traditional way, so not using plone.distribution. It could be a bit more basic, because we would prefer not to maintain both the old and new way.

Precondition

We need a way to issue deprecation warnings for moved templates:

This has been developed in:

• Add jbotDeprecated directive with dictionary as single argument. zopefoundation/z3c.jbot#20

Deprecation chapter in docs is avail here as preview: https://plone6--1850.org.readthedocs.build/backend/deprecation.html#deprecating-a-template-position

Name of the Package - [your username], if you are working on it - [PR A/B]

Package	User(s)	PR Links
plone.locking	@ale-rt, @cihanandac	plone/plone.app.layout#384, plone/plone.locking#45
Products.CMFPlone	[username]	[PR links]
plone.app.content	[username]	[PR links]
plone.app.workflow	@MrTango	plone/plone.app.workflow#58, plone/plone.app.layout#390
Products.CMFEditions	[username]	[PR links]
plone.outputfilters	[username]	[PR links]
plone.app.dexterity	[username]	[PR links]
plone.protect	@cihanandac	plone/plone.protect#125, plone/plone.app.layout#386
plone.app.theming	[username]	[PR links]
plone.app.contenttypes	[username]	[PR links]
plone.app.i18n	[username]	[PR links]
plone.browserlayer	[username]	[PR links]
plone.app.linkintegrity	@petschki	plone/plone.app.linkintegrity#106, plone/plone.app.layout#389
plone.schema	[username]	[PR links]
plone.app.registry	[username]	[PR links]
plone.app.users	[username]	[PR links]

Optional packages (or future optional),

Which we will not move for now and probably never will.
These package are optional for Classic UI or could become optional.

Package	User(s)	PR Links	Comments
plone.app.portlets	[username]	[PR links]
plone.app.contentmenu	[username]	[PR links]
plone.portlet.static	[username]	[PR links]
plone.portlet.collection	[username]	[PR links]
plone.session	[username]	[PR links]
plone.app.viewletmanager	[username]	[PR links]
plone.theme	[username]	[PR links]	View/Template only in tests
plone.app.vocabularies	[username]	[PR links]	View/Template in a deprecated View for Plone 7
plone.app.contentrules	[username]	#4110, [PR links]
plone.app.customerize	[username]	[PR links]	Potential deprecation

Deliverables

plone.classicui package and shrunken Plone-core packages (those between (and including) plone.base and Products.CMFPlone).

Risks

• No longer fallback UI for a pure headless Plone (except ZMI)

Participants

TODO

[mauritsvanrees]

I talked with @ale-rt and @MrTango at the Buschenschanksprint. It feels like the discussion is not completely done, or not unanimous, but my conclusions from there are:

• Let plone.classicui only contain the distribution, nothing more.
• plone.classicui will always depend on Producst.CMFPlone, not the other way around.
• If we want to start moving templates, they can go to plone.app.layout, as that feels like a really Classic UI only package. Some parts should be moved out of there if they are needed by Volto. In Plone 7 plone.app.layout would then live above Products.CMFPlone and be pulled in by plone.classicui.

An alternative package name could be plonedistribution.classicui (or plonedistro.classicui), and then plonedistribution.volto to be on top of plone.volto. The idea would be that plone.volto already has too much code, and for a distribution it is best to be a very light package, just like the current Plone package has no real code.
But I am not much a fan of adding yet more packages.

[jensens]

I agree to have a small plone.classicui package and use plone.app.layout as the bucket for all layout/ui/template related.
I tend to not add more packages.
The other way around, features in plone.volto could be moved elsewhere, because meanwhile its very bloated. But that's OT here.

[tisto]

I approve this PLIP. cc @plone/framework-team @plone/release-team