Why is Volto "overriding" classical dexterity types

Development Plone 6 UI (Volto)
1

plone.volto kind of "overrides" some classical dexterity content type like Document, Event or News Item by adding the volto.blocks behaviour (see plone.volto default types).

Doing so it is not trival to use the original functionality of those content types (like e.g. classical forms with fields not simply in the sidebar).

I'm wondering why this decision was taken instead of creating new volto specific content types like e.g. "BlockDocument" or "BlocNewsItem" and leaving the dexterity types unchanged.

In my opinion this would allow a "peacefully" co-existence between Volto and Classic content in the same site. As well as allowing smooth-er migrations from Classic sites to Volto.

I'd like to understand the rationale behind this decision. Is there any documentation, talks or discussions about this?

I've already read different posts here like for instance Can Plone classic and Volto coexist? or Volto and Event content type.

2

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
  • No Collections

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.

No collections

Collections feature set was superseded by the listing block in Volto, so it also was redundant to keep it around.

3

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?

2 Likes
4

@mekell

Correct me if I'm wrong, but you are making 2 assumptions here:

  1. One often wants to have a Plone website where both frontends are active at the same time for the same content

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

You * don't * want to activate 2 competing editing frontends that are based on different frontend technologies and support vastly different underlying html/javascript outputs for the pages in the same server processes and on the same content.

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.

2 Likes
5

Thanks for the kind reminder.

6

@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. :rofl: 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.

1 Like
7

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.

8

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.

9

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.

10

I was not involved in the decision process, but I suppose nobody thought one would plan to use both frontends in parallel. I always understood it is meant to use ClassicUI XOR Volto UI.

The idea is to use

  1. ClassicUI if you come from 5.2 or earlier and want an easy upgrade
  2. ClassicUI to start fresh and have some application use case is not (yet) supported by Volto.
  3. Volto on a fresh site.
  4. Volto on a fresh site and migrate all content to Volto (there are already tools for many use cases).
11

I'm afraid that this could be kind of a "Chronicle of a Death Foretold" for Plone Classic UI. I dare to say that some customers won't be amused.

Do are the use cases for Plone Classic UI really reglectable in the Plone community? I'm reluctant to believe that this can be the case.

1 Like
12

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.

13

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:

[options]
include_package_data = True
install_requires =
    setuptools
    # WSGI
    Zope[wsgi]
    waitress_fastlisten
    # Plone core
    Products.CMFPlone
    plone.app.upgrade
    plone.app.caching
    plone.restapi
    # Addons
    collective.collectionfilter
    collective.fieldedit
    collective.impersonate>=1.4
    collective.revisionmanager
14

I thank you all for your interesting comments.

Unfortunately this topic has derived in a direction that was not intended when I posted this question.

I'm ok if there is no need to take care of the issues I've been mentioning. I just thought it could be relevant.

15

because it allows for more control over how data is displayed and accessed. This gives developers more flexibility when creating applications.

16

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.

17

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.

18

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.

19

Yes. You are right. I thought it were polite to react to the answers even if they don't answer my question. I apologize.

20

Nonetheless I'd like to point out that my question was not about "why" but about "why instead": I.e. why override existing types instead of creating new ones?

Specially because plone.volto already creates its own types in plone.volto.content but overrides the existing ones in plone.volto.profiles.default.types. With a minimal effort here one could have avoided the mentioned consequences.

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.