Seems like the right thing to do for most CMS type situations is something that generates the site offline... and only uploads a static site to the web.
Something like jekyll or something.
Something like jekyll or something.
However, I see a couple of problems standing in the way of more widespread adoption of static site generators:
1) I've never seen a static site generator that non-technical users felt comfortable with. Programmers like terminal interfaces. Your average user in 2018 has probably never opened the terminal.
2) Possibly even more significant, I don't think the people making the choice to use a CMS for a simple business-info or blog site are aware of the trade-offs that they're making, or of the benefits that a static site will provide down the line. For a lot of small business owners I've spoken with, Wordpress is basically synonymous with "web presence."
I wonder if there's a market for a web-based GUI like what Wordpress provides, but which runs jekyll under the hood and uploads the files to s3 or something like that. Is this what companies like Squarespace and Wix do?
(disclaimer: Netlify employee)
That said, it didn't help that you don't support Gitlab, which is where all my sites are, and which is the more important reason why I couldn't get it to work.
We (Graphia) took a similar approach for our document management system. Essentially it looks and acts like a regular CMS but it sits on top of a git repo instead of a database; and publishes via Hugo.
It's not intended to be a fully-fledged CMS but the API would support it without much work; the UI is definitely the time consuming portion.
http://www.graphia.co.uk for anyone who is interested, not quite ready for prime time just yet. Soon.
Feel free to ping me using the contact info in my profile or at @benaiah in our Gitter room (https://gitter.im/netlify/NetlifyCMS) if you're interested in discussing this elsewhere.
Imho if you are really wanting to write a blog and host it yourself, this should not be too hard to learn. Wordpress doesn't install itself automatically, either.
We also have a pretty neat solution for site generation/hosting (JekyllPro) which is rolling out next month.
Using these two, none of the contributors realize they're using Jekyll. It's not as user-friendly as Squarespace, but it's pretty darn good.
1: https://github.com/Wiredcraft/jekyllplus
2: https://wiredcraft.com/blog/the-new-starbucks-cn-website-bol...
I remember having to purge front page extensions off many a server. Cathartic feeling that one.
Forestry + Netlify + Bitbucket is a good combination.
I would work on this if I wasn't already running another startup.
I spent a lot of years working in tech consulting and did a lot of CMS integrations. We desperately wanted to push clients to Contentful and away from ornery beasts like AEM, but Adobe can sell AEM by saying it's part of the "marketing cloud" and that it's magic power is in user engagement and analytics and whatever other marketingspeak lies. Contentful was the developer favorite, but it was hard to convince businesses it was in their best interests even though it totally was.
That's not only the same gnarly problem as cache invalidation but with a metric ton of filesystem writes on top of it.
There's also Netlify CMS, but I haven't done much with it. I think the GitHub requirement puts people off, and work on the GitLab--which has free private repositories--support issue is slow.
What we need is something like Publii that's not packaged in a way that's obviously meant to make closing the source easy. That story is too old, and too common, to believe their intentions are good.
That said, back on subject:
Look, this is the main reason you devs tend to hear disdain from us sysadmins when we hear you want to run some new webservice in whatever language fad of the day (node, python, perl, php, asp.net, ruby, scala, go, etc) instead of generating files with your app that can then be serviced to the user using the tried and true tools (apache, nginx, hiawatha, haproxy etc) that have had sometimes decades of public internet exposure to claw thier way through.
Ah, but what about $functionality. Most webdevs think they need a scripting language backend when they really don't. There are uses for it and it has it's place, but it's been way overdone.
Relevant discussion: https://groups.drupal.org/security/faq-2018-002
Sidenote: I think everyone should check out hiawatha webserver, over at (https://www.hiawatha-webserver.org/). Hugo wrote it with security in mind and it by default addresses many things that no other webserver does. It's also gplv2 (which is a big deal for me), and it's performance is second to none. I'm not a big php person, but if I were to be doing a webapp where a backend like that would be needed, I would probably try to go PHP-FPM with hiawatha(mbed TLS)/haproxy and a really nicely hardened boxen and edge firewall(you are using nftables now right?).
I'm on mobile but a quick ddg show: https://www.hiawatha-webserver.org/weblog/64
I used to work a LONG time ago for a company that built Yahoo Small Business ecommerce websites. They used a tool called RTML ("Robert T Morris Language"), which was essentially HAML, powered by Perl, and constructed using a GUI (no text editor interface). Select where you want a node > New node > select node type > Save...each action was a full page load. The process was excruciating, and I was in charge of developing tools to automate the upload of "template" files from the developer's machine to the client's Yahoo Small Business store.
At the end of the day, the customer would load up all their goods into the Yahoo database and hit "Publish", at which point a multi-hour job would kick off to run their RTML against the database. The result was a completely static ecommerce website. Only the cart/checkout pages were dynamic, and those were using shared code.
The development process was a nightmare. The client experience was really bad (want to fix a typo? You're going to wait a couple hours). But I'll be damned if it was possible for anyone to hack those things. There was nothing to hack.
Turning that CMS into a distributed publishing platform is tricky, but scaling static content is easy-mode from top to bottom.
Funnily enough, having worked on all kinds of websites for the past 15 years, i'm still at a loss when asked what the all-round good solution is.
To further complicate things, things change. A website that was a perfect fit for a Wordpress template easily grows beyond that. And a site that seemed ideal for a custom Django/Rails backend might eventually settle into the kind of functionality groove where you begin to wonder if an off the peg solution might not have been a better idea.
Is there significant overlap in their functionality?
You know it's all trivial garbage...except if you want to replace it you need to support it, train them to use these tools and at every point you're going to encounter this resistance about WHY you're doing it and you say well security and speed and they're like it's fast enough and we've never been hacked.
So until the site grinds to a halt and they get also get hacked they basically view you as a blocker.
Static site generators are simply a file-system caching layer. Drupal used to have one of those and it was a terrible idea as the number of page variants on a commercial site very quickly hits file-system limitations and performance is appalling. Better to use a proper CDN for a similar result but with massively reduced latency due to content being served from the edge.
Most websites are mainly read only anyway. No need to throw in a programming language and store the data in a database.
The thing is, non-tech savvy people should be able to use(and deploy) and understand the static-web generators.