I don't know anything about GSoC and the following is certainly not a topic as such, but one feature that Plone really lacks is the ability to easily change the favicon of a site!
Just an idea but perhaps a tutorial/changes to make plone an attractive free JAMStack solution, ie free tier heroku and netlify?
Context: if you look on fiverr for $100-200 you can hire someone to take a custom design, convert it to gatsby or nextjs, put it in github and deploy to netlify free tier, install strapi on heroku free tier and wire that into gatsby such that you now have a custom CMS backed site that scales with no ongoing costs.
They key point of this is that stapi loads on demand on heroku such that you only pay for time you are editing which for small sites is very seldom so you never pay.
In theory this could be done with Plone perhaps with the right tutorial?
We already had gatsby integration perviously, does this work with plone 6? Do blocks give too much control to the editor to as make this kind of simple site too complex to make and if so what switches could there be to lock it down to make that theming (and connecting CMS fields to content on a page) as easy as it is with strapi?
Plone might be a little slow to load but perhaps it could be made faster?
Tutorial should sell all the extra you get with Plone while still being as easy to integrate as strapi is.
There are some little touches that make this whole process flow more smoothly. Like that strapi lets you create links to send for users to set themselves up without needing any email hooked up.
I guess this is what GitHub - tkimnguyen/plone-in-a-box: An easy way to deploy a cloud server running Plone. Definitive repo is now https://github.com/collective/plone-in-a-box is partly trying to do @tkimnguyen but I notice the options there didn't include heroku or any other system that gives you on demand loading?
here there are past GSoC proposal, maybe there's some useful idea.
it's on the ay: add favicon by talarias · Pull Request #3389 · plone/Products.CMFPlone · GitHub
fee free to review the comming solution.
I think we had Plone on Heroku already via a button from some repositories.
In general it works, i think the limitation there was the number of rows in the database. Which leaves you with some space for a small site for free. But I'm not sure if this would be the right target audience. Plone makes more sense when you are not building a very small and flat website. Otherwise things like Strapi are easier and probably more flexible.
We should target more into the contentful direction and get the users who have higher needs, that Plone is a good fit for, hierachycal content, workflows, permission, content rules are coming in mind.
I aggree, it should be easy as possible to use Plone in headless mode. But even more important is the frontend connections part. Only when it's easy to start with a lot of frontend options, people will consider it.
For example if i want to use 11ty for the Frontend/SSR, it should be relatively easy to have a start where i already have the main content importable there and also some recipies to archive special needs.
Yes, for a while I had the Heroku button on the Plone.org download page but it wasn’t maintained as consistently as it needed to be featured, and I always found it took minutes to load up on top of being crippled.
I want people to have the full experience of Plone so a real VM that can store lots of items and they can choose how much power and space to put behind it.
This is what @ebrehault and I started trying to set up in Sorrento: a service for which you register, you provision a Plone backend site to be the headless CMS for a front end you select and connect, and a choice of front ends. That was when Contentful was making waves, as reminded @ericof at his 2016 conference talk
Actually, headless CMS providers like Contentful or ContentStack do not provide a fully-featured library for each big frameworks.
Either they just have an API (classic REST or GraphQL), either they have a framework-agnostic library managing authentication and easing the API calls (and then that's on you to wrap it in an actual service working in your frontend framework).
So it tends to show having a lot of frontend options is not key to have a successful headless CMS offer.
I think history has proven time and time again that the small guys become stronger and take over while the large dinosaurs die out.
Wordpress beat all old style CMS and gradually became able to handle bigger and bigger sites. And now strapi and JAMStack are eating into bottom end of CMS market out competing wordpress. That gives them room to move and Plone less.
Contentful is SaSS. So it's easy to get running. In the same way as paying someone on fiverr to install strapi is easy to get running (or the heroku button)
But if plone could scale the way SaSS does then someone would already have made it a contentful competitor. Reachtecting Plone to work well as SaSS would not be easy.
And then you'd also be cutting off its biggest strength which is its extendability.
That's a shame. Cutting out unneeded objects in a plone site to reduce rows and unneeded code to speed plones load time doesn't sound something that's easily achievable. maybe guilitina stands a better chance
Timo seems to support workflowmanager for GSoC
I have 2 projects where bulk editing is a nice to have feature, but it was always postponed because of budget and time.
The idea is as follow:
Users are able to select multiple content items (like in the folder contents view, based on a query) for bulk editing or actions. Some of that already exists with folder contents, but the search has some limitations here. Users would then be able to change multiple fields/settings on the items at once, not just title and id. Possible actions would be workflow (already exists), move to specific folders etc.
Another action would be to change the type of content items. Background: I’ve had projects where editors start with default content types (e.g. Document), but then need more flexibility or specific fields to index data for a custom search. We then created the new content type (sometimes TTW), but the editors would now have to migrate all existing content to the new type. It would be more effective if we could migrate the selected items to a new content type, and having a configuration screen for the fields (like when changing a workflow for a content type), so
field_a of the old content type becomes
field_b of the new one.
I love it! It should of course be called Mass(mann)-edit
I don’t think we need to rearchitect it: I used to have hundreds of sites in one Plone install
but if you stop and think about it, there are a large number of sites, even with lots of content and editors, that don't get updated every hour or even every day. I would say the vast majority of my gov clients don't update their sites daily and some not even weekly I'd guess.
Once you consider this you realise that having 1-3G of ram always on to run the CMS is wasteful and not really needed. Unless you are having integrated apps, extranet functions then very little in a normal site requires a live backend. Search is perhaps the main function you need a live backend for and there are other ways to solve this. And maybe a contact form, but also not hard to solve in other ways.
So any CMS that only runs when you actually need to edit something is going to have a fairly big cost advantage. and security advantage and rendering speed advantage. Hence why jamstack is getting so popular.
You can argue plone is not attractive to those kind of clients/sites but eventually something that has the permissions and workflow models and the other things plone has, will come along that is fast loading and does work with netlify.
I can also see it as an advantage for existing integrators like myself because we could drop the costs of hosting significantly, at least for 50-70% of my clients. if plone can start in 20-30s and I train users that logging is a little bit slower as it has to "warm" up then they there is very little difference from their perspective.
For a client project I've written a form that supports bulk-editing of any content. It is constrained to Bool, Choice, List, Tuple and Set fields because editing text, files or relations made no sense in the use-case and UI that we created:
If anyone is interested I could try to open-source the relevant code. It supports Plone 5.2 and 6 classic.
I am glad to see we already have a bunch of ideas here!
If some people here think they could be a mentor for one of these ideas, let me know (just post it here or send me an email at firstname.lastname@example.org if you prefer)
If you are new to mentoring GSoC project, let me tell you a bit what it is about:
- you are involved in the candidate selection (so it is about reading the different candidacies and making a choice)
- you support the selected student during the implementation (unblocking them when lost, making sure they progresses well and in the right direction, etc.)
It is not an heavy extra workload, and it is usually very nice
If you are not sure, I will be happy to discuss it with you, just let me know!
rearchitecting in a sass (isn't it "saas"? as in "software as a service") fashion, is something i chew on for a while now - theoretically.
in my head (call it brain fa*ts, for better terminology) are things like:
- compositon/configuration of your project via webui
- an option to move that config/setup into my own cluster (cloud or on prem)
- (micro)services to split applications apart into simpler topics (ddd would be a thing)
- canary deployment for less sweaty hands during adding/updating new features
- modularization of frontend (module federation might be of help)
- message broking between services (async/decoupling)
- event sourcing as a source of truth
- ttw development of ui components, content types, layouts, ...
i like the idea of having a "project" consist of a defined set of services, talking to each other via (a) message broker(s), being tied to security on service mesh level instead of each component implementing its own.
adding/updating/removing services (aka features, aka plugins/addons) without restarting the whole server and getting closer to a orchestrated set of services, in which parts can spin up/down when ever needed and only using resources when in use and therefore only create cost then.
there is lots more, but such a complex topic... and i've run out of buzzwords - sry for that
i don't think it fits gsoc ...
too much? i fear so
too crazy? i hope so
Make Plone a CalDAV server.
did @pbauer ever read this?
much snap, many import-export, such migrated, wow done!