Let’s think it the other way round - from dynamic to static, this is a trend which i understand and it would be handy in many situations.
It’s just an idea on how to make Pinegrow more popular, without reinventing the app.
Let’s think it the other way round - from dynamic to static, this is a trend which i understand and it would be handy in many situations.
It’s just an idea on how to make Pinegrow more popular, without reinventing the app.
The main reason behind the rise of static sites is undoubtedly that people simply copy and paste and think they’ve built a website – because, to all intents and purposes, that’s what it looks like. But then there’s the aftermath: the maintenance, and everything else. The image I had formed of this new product went beyond a simple converter – I envisaged TreeCMS – a Pinegrow engine that lives in the cloud and can be linked to the developer’s app and allowing the client to access their own dashboard. A simple, modern database for managing content, turning this into a modern service right on trend. The big difference, however, should lie precisely in the simple management of content – just as is already the case with components and the internal CMS, but taking it to a level of management that is more accessible to everyone. It would be very useful to find solutions within the app that allow Pinegrow to function as a builder similar to the well-known ones – but on a static basis. I think the structure is already there in some way; with a bit of good marketing, it could take off – or is that just an oversimplification?
So more like an in-browser content editor? Definable zones etc, that a user could login and modify content. Maybe managed by a flat file system?
I have tried couchcms, pretty basic simple, but it gives you the ability to add editable areas. It is meat for tiny project…
Hi Pete! Yes, what i meant with the CMS system is something that might cover the most basic and natural need of a simple website owner should have, some simple tables for common info, that’s it. It is meant to serve people, as Pinegrow advocate since the beginning. Not sure if it’s the case to give to the client so much ability to modify event the aspect - i’d rather keep them in the sandbox with some safeguards and roll backs. It’s more of a business model rather then a change in the app. That way, people who work with Pinegrow, will see a smooth adaptation of what they used to see, plus, the ability to manage a sort of static site generator integrated and connected to TreeCMS - the portal where clients signup, do stuff, call you.. :- )
But i’m sure that at least once, the team has thought this - maybe it’s a bigger issue than i immagine.
Hi Red, i’ll have a like into it - so basically Pinegrow was connected to the cms, and the client could do the basics i described?
basically you design your website as a complete static site in pinegrow and then configure couchcms and add editable areas. Then you have edit content via web browser.
also check at https://www.surrealcms.com
Will definitely look into it, thank you very much!
I have been experimenting with Directus, and their visual editor does something similar — https://directus.io/docs/guides/content/visual-editor/frontend-library.
If the page is an SSR site, then the updated data is automatically read from the CMS, server-rendered (think - typical WordPress flow), and served to the client’s website.
With SSG, an update means a re-build (with updated data) of the static site is triggered and has to be auto-deployed.
Here is a static site that I test-ran on my Coolify instance hosted on Hetzner.