This decision was taken long time ago, and it needs to be documented properly... sorry for the brevity here you are the reasoning behind.
The changes are:
All content types are folderish
No Folder content type
All content types are folderish
This was not the first time this feature was put on the table in Plone history, and given the UX pushed by PastanagaUI it made very much sense. So a content, contains their own resources, images and files. This helps for tidiness and users find it more usable.
No Folder content type
Once all content types are folderish, then the Folder content type looses its meaning, and it's redundant.
Collections feature set was superseded by the listing block in Volto, so it also was redundant to keep it around.
Making all content types "folderish" might be a good idea.
But they are not simply "folderish". They are "volto-folderish" (plone.volto.content.Folderish*). This makes those content types (Document, Event, Folder, News Items) unusable with Classic UI.
Why not make those content types really "plone-folderish"?
And if Volto needs/wants different content types: why not create new volto ones instead of make the old ones unusable for non-volto installations.
"Document" is not "Document" anymore.
From an architectural point of view: Is it really a good idea to have a frontend that kindof smuggles a package (plone.volto) in the backend behind the RESTAPI? This utterly kills the classic frontend?
Correct me if I'm wrong, but you are making 2 assumptions here:
One often wants to have a Plone website where both frontends are active at the same time for the same content
That such a setup shoud be a supported in a 'no technical knowledge' needed profile for non technical users/integrators because it is a common use case.
From a migration/upgrade point of view it could be part of the desire to 'slowly' migrate your site from a ClassicUI frontend to a Volto frontend. And if you really want to, it is indeed technically possible. But you need a lot of experience, really know what you're doing and have very very good reasons to do this and a desire to shoot yourself in the feet. It will take you days to weeks to months to correctly set up, and months and years of future maintenance and update issues.
If you want to have folderish types in classic UI: there's an add'on for that: collective.folderishtypes · PyPI . Might need some updates for Plone 6, latest classifier is for Plone 5.2.
The Volto frontend doesn't smuggle a package in the backend. It is by design that you use either Volto, or ClassicUI. And if you want a mix: it's all technically possible, but if you are asking here why it isn't configured for you by default this way or 'made easy', then it is unfortunately unlikely that it is a good setup for you.
@sneridagh@tiberiuichim One thing that has been confusing or rather slightly annoying while editing content in a Volto site is that everything in my (top) site hierarchy is a Page. I am lost without seeing the main site structure if I’m not reading every page title to umderstand it is a branch.
I want my folders back Da***t. But I realise adding back the folder ct just for that is not worth it. I had an insight though: it is only the editing UI where I want to see this.
What if we index an extra property on every (Page) item that stores if the page has any direct sub pages? And with that info show a slightly different Icon on the folder contents to signal that this page is part of the site structure. That would do it for me as a visual cue for the branches between the leaves.
The icons shoudn’t switch for contained images and files.
Heck we could even create 3 icons, where the folder icons slightly differ if more than x pages are there or if there are sib sub pages. Wondering about the indexing cost here as well.
Having two (or more) frontends competing with each other is not the issue at all.
In my opinion the problem arise when the frontends compete on the backend's definition and one of them (Volto) takes decisions on what the backend should look like and this decisions have serious consequences for the other frontend or for the whole system (Plone) at all.
As for now, switching to Volto is a no way back (to Classic UI) decision. This goes far beyond a simple frontend decission.
BTW: I'm not criticizing Volto itself at all. But I think some of the architectural consequences for the Plone ecosystem as a whole (including specially Classic UI, Dexterity, richtext) could have been overseen here. I do really appreciate openness when it comes to technical criticism.
One well known example is WordPress. Most of the advanced theming technologies there (page builders) make such assumptions of how content should be structured in pages that switching from one theme to another is actually impossible. This strategy has proven very successful from a marketing point of view in low budget market segments. But as soon as the needs of a project start growing it might become a really nightmare. I personally wouldn't be so happy with such a wordpressy-fication in Plone.
With 'competing' in my post I mean being 'equal' alternatives to create and edit content in the same project, the same website for the same group of editors. It's almost doubling the necessary work you have in development, maintenance, training, documentation and end user support for such a website.
Plus the technical and conceptual overhead of keeping the differences in UX separate: folderish pages vs folders with default view, the block layout vs another tile based composite page add'on. Links between content created with one or the other editing frontend. etc.etc.
That Plone now offers 2 'officially supported by the community' frontends that you could see as competing is indeed not the issue, that's the evolutionary path we're on to embrace new technologies.
To clarify: We do not use nor plan to use both frontends in parallel.
But what we are using is the RESTAPI in combination with Plone Classic UI. This (the RESTAPI) is in my opinion one of the achilles heels. In our particular case because it doesn't handle richtext values and mime-types properly.
I do not see any reason to install Volto to have the RestAPI. It works on its own very well. Actually, I use it even without plone.volto available, because I depend in my project profile package directly on Products.CMFPlone and plone.restapi, but not on the Plone distribution package. Here an example from a Plone 6 project setup.cfg:
From your comment above "But what we are using is the RESTAPI in combination with Plone Classic UI." I tend to say there is no problem with Plone, just a wrong configuration. So, there is no need to take action at the Plone side. Prove me wrong.
In my opinion it is not just a wrong configuration.
Take for instance the issue referred below (richtext fields). What if - as it is the case now - lots of code based on this conceptual misunderstanding (see the comments in the issue) are developed. It will probably come a day when nobody will be able nor willing to accept to fix such issue and this issue will probably be officially declared a feature (as already mentioned in the issue).
This kind of issues is what I am talking about. This is my point. Not the collateral issues added every time in response to it.
Well, you covered more than one topic here. The one I cited above is wrong configuration. I agree (and commented accordingly in the issue) the markdown serialization problem is a bug on a conceptional level.
And probably one could solve the richtext issue as well in a way that the new types (that in my opinion do not need mime-type conversion at all) use their own serializers/deserializers in the RESTAPI without conflicting with the existing ones which actually do need mime-type conversion.