plone.volto is mentioned as dependency in different parts: e.g. plone-backend's Dockerfile or Plone's config.cfg.
it is not a requirement for running Plone 6 with the classic frontend, but it is part of the core Plone 6 'distribution'.
Just like plone.app.multilingual is part of the core packages/distribution for Plone, but not necessary if you run a single language website. Or plone.restapi if you don't need to connect through rest.
plone.volto is a small support package that offers extra setup,profiles and other utility functions if you want to use the volto frontend. the frontend itself is not included in this Python package so it doesn't save you much space by trying to not include it in a setup for Classic.
I assume that's the reason why you ask if it is necessary? Or are there other reasons? 
@fredvd Thanks for clarifying!
Actually it is a requirement to NOT install plone.volto for Classic UI. Among other things it disables the Richtext-Behavior for Documents and other types.
Plone 6 is rapidly evolving with very interesting technologies. Thanks in deed to the whole Plone Community! But its architecture (and specially the “new Plone” terminology) is becoming somehow confusing to me. IMHO Plone 6 Classic (with its own "frontend" e.g. Barceloneta) is conceptually something different than Plone 6 backend (as a mere "backend" for Volto).
I’d like to see Plone 6 Classic as a “first class citizen” in the Plone ecosystem. By reading the current documentation (as well as the new installation proposals) one could get the impression that Plone 6 Classic is becoming a kind of "side effect" of Plone 6 backend.
1 Like
@pbauer Thank you for this very helpful information!
Answer: No.
My Plone ClassicUI installations are depending only on Products.CMFPlone, plone.app.caching and plone.app.upgrade
Additional and if needed (project specific) I include one of
- plone.app.iterate
- plone.restapi
- Products.CMFPlacefulWorkflow
Sometime (for larger clusters) I do not include plone.app.upgrade everywhere but run a service instance having it.
1 Like
You are not the only person that gets confused. Can you provide a link to the passage in the Plone 6 Documentation that you find confusing? Let's make it clear. Please file an issue for further discussion. But first check if any of the following is relevant to what you experienced.
There was a recent discussion about how we lack a section in the Plone 6 Documentation to help users choose a frontend. I created an issue to resolve that.
To help you on your way, we have two frontends, "Classic UI" and "Volto". I am of the firm opinion we must stop calling the older frontend "Plone Classic" or "Classic" because it lacks a user interface context and gets confused with the backend or the entire thing that is Plone. And that Overview of Plone is another open issue in the docs.
There is only one backend, and it is OK to name it "backend".
The many packages is another matter, but we try to keep that clear by using inline literals, like "plone.volto", and not get sloppy with "plone.volto", in narrative documentation. That formatting has meaning to readers.
1 Like
@stevepiercy Thanks for clarifying.
I reformulate my question with your terminology: Is the package plone.volto a requirement for the "backend"?
Non being part of my original question I still have questions (that of course not belong here but in the Overview of Plone):
Like: What is exactly the "backend"? Is it the package Plone and its dependencies without plonetheme.barceloneta and evtl. plone.theme and evtl. plone.volto? Which packages/components constitute the "Classic UI" frontend?
Yes if you want Volto, no if you want Classic UI, for the frontend.
Good questions. I'm afraid I don't have a simple answer, but it will get defined in the Plone 6 Documentation, once the open issues regarding around this topic are resolved.
The backend is when you install Volto and use Plone just for restapi and some configuration.
Backend vs. ClassicUI
At the moment it feels more or less the same. You can have ClassicUI without Restapi, as mentioned above.
But it is not the same. In my lighting talk at the Plone conference I sketched the "Mental Mode of Plone" we developed at last Beethoven sprint. In this model we have two packages defining mental borders to define the Plone architecture: plone.base and Products.CMFPlone. Why?
plone.base defines the contracts for Plone: The interfaces. It also provides core utilities to work with. It depends on Zope, CMF, but also some other low-level packages.
Products.CMFPlone depends on everything that defines the core, the plethora of packages plone.* and plone.app.* that do not depend on Products.CMFPlone but depend on plone.base (mostly).
Then we have packages that are above Products.CMFPlone, because they depend on it: plone.restapi, plone.api, workingcopysupport, plone.volto.
And there is the Plone package which defines our default distribution, which depends on those I named the paragraph before.
I pretend to create a page for the documentation, latest at Alpine city Sprint but probably before, going more into details with this.
@jensens Thanks for the explanation. I've created a script to explore the package dependencies.
1 Like
It looks so... simple. LOL.
Out of curiosity, what tool did you use to generate this spider web?
I adapted some code of pipdeptree, added some logic to cluster packages based on regular expressions, constructed a digraph with graphviz, generated a DOT file and converted it to SVG with Graphviz DOT.
For detailed instructions see the README.md.
lol, yes, some work needed to untangle this way more. I did the same some time ago and it looks now better than it used to.