In Plone 6.1+, you can disable loading parts of the Classic UI code by setting an environment variable.
Motivation
In Plone 7, Classic will be optional: by default with CMFPlone you get a very bare Plone Site, and you should either add plone.volto or plone.classicui.
Meanwhile, in Plone 6.1+, it would be good to start preparing for this, and see which parts we can safely let away.
Assumptions
Most people who install Volto, do not need the Classic UI. It could still be useful as fallback though. In fact, on current plone.org as release manager I need Classic UI for creating a Release, as this content type has a classic rich text field, and not a blocks behavior. (I also need ZMI as fallback in this case, but I digress.)
In Plone 6.1+ we still want to ship all or most Classic UI related code that you get in Plone 6.0, including portlets. A start has been made on a plone.classicui package where some code or dependencies could be moved, but CMFPlone 6.1+ would pull this package in.
By default in Plone 6.1+ we still want to load all Classic UI related zcml. Disabling it must require an explicit step in a project. It is fine though if for example demo.plone.org completely disables Classic UI, or if an example Plone Distribution does this. plone.volto in Plone 6 must not do this though.
In Plone 7, the Classic-UI-only code will not be pulled in by Products.CMFPlone, but by plone.classicui, which would then become a dependency of Plone.
The user can set an environment variable DISABLE_CLASSIC_UI=true.
In CMFPlone in meta.zcml we will check for this variable, and then register a zcml feature disable-classic-ui.
In relevant places, check for this feature, and only load some zcml when this feature is not set: <configure zcml:condition="not-have disable-classic-ui">
We can use this to disable for example:
portlets
viewlets
plonetheme.barceloneta
plone.staticresources
Alternative:
Do not use an environment variable, but instruct users to directly set a zcml feature disable-classic-ui. Setting an environment variable will be easier for most.
Based on the new xml feature, we can either disable loading the portlets zcml in CMFPlone, or we check this feature in the code of Classic UI packages like plone.app.portlets. The last could be needed, because add-ons may load the zcml of plone.app.portlets anyway. For example plone.app.event does this, which I want to fix here. [Update: done.]
Deliverables
Products.CMFPlone branch to define the zcml feature based on an environment variable.
We should have a way of running at least some tests with Classic UI disabled, either in Jenkins or GitHub Actions. This may need changes in plone.app.testing: define a layer without Classic UI. Not sure if this is possible.
Several tests will need to be updated: when Classic UI is disabled, some tests should not run, because they will fail.
Some Classic UI parts should actually be disabled. We do not need to disable all possible parts, but I would say at least either portlets or viewlets. Viewlets would be the easiest, presumable just avoid loading plone/app/layout/viewlets/configure.zcml. But then the viewlet managers won't be defined either, so this may cause errors in the main template. We will need to see.
Moving more portlet code together would be helpful, but that can be done in a separate PR.
Risks
If zcml is not loaded, third party add-ons may break. But they should only break if a user deliberately sets the environment variable. So should be fine.
Probably we will change the order of loading zcml a bit, for example so we have a zcml condition in one place around loading four portlet related zcmls, instead of scattered over four different places. A different order could have unwanted side effects, but this should only be when another package does not load all the zcml it needs properly.
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer: Maurits van Rees
Seconder:
Abstract
In Plone 6.1+, you can disable loading parts of the Classic UI code by setting an environment variable.
Motivation
In Plone 7, Classic will be optional: by default with CMFPlone you get a very bare Plone Site, and you should either add
plone.volto
orplone.classicui
. Meanwhile, in Plone 6.1+, it would be good to start preparing for this, and see which parts we can safely let away.Assumptions
plone.classicui
package where some code or dependencies could be moved, but CMFPlone 6.1+ would pull this package in.plone.volto
in Plone 6 must not do this though.Products.CMFPlone
, but byplone.classicui
, which would then become a dependency ofPlone
.Proposal & Implementation
Proof of concept: https://github.com/plone/Products.CMFPlone/pull/3922
DISABLE_CLASSIC_UI=true
.CMFPlone
inmeta.zcml
we will check for this variable, and then register a zcml featuredisable-classic-ui
.<configure zcml:condition="not-have disable-classic-ui">
plonetheme.barceloneta
plone.staticresources
Alternative:
disable-classic-ui
. Setting an environment variable will be easier for most.plone.app.portlets
. The last could be needed, because add-ons may load the zcml ofplone.app.portlets
anyway. For exampleplone.app.event
does this, which I want to fix here. [Update: done.]Deliverables
Products.CMFPlone
branch to define the zcml feature based on an environment variable.plone/app/layout/viewlets/configure.zcml
. But then the viewlet managers won't be defined either, so this may cause errors in the main template. We will need to see.Moving more portlet code together would be helpful, but that can be done in a separate PR.
Risks
Participants