How to set up a blog with Hugo and Cloudflare, and why you should
smaller.fish
smaller.fish
> Wordpress is a mess that keeps on chugging through inertia
This is a weirdly reductionist position.
WordPress is an auto-updating, security-patched, open source CMS with a stable API, an advanced WYSIWYG editor and now layout tool, a reliable REST interface, good hosting support from stable vendors, a highly functional foundation and a profitable owner, etc.
It's really no messier than any other open source CMS (less messy than several), and it has better community and foundation support than almost any open source product I can think of.
It's fine not to like it, but let's not just casually write it off in a blog post about a static site generator that is limited in scope and a single third party behemoth hosting operation; that's disingenuous.
WordPress core is kept up to date by a responsive team. However, while some WordPress users may be content with a vanilla installation, there are many who are not.
A traditional way to add functionality and style to a WordPress installation is to add plugins and themes. These plugins and themes are not sandboxed, and operate with full privileges.
Unfortunately, there are many plugins and themes which do not uphold the standards of core WordPress with regards to security. And the people who determine which plugins get added to a WordPress install are often non-technical users who are not in a position to evaluate the security implications.
The outcome is that while the WordPress core is hardened, typical WordPress installations which use themes and plugins are still a security shitshow.
The only way I can see to solve this architectural/ecosystem problem would be to somehow nerf plugins, or at least themes, analogous to how browsers discontinued support for the old-style fully-privileged browser extensions. For example, themes could be restricted to inert HTML and CSS. But considering how WordPress gets used, this would be so disruptive that I can't ever see it happening.
And therefore, static site generators like Hugo will continue to enjoy a huge comparative advantage over WordPress in terms of security, even if WordPress core has all the positive traits that you lay out.
Very true. But it is clear that WP's broad trajectory is towards GUI-configurable, block layout themes that do satisfy more users. They are doing more on this than any other CMS project.
> A traditional way to add functionality and style to a WordPress installation is to add plugins and themes. These plugins and themes are not sandboxed, and operate with full privileges.
This is true, as is the risk with third party plugins. (Though ultimately end users will just install some other bodgy CMS if they can't get what they want from plugins. The tradeoff with WP is that those plugins receive some scrutiny through vulnerability databases, better educated WP developers etc.)
Sandboxing themes is always going to be a little tricky, but it is plausible (and indeed it's not out of the question to project WP moving in that direction, given the way its internals are being reconsidered around the REST API).
But do you know of any widely-installable, user-friendly CMS that sandboxes its plugins? That is a huge undertaking. It's something I've thought of many times before, but I can't think of a way to make that practical on the sheer range of hosting options that WP makes possible.
[1]: https://blogs.gnome.org/tbernard/2020/01/17/doing-things-tha...
This is a great point - I built a website for a club I go to on Hugo and S3, and it is updated by users going to Forestry.io which then posts changes to Github, which then runs a Github Action which compiles it with Hugo and uploads to S3.
I thought users would be able to get their head around it... nope! I'm the only one that can make changes to the website.
It's still been worth it because of how cheap it is to run, and better for the environment than having a server idling to support our static site, but still a pain that I'm stuck being the one person that can update it.
What are they having problems with? Maybe there's a fix?
* The ability to upload an image and resize it (i.e. someone takes a picture with their iPhone, then uploads it directly, and then cannot resize it within Forestry.io to make it sensible for the page).
* Inserting something like a table becomes an exercise in writing HTML or markdown rather than a GUI action.
* We had a requirement to embed some html in which eventbrite provides every time we have a new event (which gives a 'buy ticket' link embedded to the site for our events, but attributes in the html change for every new event we add to the website). You can embed html directly into the forestry.io editor, however it doesn't work when the html is sufficiently complex, so then they need to edit this particular page in GitHub to add the html in. (Note: using pre-built html blocks in forestry.io does not work for this as far as I can see, as the html changes for each new event). I think this happens when a file contains a combination of both markdown and HTML.
* When creating links, you have to find the relative URL path and then type this in, rather than just clicking on another page in a hierarchy as you would in Wordpress. I know this is a tiny thing - but again it makes users find it more difficult to move when they are used to Wordpress.
Despite these things listed, I do think that forestry.io is fantastic and similar CMS programs are the future - It's just that Wordpress has the edge at the moment. I have seen that the team at forestry.io seems to be building a new product at Tina.io and the forestry.io product does not seem to have changed much recently, so maybe this will start to fill some of the shortfalls.
After each save, they thought something was wrong so would end up breaking/conflicting the process of git commits etc as they tried clicking different things because something was taking too long.
This was a couple of years ago so things may have changed by now.
Amen, and I think this is the thread creator's point — WordPress doesn't have to "lose" for Hugo to "win", and it's pointless to pick a fight with a wildly different solution that solves a different set of use cases.
The thing that bugs me about more or less any article about why static sites are better/easier/simpler is that they all depend on writing off WP as sort of a straw man.
I have been playing with Publii again after being nudged towards it by a HN comment, and I think it might be a useful middle ground:
It's far from perfect but it's kind of cute and fun to use, and definitely easier and more approachable than Hugo.
It absolutely does -- and different criticisms have landed harder at different times.
For us technical folk, Wordpress is a beast that needs to be slayed. For John, the non-technical, world-travelling coffee shop owner, that wants to maintain a simple blog describing his adventures, it's perfect.
(I say this as someone who used Wordpress and now uses Hugo)
- WordPress can be auto-updating but when you update the core files, theme, and plugins, and want to upgrade PHP, there's lots of incompatibilities that can take your site down and cause other problems so it's not set and forget.
- Most sites also require a combo of plugins because core is missing essentials (e.g. page caching, SEO tags, contact forms, image optimisation), where each can give page speed, security, and maintenance issues.
- Dynamic PHP code is inherently less secure than static HTML files e.g. there's been remote code execution exploits via WordPress contact form and caching plugins in the past which isn't something you have to worry about with static sites.
- Versioning, deploys and updates via Git and CI/CD isn't standard practice with the WordPress community either. Plugins that update themselves and write files to the server is the norm which is another source of stability and security problems.
- Configuration being split across the filesystem and the database gets in the way of predictable staging/production deploys and QA.
- When writing PHP theme templates, there's minimal default escaping when you output fields so you have to be extra careful to not introduce exploits.
Static sites are fundamentally more secure, more performant and easier to test by default. There's bandaids to some of the above but you'll be fighting against WordPress standard practices all the time.
I'm still trying to find a good open source WYSIWYG page builder experience here that can compete with WordPress though. Using WordPress as a CMS and a static site generator to deploy it is an option though.
I'm afraid to say I consider "performant" to be a term almost without meaning, but especially here where you just mean "faster".
Any true comparison of performance would have to address the functional things that WP can do that a static generated site cannot do without third party services or serverless functions etc.
What functionality are you thinking about here? I find most business websites don't need much beyond static HTML contact forms, nothing that would need serverless functions. A themed search page is a bit more challenging but you can embed Google Search or something like Algolia. Messaging widgets, analytics are usually JavaScript snippets, same with a lot of buy-button functionality.
For me the primary benefit of a contact form is obscuring its destination (or piping it into a CRM or ticket system).
Search is important. But other functionality includes things like content embargo/scheduled publication. Or multi-author systems, where not everyone who is writing the content should be doing any damn thing with CLI tools or Git or any such thing), and where there might be editorial approval before it is posted.
Analytics: again, this is something that I personally believe should be achieved in aggregate on the server side, not in JS trackers.
Most simple business brochure sites do not need much, but most simple business users like a control panel they can log in to.
I do not have _any_ customers I'd deploy a static site generator to. It's just not going to happen without an online frontend (or something like Publii, maybe).
I got taken by the HN hype over SSGs and moved my site from Drupal (I didn't want to move to Drupal 8) to Hugo. I spent a glorious three weeks porting my site and getting to grips with Hugo hosting my site on Gitlab. As is the case with me I then didn't touch my site for over four months and when I wanted to post a new post I had to learn a few things again. I have a work device and home PC. Posting meant I had to be at home because that's where my pipeline was setup. In the end I just moved to WordPress. I am not a web developer. There are probably smarter ways to setup and post to Hugo but given limited time at my disposal and limited functionality of my site, WordPress just easier for me.
Salesforce HTML form. Netlify HTML forms Typeform JavaScript form. Lots of options: https://jamstacktools.org/browse/all/form. I use this for personal sites, takes 10 minutes to setup: https://formspree.io/
Obviously there's a third party backend somewhere but better than using a WordPress plugin that might have an RCE security exploit or is open to spam at some point. Outsourcing stuff like this can be a good tradeoff.
> But other functionality includes things like content embargo/scheduled publication. Or multi-author systems, where not everyone who is writing the content should be doing any damn thing with CLI tools or Git or any such thing), and where there might be editorial approval before it is posted.
Customers wouldn't use Git directly or a CLI, they would use a headless CMS. I'm not sure which one covers all of the above but there's lots of headless CMS options here:
https://jamstack.org/headless-cms/
> Analytics: again, this is something that I personally believe should be achieved in aggregate on the server side, not in JS trackers.
Netlify and Cloudflare, and others offer this.
But how many developers do you know outside of your own work team who know how to install an AWS Lambda function?
I've been developing a long time and I have Lambda functions in production but the entire process makes me want to bash my head against the wall to the point of unconsciousness.
The idea that we can write off wordpress as bad in one breath and then recommend a "static" site system which is a bunch of HTML pages with a set of specific third party hosting dependencies has always struck me as interesting. JAMstack is a manifesto for dependency on subscription microservice providers.
Maybe that is increasingly a distinction without a difference, though; lots of blogs are now removing their date-oriented URLs (more's the pity)
> I'm still trying to find a good open source WYSIWYG page builder experience here that can compete with WordPress though.
I would be interested to see a static CMS that worked more this way -- Publii is interesting for this though.
> Using WordPress as a CMS and a static site generator to deploy it is an option though.
This definitely can be done, and you could use e.g. the Atlas content modeller plugin and GraphQL and then Gatsby/Gridsome. But it is more work in search of a reason to do it.
Unless bad guys "patch" it first before the official patches are out.
I usually find out there is an official patch when I get an email from a WP installation telling me it has already been installed.
Core WP copes with zero-day attacks better than most platforms. To the extent that they will even mitigate problems in widely-installed third party plugins and themes if they think it necessary.
Sure, there is a paradox with anything popular like this, that the people who are installing it are the people least likely to be able to deal with security patches. And that is an endless source of tension. But it is also why WP auto-patches, why plugin and theme auto-updates are now possible etc.
This garbage was normal in early-2000s web development but nowadays this problem has been solved - just look at any modern server-side MVC framework (whether PHP or others - PHP isn't to blame in here).
Maybe it's indeed "good" at handling zero-days in terms of raw numbers, but maybe it would be better to just not have as many zero-days in the first place?
But it's also entangled with the last bastion of one of WP's most underrated/underdiscussed features: pluggable authentication.
If you mean the appearance of the code: it's not to my taste! But it's actually really heavily governed by code standards (including the Yoda conditions stuff).
WP itself will never be an MVC system, but then MVC is really at odds with the hooks-filters-and-actions API approach WP uses, which again you don't have to like but is crucial to its success.
You can make tiny, targeted changes to the way a WP page renders -- with a single hook function -- that would be hard to replicate in MVC without vastly more effort. Magento tries to achieve this, and does it well, but at the cost of needing dependency injection, XML layout files, etc. etc.; it's enormously more complex.
I personally think MVC is the right thing for app development but wholly the wrong thing for the rendering front end of a CMS site, but I acknowledge this is a contentious opinion.
> rendering front end of a CMS site
If this was a view layer working entirely in a sandboxed runtime, maybe, but it's not - you're still editing the underlying application and can run arbitrary code.
MVC may be more difficult to grasp, yes - I went through that a decade ago when I moved from shitty PHP scripts similar to the code above (but hey I thought I was being smart by hashing passwords with SHA-512 instead of MD5!) to learning a proper framework like Laravel (and eventually moved off PHP altogether). However, I absolutely believe it's necessary otherwise you kill productivity, increase human errors and make code review much more difficult. If it raises the barrier to entry I'd say that's a good thing as it would prevent at least some terrible & vulnerable plugins from being made.
Right, but can you give me an example of a dynamic content management system that fully sandboxes its _plugins_? I can't think of one.
I tend towards telling people that adding a plugin or theme to their site is the same as adding its developer to their project. You have to decide where your risks are. But the flip side of this is that adding third party services to a static site generally involves significant GDPR exposure at this point. There is a choice to be made.
> MVC may be more difficult to grasp, yes
It's not that MVC is more difficult to grasp; I've been building PHP apps like that for 16 years (and before that Rails and Perl). I've never had any difficulty teaching it to other developers.
It's that MVC isn't actually appropriate for the generation of static CMS content at all. It ultimately locks you into a very specific pattern of layouts (with all sorts of ugly solutions to break out of the box).
It may not be a popular opinion but the hooks-and-actions approach to WP is a much, much more appropriate system for the generation of code for a content management system.
It gives you a "nudging the asteroid" approach to plugins, where hooking into one function at the right point in the page life cycle gets you what you want. That is more difficult with MVC -- you inevitably run into much greater design complexity. As I've said elsewhere, Magento has attempted this, and they have to offer several different methods (involving dependency injection, method rewriting etc.) that WordPress does not need, because its page rendering has a simpler functional flow.
NO.
We are spoilt with choices these days for Static site and I'm particularly happy with both Netlify and Cloudflare Pages.
So anyway, downtime is one reason I suppose. Are there others?
I’m fine with that but the lack of error why that is happening was hard for me to assume.
Last year, I moved my site[1] (a pretty heavy content with lots of text files from two decades), and I really like Hugo. It was fast and can compile my site quick enough. Jekyll still crawls but I was ready to live with it as I can just write in MarkDown and don’t worry about compiling every time. However, the downtime was the reason I stopped using GitHub Pages.
OR
There is a way to make GitHub pages to support commenting by default. Currently, it is a pain to run after third party tools for commenting.
Is it so difficult to make already existing commenting feature to work on pages or regular files?
Edit: It is a little slow to build when you make changes. My changes take a minute or two to appear on the site.
Don't really remember what the hurdle with gh-pages was though.
I also recently discovered that all our corporate machines show: "MismatchCert (Hostname mismatch) Blocked by SSL_HOST_MISMATCH" on the Github provided certificate. I can only wonder how many people have seen this and didnt visit my site because of it...
Does anyone have a recommended site/guide to setting up simple static sites without technical heroics? In the meantime, WordPress is a saviour.
I haven't used GitHub Pages. I use Netlify with Hugo and love it. Super easy, never had any SSL issues. I wrote a guide for this -- apologies if this is self-promotion, I can delete this post if necessary -- the link to my blog is in my bio. I don't think this guide requires "technical heroics", but it depends on your perspective, I guess.
https://discord.com/channels/595317990191398933/922968777988...
So you could totally build everyting locally and commit the site into a Git repo and use it in that way. It would be nice to have a non-GitHub way to just shove my built website into CF Pages but I don't know if that is on the roadmap.
Deployments are still painfully slow.
Pages is also missing some Workers features, like being able to see logs, Unbundled Workers for >50ms server-side processes, etc.
You can ask "Walshy" in the Cloudflare Developers Discord and he can give you access to a feature called "fast builds" it's in beta at the moment.
> This tool and the template engine it is using were born from an intense dislike of the (insane) Golang template engine and therefore of Hugo that I was using before for 6+ sites.
Could anyone with experience with this and other solutions weigh in? There are so many of them my head spins when I think about it. I just want something that doesn't make me babysit it (as in, I can write as little code as possible to get a simple static webite) and has the usual things you'd want by default (e.g. image optimization) and is extensible if I do outgrow it and need to add dynamic components.
https://jamstack.org/generators/
Each option lists which template language it uses, license and language it's written in... just pick the option that best suits your taste among the hundreds of options there... they're mostly all great, Hugo really is just one option in hundreds.
...they refer you to the GH's releases page, where you can find binaries ready to use (I don't use Mac, but I see 64 bit and ARM64).
You don't need a Go dev env to use Hugo. I use it in Linux and I don't have a Go compiler installed.
Basically it uses the Go dependency manager to help you assemble your website. Here's my documentation on Hugo modules for my work-in-progress Hugo theme: https://git.sr.ht/~skyfaller/maxethics-hugo#hugo-modules
The biggest ones are being able to organize all my posts as subtrees in a single Org file and leverage the Org mode's inbuilt"meta data" inheritance.
Publishing writing on a blog just makes this information public. I chose to do that since I benefit from the blogs of others, so I might as well make my learning and insights public, hopefully helping someone else too!
1. Opinions you talk about regularly, that would benefit from a well-structured argument you can link people to instead of typing from scratch every time
2. That one StackOverflow post you need every 2 years but you keep losing it because the search keywords are weird
I get 3 or 4 emails a day for jobs without having a blog, so I'm curious to understand how he can tell that his blog is what is drawing the attention.
Also, sometimes, my website is directly mentioned in the emails.
Like others have said, I write for my future self. I’ve been doing so for about 20 years. It’s extremely rewarding, for me, when someone emails me to say thank you. I’ve gotten emails from people saying I helped them lose 200 lbs (yes 200) or save $1000’s of dollars. That’s pretty rewarding.
For the curious, the person who lost weight was using a calorie tracker I built and wrote a blog post about. The person that saved money followed instructions on how to install old software on newer OS’s, saving them from buying a whole new embroidery machine (something I only did because my Mom needed help with her embroidery hobby).
To help myself, as another poster said, I record things I've learned, errors I have fixed, processes for e.g. setting up ssh securely or whatever.
To help others, most of the things that help me also help them. Every now and then I get a really weird error that no-one else seems to get and I have to solve it and then blog about it. Hopefully another 10,000 people don't have to go through the same pain.
At one point, I think I had about 200K viewson my blogspot blog but eventually I just came to hate the fact that they never seemed to update the site or fix any of the bugs on it so I went static and lost a tonne of SEO in the process but that will grow again!
Engineers are often introverts and many can struggle communicating easily the ideas that they understand entirely but which are complicated. Blogging is a good way to challenge that and force you to abstract something well enough to explain it.
I say "for developers" because you'll usually need to write at least some HTML and CSS overlays over the themes that Hugo makes available to do things like add analytics tags or custom footers. This is a slight hindrance for non-devs who just want to generate content. Medium or Substack work really well for this user persona.
(Git is not easy to teach outside of the big three commands --- clone, commit, push. I teach engineers how to use Git amongst other things, and it gets complicated (i.e. let's talk about trees and some other CS things) to explain once you scratch slightly beneath the surface, like "what does clone/commit actually do?")
It has been working perfectly for about a year by now.
We don't use CF pages, admittedly. It's workers sites, due to the ability to publish directly.
I think Medium have even tried to stop people copying and pasting content without an account. That is so anti-internet. Most of the knowledge I have I got for free so the idea that somehow I should charge others for it instead of helping others to go much further than I ever could.
If I host my domain with Njal.la, and have Cloudflare setup as in this post, I should be safe from any frivolous take-down requests, right?
I'm a long time user of Cloudflare, however, when Cloudflare forwarded my personal information due to a DMCA take-down request (even though they refused to act on the actual request, forwarding my personal information was a shock); it opened my eyes to the fact that no one is immune from the bullshit that we call "DMCA".
The best option would be rather create posts in a browser or iPad.
Is there a way to set up a stand alone blog (which is not on “community-linked” content platforms like Medium) that DOES NOT require installing and compiling or even a personal laptop?
Consider using WordPress. There are many hosting providers who offer a managed WordPress option. They manage the installation, hosting and back-ups. The non-technical users simply sign-in to WordPress via their browser to write posts using a browser-based editor. Local installation on user machines is simply not required.
Static Site Generators (SSGs) like Hugo are supposedly 'simple' compared to the complexity of dynamic blog engines. However, the Hugo setup discussed in this thread is much too complicated and defies the meanings of simplicity or easy. SSGs lack comments and even a simple contact form is impossible without a third-party service or plug-in.
Those add a CMS UI for your SSG website that can be accessed for example from yourblog.com/admin/.
Other options would include creating HTML pages on vscode.dev or creating a Next.js site with Stackblitz that is hosted on Vercel or something.
I wrote something similar - https://www.unsungnovelty.org/posts/11/2019/why-do-i-host-a-...
And I hope somebody else will get inspired by these as well! There are a lot of personal blogs still BTW.
And for those who plans to write. Creating a blog is easy. Maintaining it is the hard part. Irrespective of your experience and topics you want to share, just keeping the website and writing is hard. Do keep in mind so that you will prepare well for this. :)
- Netlify
- Heroku
- Github Pages
- Gitlab Pages
- Google Firebase (360 MB/day traffic, plenty enough for small sites)
- DigitalOcean App Platform (1GB/mo)
Perhaps you’re thinking about GoDaddy?
I liked this part. Honest, and shows it isn't a vendor lock-in.
Hugo can be used much more simply and I don't see why we have to use Cloudflare for simple blog. You know you can host it on Github if you want to, or anywhere else.
Their previous CEO killed elephants. This company supported SOPA. They literally use every trick they could come up with to fool people. It’s probably one of the least ethical domain registrars out there.
Just use namecheap, name.com, gandi.net(Amazon domains uses them I think),inwx or anything more ethical.
What a static website lacks is interaction with visitors.
Interaction with other people is the whole point of going on the internet.
Forums and comment sections on blogs is the reason we go on the internet. It's the reason people visit HN. If you couldn't write comments, would you visit the website? Maybe you would, but a lot less frequently. For example, I don't visit the lobsters website because I can't sign up for an account so I can't participate in discussions.
The problem is that setting up and maintaing a website in 2022 is quite cumbersome and tiring. No one wants to maintain a web server with the correct configuration of which versions of which applications are installed, where their configs files are, and what the contents of these configuration files are. Which is what you have to do with any of the existing solutions like Wordpress or Ghost or similar products.
A website should just be a program. A program you run and it manages itself. You shouldn't have to manage it. Programs are for automating things with computers.
In 2022, it's not difficult at all to write a program that does all of the following:
- Be an http(s) server (listen on the http and https ports and implement the http protocol)
- Manage its own data storage (database as library, not as a separate program that needs to be setup and configured separately).
- Manage the acquisition and updating of certificates for https (thanks to the ACME protocol and Let's Encrypt)
- Handle thousands of concurrent connections on cheap hardware (about $5/mo) without breaking a sweat
- Manage its own installation. For example, the user need only run a program on his own computer, give it the IP of the server he wants to host the website on, along with root username and password, and that program will do everything necessary to setup the website program and install it on the server. It should not take more than a few seconds (less than 10 seconds, and that's being very generous with time).
I'm not sure why no one is working on such a thing. It seems like a very low hanging fruit.
I suspect that people look at the current landscape and see that users prefer managed solutions like Substack over self-hosted solutions like Ghost, and they conclude that no one wants to self-host their own website.
I think they are wrong.
No one wants to self-host using any of the existing solutions because they all suck in that you have to sort of be a sysadmin in order to self host.
People think this is a fundamental properly of self-hosting and don't realize it's just a coincidence that all current solutions are like that but that things don't actually have to be that way.
This is also possible with other static site generators like Hexo and Jekyll.
The whole point of the exercise (doind static websites) is to own your data and make the internet more decentralized like it was intended to be.