@sneridagh I think the only time that works between asia, americas and europe is 3pm central europe time. Thats 9pm for me and 9am for @pigeonflight. This time is fine for me (11CET is also ok though)
I have a meeting from 11 to 11:30, so I will miss the beginning of the meeting.
(3pm works for me)
That's 5 am here 
Ok, sorry for not coming back to you before.
Let's try it at 15 CET then as a test drive. I might be a bit late (lunch time here) but I'll try to make it. Is everybody ok?
I'm ok with 15CET as well at least as a test trial
Sure. Where do we.go?
Discord?
1 Like
You've made so much effort to accommodate us. Not sure how much perspective I have to contribute at the moment but I'll be there!
Key ideas I came away thinking about from the discussion (not absolutely headless related):
I see opportunities for adding value and improving the overall experience by doing the following:
- make it easier to modify layouts
- make it easier to create and customise components
- explore editor offerings
- make it easier for newbies get started
My general use case is that I want to be able to work with less skilled or less experienced devs. Right now, there's still a "Volto tax" involved in customising the layouts and components, even for experienced React developers.
@sneridagh if you're looking for a Persona to describe this, I'd call "The distracted developer". Their goal is to quickly customise the interface and experience, on behalf of the customer.
I hope this can stimulate some ideas. No idea if this has any consequence on the headless discussion though. I also, haven't properly captured @djay 's ideas here.
This is the use case for a decoupled editor to join plones headless CMS offering.
They don't have to learn the volto way but instead next.js or something else.
1 Like
We use headless plone with our own React based frontend.
Our perspective of interest is not the CMS part with focus on content editing (with external views), but more the IT-platform headless plone where all 100.000+ users edit.
An example problem we needed solve (and have solved) was how to handle 100.000 users efficient.
In the client side code working with Error Boundaries for efficient error handling was one of our main efforts.
2 Likes
@nielssteenkrogh Thats very interesting.
So for editing you are not using blocks but just using content type fields? or you are using blocks but just the inbuilt ones and and training your users that in the edit UI the blocks don't look like the final page?
An example problem we needed solve (and have solved) was how to handle 100.000 users efficient.
In the client side code working with Error Boundaries for efficient error handling was one of our main efforts.
Plone normally deals with this by the user setting of "many users" and "many groups" and often by using LDAP or other plugins that are better at handling large numbers of users. Those settings are meant to change the UI to use search instead of listing out users and groups.
However I have noticed that these settings don't prevent all users being listed out in certain parts of the UI so those parts will then be impossibly slow. For example the User Groups management page.
But if you found and fixed those bugs it would be good if you raise those bugs in github or list them here so they could be fixed for everyone?
Our usecase very different to what is normally the case. What we do is having 100.000 users answering questionnaires (React client side connected to Plone API extended with supplementary post and get services).
The resulting content (answers of questionnaires) is saved into JSON fields in MySQL and then importable by professionals evaluating the answers and taking decisions based on advanced presentations of the data in a Plone classic GUI. Here the presentations is not documents but advanced views and z3cform widgets and dexterity content types for documenting the decisions.
Related the userhandling what we have is personalid from external national login-systems. This we need map into plone user profile where userid is a UUID and the personalid is a property.
For having needed speed in lookup of the plone user (simple plone member of a group) we added index in mysql in front of the plone members so we know which UUID to use (instead of going though all 100.000 members looking for the property with the persinalid). The Plone users and the Mysql index in front of it is maintained by subscribers in the plone clasic where the 100.000 users doing questionnaires are created by the same professionals doing the evaluations and taking decisions.
With 100.000 members this approach brought us from from 2-3 seconds for a plone api call to near nothing.
@nielssteenkrogh yes it doesn;t sound like a typical headless CMS use case.
In terms of the problems with large numbers of users. I do think a feature is desirable to put an index inside plone to handle large numbers of users. However the normal way this is dealt with is to use an external user storage like LDAP or mysql and those will have fast search for large numbers of users.
Plones default user storage just isn't designed for large number of users but that isn't documented well.