POC Decoupled WYSIWYG Editor UI for Plone Headless #5767
Comments
|
There seems to be an extended interest for this, if I understand correctly from this: https://community.plone.org/t/plone-as-headless-cms-story-interest-group/18885 |
|
@djay sorry for not coming back to you before. I have some doubts, let me ask some questions inlining them, as I also weigh in on some matters:
What is for you a "component"? Are we taking about a React component? After a first read of the PLIP I don't have it clear.
Without React? how? in the editor UI? Then what you'll have in the editor UI? How would you model it? and then render it? As a blocks setting form? as a block editor? If so, a direct consequence would the that inline editing is no longer possible. Maybe you mean with the iframe, reaching to the "View" framework/deployment/development of that hypothetical site?
So the detached view mode working in another framework would receive the updates, let's say, via websockets? Then update itself accordingly? NextJS claims to have such a thing, but not sure if a solution cross platform/build is possible. Meaning, possible most probably is. But having the bandwidth/resources to implement this is a project on its own.
Which API?
Agree, this is part of the new theming story that we are pushing nowadays. Bring your own design system to your public site.
Fully agree. The monolithic edit/view approach in the same place is a thing from the past, and it's not aligned on how the modern web works. In terms of performance, bundle size and others, it's just wrong.
Even allows you the option to not have to deploy the edit bundle somewhere. In some scenarios, the editors could have the CMSUI build locally and build the site from their computers.
Indeed.
You can model a block without thinking on how it's going to be displayed, skipping completely the view side. However, I can't see a practical implementation. Could you elaborate a use case? Eg. a slider block. You'll need to provide a view implementation, at least, along with the block model. A complete different thing is that someone wants to create a complete different slider block view based on your base model, which is ok. Add-ons are complete by default, and have sensible defaults so integrators expect at least one reference implementation. There's still another dimension that I can think of. Block Styling in the block model. Did you think about it?
We can't compare a VC-backed startup with the development power of the Plone community. We don't have the resources nor the moneys for that. It should be possible, but we have to keep in mind our limitations.
Volto is Plone CMS reference implementation for the so called modern frontend technologies, and it's what it is. Volto follows the same monolithic approach that the ClassicUI approach, and we developed it in the image and likeness of ClassicUI. We cannot change it overnight, nor push for such a fundamental change, because lots of existing projects rely on it being like is it now. The Plone Community don't have the output nor the need for that. So I'd say it's out of the question. It has to be developed aside Volto, because conceptually it's another thing.
Where would that model be saved? in the backend? What benefits would that bring? aside from allow the users create blocks on the fly. How the view part would adapt to a new field? How would it render it in the intended way? You'll have to adapt both sides still, right?
This is good, and what we are aiming for, by all means.
As said before this is challenging, and not clear how this will happen in an agnostic (bring your own frontend) way.
I fully agree, I'd also like to remove the D&D from the main interface. It has no point any more. I love the Elementor navigator.
What needs to be implemented by the integrator then?
Same as above, this is challenging.
At first read, this seems to me from another world... an iframe, tracking scrolling, mouse events inside it forwarded outside? Maybe StoryBlock has gurus that are able to do this, no doubt about it...
This StoryBlock bridge, it's kind of magical, isn't it?
We need more down to earth deliverables, especially if we want to present this PLIP as a GSOC project, so young student candidates, totally new to Plone can understand what we want and what we want to accomplish with it. We need a more detailed set of requirements as well. I am not opposed to explore this using a GSOC project, I'm only pointing out that it can be daunting, both for the student and the mentor. @djay You know that I'm very much in favor of making this a reality. It's the way to go, and it would be amazing making this idea a reality. I will help in everything that I can. However, it cannot be taken lightly, and it should be thought and taking into account the vision, the current scenario and the Plone Community resources and make decisions accordingly. There are a lot of other moving parts that we want to address and all of them have to play well together towards the common goal. We have learned that lesson the hard way by having to implement Volto in a rush. Now we know what we did wrong, and how we would do it better. Let's do it better this time. Rushing through things does not work, and every single piece of the puzzle has to play well according the master plan. The final architecture has to make sense and sum of them has to be a symphony, if you allow me the metaphor. As always, I'd be glad to discuss it in the upcoming interest group meetings. I'd say since it's a complex matter, let's talk about it face to face, and not engage in a back and forth GH powered discussion. |
|
@sneridagh we;ve made some changes to make it clearer for you. Please re-read all of it before replying. |
|
@sneridagh I've responded to some of your comments below to try and address some of your points (in addition to the updated PLIP). I'm happy to dive deeper into anything, but we're still piecing together some of the implementation details.
Component was possible the wrong term to use here. We're just talking about being agnostic to the frontend technology used to build the interface. The mention of plone/api here is both the REST API and
The idea is that you can attach a
See the response above about the Next.JS preview mode. This is the bit that needs fleshing out the most as the 'live updating editor' is potentially a significant amount of work.
The
While yes
Correct in that you can
Again, we're completely impartial as to how you display anything here. Controlling styling through block or site settings would be done the same way as how it is done with
Agreed here. I've touched on this below, but we should try to find a way to build this that is maintainable as a community
I'd agree that this is one of the biggest contention points: maintenance of such a technology as a community and I think needs further discussion as a community as to how to take this forward. Some people are already struggling to keep up with the big sweeping changes coming in future Volto, introducing an entirely separate technology may confuse integrators further. However, we could also build this headless editor idea in a way where the core components of it can also be used by current and new Volto, sharing the codebase and having things be more maintainable. For example, we could make the
We've updated the PLIP to mark this as out-of-scope. I think it may be useful as part of the 'bigger picture', but isn't an essential deliverable for this project.
Same as the above discussion about how the edit mode live listener will work.
The intergrator's work will be taking the data from the
StoryBlok gets you to assign a block UID (and additional information) to some HTML so that the bridge and visual editor can link information together. This would be part of the integration process. See https://github.com/storyblok/storyblok-js?tab=readme-ov-file#3-link-your-components-to-storyblok-visual-editor for how StoryBlok does it and how it provides helper functions to make this easier.
We aren't sure about the WYSIWYG story yet to be honest and is something we want to discuss further and would definitely love some community involvement! |
I've put in some more ideas on how this could work. If storyblok can do what it already does with overlaying block menus etc on blocks inside an iframe when all it needs is a data attribute to enable this. Then I think inline editing is also possible in a similar way. I've put more detail into the proposal how this could work in a way that requires very little code integration from the integrator. |
|
I will take a look today! |
|
We use something like this IFrame Bridge in our CMS Layer at e-ventis one Plone/Zope base. I would compare it to Level 3 of your PLIP. If only serializable stuctures are used (like you are used to do it in REDUX), you are able to use buildin window.postMessage as gateway. This makes the IFrame nearly transparent. Send up events as JSON-like structure, send down changed data as requested from the server and re-render. Or sent down an action/command as JSON-like structure and trigger it inside the IFrame. Could be a middleware/plugin in plone.client? We also use something like RPC to call functions in a transparent way. Define a proxy-function inside the IFrame and run it outside in the editor or the other way round very easily. I would love to give feedback on implementation detail or share our experiences, if it's wanted. IFrame bridge is a really nice name, but it's no magic in my opinion. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage |
|
@mtoepfl thanks for the added details. I also forgot to mention that the RPC part there are existing packages https://www.npmjs.com/package/iframe-bridge. The way I've written it this IFrame bridge code is doing two things however and I think victor might have been referring to the how it will need to place visual elements like menus in the right spot overtop of the IFrame but not inside the IFrame. |
|
@djay @JeffersonBledsoe I've taken a closer look at the updated info, I think that it looks a lot more better and it's more understandable, especially for newcomers and potential GSOC candidates. From the GSOC point of view, I'd say that the only thing missing is to elaborate and clarify a bit more the deliverables. For example, I will focus in an specific implementation of the frontend to be demoed, and include it as a deliverable. I don't care what we use, but it should be used as a demo. Also, we will need detailed documentation, including the development/deployment story around it. From the release manager perspective, I think we should stop saying that this will be part of Volto. We need to work still in the wording, which I plan to do in the upcoming sprints, but I really believe that Volto should remain the "reference implementation" of the monolithic approach and UX concept should remain the same. Everything that we develop from now on, should be aside it, as an addition to the Volto offering. Could it be used in conjunction with the new things incoming? most probably, as complement, we'll see. So Volto must continue being Volto for the time being. This is an important message to send to the community. I am +1 to explore this way, since it seems that it could be useful for a number of use cases. I like the way you described the different architectural options. I still think that the "hybrid" and the "decoupled" have a lot of things in common (specially while you are on the simple side of the decoupled implementation), but we can polish the ideas. I'll be honest with you though, the "decoupled" way that you depicted, specially reaching the L4, is the top tier in resources and energy concerns to be spent. I still see lots of small things that we haven't think of, like where to save the blocks schemas, deployments, development story... These and more, all will arise while developing. We've been there before, while we developed Volto, and the monolithic way, is the conceptually simplest one. I'm sure you are all aware of it, but I wanted to say it anyways. Getting the dynamics and the developer experience and deployment story won't be easy either. I'm also concerned about the maintenance of the outcome of this after the GSOC. I'd like also that someone steps up and champion this. I'd like specially to be a company or companies to back the "whole" decoupled CMS UI idea. I won't also hide my personal intentions, since I think that it's also fair for me to be transparent. While I'd like to the "decoupled" way to be a reality, I personally like more a concept where the development experience and the user experience get together into a solution that is half way the "decoupled" and the "hybrid" way. Of course, then you have to tie your development to one platform (at least), and be RESTAPI powered. But I still think that's down to earth, and could show people how to do it in other platforms (Angular, Svelte, Solid, Qwik, etc...). By the way, this concept must also be provided outside Volto, for the same reasons exposed above. True, the decoupled way you barely will have to touch the CMS UI, but it will force you to write your adaptation in your frontend every single time, for every single block. This defeats the whole add-on concept. You won't be able to create an "slider" add-on that works for both sides. The add-ons architecture we created is one of Plone's community super-powers, both in classic and in Volto. Decoupling it from Volto was huge, and it's still to be seen its consequences as it opens a new world of possibilities. Anyways, I don't want to engage here in a list of things that why I like more an in-between solution. I will work in drafting also such a solution so I put my thoughts also in words, again, not as an alternative but as a complement to the "decoupled" way. That's why I loved that you defined the different architectures in such a way. Finally, thanks for pushing for this and volunteer for mentoring the GSOC project! |
|
@sneridagh I have to admit I'm not 100% clear on everything you are saying but we can discuss it in the first Headless interest group meeting. I'm glad the revised explanation now makes things more clear.
We will work on this
You are right. The two things the POC is trying to do is show
This is a fair point. If you say Volto is developer experience of combining a frontend framework and the Admin UX then you are right that a Decoupled developer experience needs a new name. (BTW Volto isn't monolith. still not sure I got the terms right. Monolith means all serverside. But Volto isn't headless which implies there is no expectation to build on a certain framework). I didn't want to say Volto Headless since we seemed to be talking about slightly different things both being Headless. Plone Decoupled or Plone D?
One way it could do is that it works well and it turns into a codebase we can promote. The really nice this is that once the Admin UX is decoupled it can be rebuilt using all the nice reusable components and more modern techniques with much less concern for breaking backwards compatibility. This should result in being able to make the editor UX better faster. Another outcome is that it doesn't work at all. The work an integrator has to do is too much and the editor UX is flaky in ways that were aren't good solutions to. In this case then Volto but made cleaner and more remixable is perhaps the best option. The most likely outcome is that it kind of works but needs a lot more work. But we will have a much better idea of that work is feasable or not I hope. If it does work well. Then there could be a way where compatibility with volto is possible, or at least not so jarring an upgrade. With Volto as it is now the customisation is mostly overriding a Block render view to make it look different. Volto as a frontend React framework that allows for overriding the builtin blocks could still exist. It's just that we would need to seperate overrides to the Admin UI and overrides to frontend as these would be seperate codebases. So code would have to be changed because of that. Also how the Volto frotend talks to Admin UI would of course have to go via the iframe bridge and not within react states and anyone who did more complex integrations assuming that would have to change their code for that reason also.
It's true it will always give you more flexibility and more freedom. But I also think we don't have to give up on customising the Admin UI. This is our advantage. Being open source we can allow developers do customise the admin UI using code where SaaS CMS can't.
Maybe a slider addon doesn't make as much sense in a decoupled headless since the Admin UI is really just a container that contains teaser like blocks and that should be something generic we get out of the box. What the decouple editor with an iframe bridge is doing is putting a very defined api between the view component and the sidebar edit UI (and the block selection, DND etc). Which is a good thing as this is all blured right now as you know. And that creates upgrade issues for anyone building on top of volto now. I know you are trying to solve how far apart to keep the editing UI vs the view/render component. The answer is far :) |
PLIP (Plone Improvement Proposal)
Responsible Persons
Proposer: Dylan Jay
Seconder: Jefferson Bledsoe
Abstract
As a integrator building a website I can:
StoryBlok, using its iframe bridge, shows how this can be achieved. The goal is to see if this can be reverse engineered and applied on top of the volto codebase to see if a similar Decoupled Headless experience is possible.
The end result will not be as nice as UI for editing as Volto is now (but close). But in exchange Plone will be useful to a lot more different integrators because they won’t be required to use React or Volto for their frontend and they won’t have to pay the cost of upgrading their frontend every time improvements are made to the Admin UI.
Motivation
Think of a CMS site as three parts
You can connect these three parts architecturally in different ways (“Integrator” used below refers to the developer who is tasked with building a website).
Headless/decoupled is what is growing in popularity. Why?
We want to grow Plone. Plone has good features, good security and good UX with Volto but it has always had a slow learning curve. Headless CMS has a fast learning curve for many frontend developers because you can reuse existing knowledge and are not forced to learn the CMS way. But almost all Headless CMS’s have less enterprise features and a worse editor UX. StoryBlok shows you can get close to Volto style UX while still being a decoupled Headless CMS. If we combine the method StoryBlok uses to achieve this (iframe bridge + visual editor) we can have a decoupled Headless CMS with a lower learning curve and a good editor UX, yet is still open source with flexibility around how it's hosted. This would be unique and attractive to integrators we don't currently have.
I acknowledge that a decoupled editor helps the integrators we don’t currently have more than anyone currently invested in Volto. This is a challenge for finding money/clients/time to invest in this effort.
However the reasons that should motivate current Volto core contributors are:
Upgrade cost - A new version of Volto with new Admin UI features requires a non trivial upgrade for any non-trivial site.
Slow rate of bug fixes - Without new interest we don’t have as many contributions to maintain and improve the code and this makes it more expensive for everyone.
Backwards compatibility concerns are making it much harder to get contributions to improve the Admin UI.
In some ways this is similar to python 3 vs python2. As Larry Hastings said in his 2014 keynote: “Python 3 is designed for the developers we want in the future, not the ones we have”.
Note: SDK and reusable components would make Plone headless easier for some but a good decoupled admin UI is needed for any Headless CMS with or without reusable components so it's not incompatible with the reusable components idea.
Assumptions
Proposal & Implementation
To create a Proof of Concept that using the same techniques of an iframe bridge, that StoryBlok uses, it’s possible to have a version of Volto that looks and feels similar but in a decoupled way where the frontend a integrator would create is not Volto and not even React.
The editor layout would look almost the same as current Volto. However the centre will be replaced by an iframe which renders separately hosted frontend (preview).
We take the iframe bridge idea from storyblok, now renamed storyblok bridge which gives a integrator a way to make custom blocks in any framework but still have them linked to the Admin UI, allowing the blocks to be clicked and dragged around, as well as WYSIWYG editing.
You can see the UI of StoryBlok is similar to Volto. However page preview in the centre is an iframe and the block selection and action bar is rendered on top by the iframe bridge and Admin UI.
WARNING: The following will not make sense if you don't read storyblok bridge intro first and storyblok bridge details.
There would be two apis
The following are the levels of integration the integrator would be offered in a final solution.
The key point is that the integrator can do the least effort and get a lower UX for their editors for low budget projects.
OR the integrator can do more work, and in exchange get a better UX.
So they have freedom of choice and Plone becomes accessible to more uses.
Note: All the levels are provided for reference but for the POC the goal is to only concentrate on the riskier parts - Levels 2 & 3 (and maybe 4).
Level 1. Preview reloads via RESTApi (out of scope of POC)
Level 2. Point and click blocks and quanta toolbar
Level 3. Live updated preview
Level 4. Inline Editing (stretch goal of POC)
- The integrator would use a data attribute on a div with rich text in to indicate this text should be made inline editable and where to store the result.
- The iframe bridge client code would then turn this into a contenteditable and send change and selection events over the iframe bridge.
Final code (roadmap)
Volto style customization of building on top of out the box blocks could still be supported alongside the Headless mode.
Volto would be split into two separate code bases designed to be deployed to separate servers.
Addons would now come as three packages, Admin UI, backend/api, and Volto frontend.
Deliverables for GSOC POC
The goal of the POC is to try to get a functional editing experience as possible in a decoupled way but not to produce a polished api or mature code base. The expectation is that whatever code produced would be rewritten based on what was learnt from the POC.
Plan
Additional steps
Risks
The text was updated successfully, but these errors were encountered: