Static sites are nice from a deployment perspective, but CMS's make a lot of things easier than static site generators do. Seems like there's room to have the best of both worlds.
thank you, that was my experience too.
as a web developer, my primary concern is the users who provide content for a site (including myself).
i have only actively worked with hugo myself and i was disappointed by its complexity.
there are only a few situations where a static site generator is helpful.
one is a distributed team of teach-savy volunteers. here it means that i can submit occasional changes to a site as a patch.
however, the group of people that will benefit from this is limited. and the benefit does not come from the fact that the site is made with an SSG but that the content is stored in a text based revision control system. the friction in such a situation is access control and not deployment. one could easily imagine a dynamic site that pulls its contents from a text based source and still get the same benefits.
It doesn’t have a front end for authoring pages, styles, etc, but that could be built on top of this library.
After creating a site you start a local server by executing "lektor run" in the local folder, then preview the site in your webbrowser. There you get a edit-button whivh opens a backend with which you can edit the website. From that backend you can hit an upload button which allows you to push the static site directly to a remote (e.g. via scp).
Multilanguage support works quite good as well.
On the surface it seems like a pretty roundabout way to work, but the static generation side of things works well. Not quickly (well, not Hugo-quickly).
They tried to convert the base to the mainstream PHP framework called Symphony - but there is still too much "PHP Think" in the code, lessons of modern web development never learned, abyss of bad practices.
Also Symphony is more of a joke copy of frameworks from other languages, e.g. often security problems in auth code after many years of development, like the coders simply do not understand what they are doing - you should not rely on that as a base. People speaking of Symphony as a "quality framework" have not worked in different IT areas or with different languages most often - it is mainly a small group of french developers that depend on the popularity of Symphony and keep up a cult, but it is still a joke.
If you are a customer and somebody is offering you a product based on Drupal, save yourself some horror.
Good people simply have left the PHP world a long time ago and moved on to different languages and frameworks. What you get today as "PHP Developers" is the underdogs, the people, that can not get good jobs with better quality work experience missing, mostly people from the global south or eastern europe that have been misused for many years by companies that wanted to save a lot of money on "cheap coders" to sell bad products.
Wordpress is still no shining example of good PHP, but somehow the company Wordpress managed to establish a not too bad ecosystem, still miles ahead of what Drupal is - so if you are forced into PHP, Wordpress with near to zero plugins plus the great static export plugin will give you best results.
I quite liked it but development tailed off after a couple of years so I imagine it failed in the marketplace.
[1] https://www.joelonsoftware.com/2001/10/12/what-does-citydesk...
[1] http://runtimeterror.com/devlog/
[2] http://runtimeterror.com/pages/badsector/nyan/gimme/cdsite/
The whole template problem, along with customization (or is it configuration?) is the biggest blocker for me. I'm going back to a straightforward Markdown-like to HTML generator for my next blog revision.
A few years ago I wrote a static generator for Ghost. The workflow was the following:
- A Ghost instance runs on my raspberry pi
- I log into it to write content, and save
- A hook is triggered by the content update (this is a native Ghost feature), that sends an HTTP request to a local ExpressJS instance
- A script downloads the whole dynamic Ghost site as static files, fixes the links, and then publish them somewhere
It was _very_ brittle but it worked for my use case.
Everything was generated on the server but only static pages was served to visitors.
How you generate the content is a separate question. It's quite common to use WordPress as a CMS (because the content people already know it), and then pull the content in to something like 11ty or Gatsby to bake to files and put on a server.
I currently use pelican since i'm ok drafting my stuff in markdown...but I used to use lektor alot...and every person - techie or non - that i've shown Lektor (back when i used it myself) loved lektor! Since that time i'm sure there are other SSGs that operate like lektor.
You have one Wordpress instance completely internal, safely hidden behind a VPN, get all the convenience of Wordpress, and each time you publish a change in an article it will publish the static site.