PLIP: Add option to disable parts of Classic UI

[mauritsvanrees]

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 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.

Proposal & Implementation

Proof of concept: #3922

• 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.

Participants

[tisto]

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

[yurj]

I think nowadays we can have an instance with classicui for distribution that needs it (see @mauritsvanrees example about creating a Release in plone.org) instead of enabling/disabling classicui with a variable in the same instance. This means to have ZEO installed, which I think happens everywhere. Less work because every distribution will use whatever it needs for every instance in a standard way. Also, mixing distributions and features (is classicui a feature or a distribution?) can be a lot of work to have no useful gain. Also disabling parts of classic-ui and still mantain the template rendering (see example above about disabling viewlets), is useful?

Keeping the Classic Ui with the most advanced configs will help also other distribution. I don't see people creating the same feature of Classic UI in Volto, React, Vue, web apps, just because they need a subsetting because this will open to slowing development, doing development in something not related to the interface and the project, errors and security problem. Fire up a Classic UI instance, do your settings/object create/edit and all are happy.

About the variable name, what if:

<configure zcml:condition="not-have disable-classic-ui">

became:

<configure zcml:condition="have classic-ui">?