With 8.7 and block editor (almost) out the door, it's time to collaborate on the next steps. Underneath the new shiny Block Editor is a great flexible engine ("Project Proteus") that other property editors can rely on.
This means that we now have two out of three great building blocks for flexible property editors:
✅ Element Types as a core feature for defining data that are not nodes but can utilize (most of) the power of Content Types
✅ Project Proteus, Block-based data structure interoperability
❌ A structured way to store block-based data.
The purpose of the new RFC is to solve storing the data aka the missing brick.
I've outlined the why and a rough idea of how, but the more people who can bring insights, the better and faster we can get to the finish line (especially if we're other than "just" the HQ who can collaborate on implementing the work afterwards 🚀🥰).
New RFC: How to store Element Data
Happy Manic Monday!
With 8.7 and block editor (almost) out the door, it's time to collaborate on the next steps. Underneath the new shiny Block Editor is a great flexible engine ("Project Proteus") that other property editors can rely on.
This means that we now have two out of three great building blocks for flexible property editors:
✅ Element Types as a core feature for defining data that are not nodes but can utilize (most of) the power of Content Types
✅ Project Proteus, Block-based data structure interoperability
❌ A structured way to store block-based data.
The purpose of the new RFC is to solve storing the data aka the missing brick.
I've outlined the why and a rough idea of how, but the more people who can bring insights, the better and faster we can get to the finish line (especially if we're other than "just" the HQ who can collaborate on implementing the work afterwards 🚀🥰).
So help us, help you and join the fun: https://github.com/umbraco/rfcs/pull/24
Love,
Niels...
is working on a reply...