Plone as headless CMS story interest group

1

I’ve been pushing hard the last year for Plone to have a solid headless CMS story.

Why? Because it makes more sense than ever. Plone already qualifies for this category of CMSs, since we made Plone RESTAPI layer a reality. It turns out that in 2024 is how CMSs sell nowadays. There’s been an outburst of them in the last years. We need to update our selling narrative to include this face of our beloved CMS.

We are selling Plone the same way we did since early 2000, leaning on a monolithic UI, either Classic or Volto, and feature comparing with other solutions out there that does the same. But the fact is that since our stack has grown over the last years, now is capable (or potentially capable) of much more. For these reason we should be able to broaden the Plone feature offering and cover new use cases and integrations where Plone can be used.

I gave a talk about it during the last Plone Conference, if you still haven’t watched yet, it’s a good starting point.

I am currently advocating and evangelising about a new set of packages that will allow us to build this new story. I briefly explain them in my blog post:

My proposal is to approach this from two different vectors: A pure technical one, and a more marketinian one.

Since both sides are huge, I'd like for now this group to focus in the technical part.

My approach to it is quite simple: we need to provide Plone of the missing pieces that are necessary to build this story. We have the most important one: the RESTAPI interface. There are other pieces that we are missing, some of them are buried in Volto itself and are impossible to use outside it. Others have to be rethought and refactored. Others have to be built from the ground up:

  • An agnostic client to access the RESTAPI
  • A new data fetching layer pluggable
  • A new set of agnostic set of headless UI components
  • The Volto add-on and configuration registry as a standalone package
  • Contents view and other CMSUI components as standalone
  • Typings in all the stack

Once we have them all, we could build Plone sites on the top of any framework, build or environment.

These packages are foundational, meaning, we can't build more complex things if we don't have them and we battle test them.

The ultimate goal is to reintegrate them into our reference implementation (Volto) so it can benefit also from them.

My intention with this team is that we start meeting and muse around these ideas and continue the development of these new breed of Plone tools, so we keep going steadily.

Who's in?

PS: This interest group is not addressed for newcomers or GSOC candidates students.

12 Likes
2

I'm in, to be determined on what capacity and when but I am for sure interested in pushing this work forward.

3

When you say any? What if my target is an existing low code platform such as Webflow?

4

That's the whole point, you have to tell me. I have no clue what Webflow is and what it does provide to their integrators.

I talked about creating a bunch of pieces that will allow us to build a Plone Site using any framework, build or platform. You should build that integrations out of them. Obviously what we can't do is to build a story for any framework, build or platform out there, but we can show the way and how to do it in a few, so people can follow.

Do Webflow have a JS build of any kind? Can you integrate third party libraries on it? If yes, you will be able to use @plone/client at least on it, retrieve Plone content with it.

5

I am interested.
I proposed a decoupled editor POC as. GSOC project which I hope we get a good candidate for POC Decoupled WYSIWYG Editor UI for Plone Headless · Issue #5767 · plone/volto · GitHub.

I think the attraction of headless is to provide a compelling editing experience without having to customise the editor or learn how it's code works or requiring use it's reusable components. All you then need is your own view components, framework to render them and to understand the API.

I also have a talk last year that I hope showed how much nicer the developer experience would be for those implementing a design system with preexisting code if such a decoupled admin UI existed for plone.

https://www.youtube.com/live/_XmKc7jNIE8?si=OE1-c-B9Z6tLcLIp

6

In my opinion one of the most important architectural features of a CMS (and of course of Plone) is the separation of content and layout. In Plone we store the content as different mime-types and we transform it if needed when we use it. The RESTAPI interface has here since long time a bug on the conceptional API design level that prevents using that feature: The content is overwritten with a html version despite the mime-type. See issue #1526.

I am afraid that no framework will ever be able to use that feature until that bug in the RESTAPI (the "most important piece") is fixed.

7

@mekell I just read the issue, I think we are all waiting for your PR fixing the issue to arrive.

8

@sneridagh I'd very much like to fix this bug if I had the time (and the know how). I'd suggest to ask the original developer and/or the maintainer to take this responsibility on code quality. See my comment there.

My point here though is whether a headless CMS is possible with such a conceptional bug.

Simply think of content that has to be presented to a frontend framework in formats other than HTML.

9

I think this is a bad project to have for gsoc due to the complexity of such a task. I don't expect students to have the necessary knowledge to make such a thing and I wonder which mentor would have time to overview such a task.
Maybe I'm wrong in my assumptions but I think that this task would require work from ppl with deeper knowledge of our stack than students just starting and the easier tasks we have for gsoc students the more likely they are to complete them

10

I think it requires the ability to reverse engineer how storyblok does things and ripping out a lot of hiw volto works and replacing the selection and dnd with something new. I suspect it requires less knowledge of volto than you think and these are parts of volto that need redoing anyway according to victor.
We can mentor but unfortunately we don't have the money to build this ourselves at the moment.

11

@djay I finally had time to read well your proposal (PLIP).

I get the overall idea, but I have lots of questions. I will answer in the PLIP itself.

In general, I think that it needs to be brought more down to earth, especially if you want to convert this into a GSOC project. Right now, if I were a GSOC student, I would have not clue where I should start, except that you want to build a "StoryBlock"-like editor for Plone. This requirement alone could be overwhelming for a young student. Compare the power that has a student that just learned frontend technologies, that is still studying, and don't have full dedication to the achievement of the GSOC with the amount of resources that a VC-startup based like StoryBlock would have put on implementing such a thing and get the dynamics of it right.

I'd be glad to discuss this further. But I'd say we need:

  • A clear list of requirements and goals.
  • A clear list of deliverables.
  • How would this play with the current vision of the Plone's headless CMS story and all the other packages that are being developed.
    • How would this play with @plone/components
    • Which data fetching layer it would use (in both sides, view and editing)
    • How would this play with the new theming story
  • Dependencies between them.
  • Unified Block Model (View/Edit relationships)

About the last one, we are working actively at kitconcept in developing and defining a unified block model for Plone, so we can overcome all the problems of the past with this. Let me tell you more about this when we meet.

Don't get me wrong, having a decoupled editor not tied to Volto is paramount, and the lace of all this new story. However, I agree with @ichimdav that it cannot be taken lightly, in a rush, nor achieved with low cost resources. If we were about to do that, for that outcome, tbh, we already have Volto which does the trick. I still think that it's the last thing that we have to address, we cannot build the house top to bottom... we should lay down the foundations needed for the most complex piece of the puzzle, which is the editor. Knowing the final shape of the other pieces, will also help shape in a good way this final piece and reach an architecture that is loosely coupled and that you can put anywhere.

1 Like
12

No worries, when we get there, I'll most likely be asking and experiementing.

13

I would be glad to help if I can.
My focus is more on Svelte at the moment, and integrating the Plone RESTAPI in SvelteKit is one of my projects at the moment.

1 Like
14

if it lets you use a webapi then yes.

but to me the issue is, what would you need to do to make the editor/Admin UI work well. Because currently Volto assumes you have have a Volto version of every block you want to use. So you are doubling your work. You would have to reproduce webflow inside volto.
Victors reusable components idea maybe not help unless webflow lets you use React components.
This is why I think the most important part of a headless solution is an Editor that works with any framework without having to customise it, ie decoupled. ie you have both the webflow frontend and the volto admin UI sitting side by side on the same page and still have a volto like editing experience.
And it's doable. It's been done. You won't get 100% as good a UI as Volto but you might get 80-90% and for a lot projects thats fine.
I've revised the GSOC proposal POC Decoupled WYSIWYG Editor UI for Plone Headless · Issue #5767 · plone/volto · GitHub to make it a lot more clear how this works.

I think one very important point is that Volto now and the Volto proposal with the reusable components, both require you to upgrade your frontend every time you upgrade the Admin UI to get new features. This is currently a big problem for us and I'm sure it is for others also. A decoupled Admin UI would prevent this.

15

Fair enough. If I can combine Plone's CMS capabilities (breadcrumbs, flexible workflow, granular permissions, heirarchical content structure) with Webflow's design capabilities, there might be something interesting.

Webflow has something called Devlink, but it is really for designing React components and isn't so good for round tripping.

In the past, I was able to pull this off with Diazo and Webflow. Now that I'm moving over to Volto, There are pros and cons, I've had to make the tradeoff and focus on Volto's block-oriented approach.

I'm sharing to help to stimulate discussion, maybe someone can draw some ideas from this.

16

@pigeonflight It's possible I'm answering this from the wrong perspective since I don't know webflow.
It seems that webflow is more a page builder. So I'm guessing your workflow was to use it to generate a template that you then plugged in content from the content type.
A volto page can work like this but it would be a shame. Volto is designed to give editors some flexibility on layout. And it does that by have by having blocks which often work well with a design system. If the output of webflow is not designed to be moved around and componentised and flexible then using blocks is not going to work well. But maybe you can set up containers in such a way to only allow text and image blocks inside them...
But as Volto is now you can't use a diazo style where you bring in your outside html and js and have a visual editor that uses that. Not without converting that all to Volto and React.
With something like StoryBlok, or a headless CMS with a decoupled editor, then you can. But it's still not going to make much sense to use a page builder when what you should be using is a design system and use the visual editor for layout. You get less control of positions of things but more consistency. This page describes it well What's the difference between Storyblok and a website builder? | Storyblok

17

I'm not trying to bring the Diazo way to Volto. What I'm always looking for is opportunities for faster iteration.
I think there's a continuum between "page builder" and "block editor". Tools evolve and move across the continuum as they add capabilities. I've seen this with Webflow. In the early days, it was firmly in the page builder category, but now, Webflow supports the concept of reusable components and has it's own CMS and APIs. Let's call it a "visual builder".

It's about how the components get built

The win for me, if this is possible, is being able to build the components of your design system using a visual builder like Webflow. It doesn't have to be Webflow, it could be TeleportHQ which allows the export of blocks as React components. Some of this can be done even with Figma, see: Converting Figma To React the Fast and Easy Way | by Jack Herrington | Medium

Two approaches - Code vs Visual Builder

I work with both approaches.

  1. Code your design system and components
  2. Use a visual builder to create your components

I've found that approach #2 makes it possible to quickly add/rearrange elements and instantly see the results. This rapid feedback allows for faster iteration. The approach is also not widely used or supported in the Plone community yet.

Approach #1, generally involves changing and running the code to view changes. This is minimised with hot reload but still adds some overhead from my experience.

This might be the right initiative

In summary, I'm looking for the simplest way to support the creation of my Volto/React components. While, I don't see it as the goal of this initiative, it may open the door to more easily creating components visually.

18

If webflow lets you design and generate reactive components that make sense as blocks then I think a headless cms is the right approach.
You want one that lets you leave those components largely untouched in whatever framework they were built.for.

1 Like
19

While I'm still new to this project, I'm eager to learn and contribute. Is there a specific area where developers could provide assistance in moving this project forward?
I'm particularly interested in exploring WYSIWYG editing capabilities for the decoupled editor. Are there any libraries or frameworks like CKEditor or Tiptap that could be integrated with Plone's REST API to achieve this functionality?

20

Sorry for the delay, let's start meeting. During the last Volto Team meeting, we thought that we could piggyback on the normal Volto Team Meeting, the weeks that we are not having them, since almost all of us we have already allocated that time slot.

Would it be ok to start tomorrow? Tue 5, 11CET in Discord is ok?

/@djay @ichimdav @tiberiuichim @ebrehault @pigeonflight

Maybe early for @pigeonflight , right? But then if we delay it, it might be late for @djay . Open to suggestions.