brain trust: talk to me about hosted content?

[cellio]

I've written lots of stuff in a variety of places online -- (LJ to) Dreamwidth and Medium and SE and one-offs in handwritten HTML and (heaven help us) Twitter and probably some others. Some of it was transient, but some of it is stuff I'd like to keep available and together.

I have a domain and the hosting company offers what I gather are standard tools, of which Wordpress is the one that keeps coming up in searches about setting up simple web sites.

My domain isn't empty, but there's not a lot there. I have things with published URLs that need to not get disrupted, but I'd otherwise like to have a web site with some of the basics ("about" page, contact form) and, mainly, this collection of things I've written. I'm going to have to curate the things I've written anyway (I kind of gave up on the idea of bulk-importing 20 years' worth of Livejournal/Dreamwidth), so I don't mind if I have to post things one at a time. I'm going to be rereading them one at a time to decide their fates, after all.

I'd like it if whatever receives my words of (cough) wisdom spoke both HTML and Markdown. I will, of course, want to be able to tag those posts.

I need it to have a time-based archive (by month or whatever). I'd like tags to work as tags and not just visual labels -- that is, you should be able to click on a tag to see other things with that tag. I think all this is "blog 101" and tools generally do that stuff.

I need to be able to easily back up the content.

I don't know what other questions I should be asking myself.

I've read some of the "getting started with Wordpress" stuff on their site, but before I go much farther: will that meet my needs? (I can't tell about input formats and backups, in particular.) What else should I be looking at? What decisions should I be making before I install anything? What's the easiest path that would probably work for my (I think) modest needs?

Update: Thank you to the several people who pointed out that what I need (and the name for it) is static site generator. Further pointers still welcome.

Comments

[dsrtao]

The problem with WordPress is that it is an active system that consults a database and does some calculation to put together any given page. The result is a flexible system with lots of useful modules... with a terrible track record for security and performance. If you go with WordPress, you need it as an actively managed service with a lot of support behind it.

The other end of the spectrum is a "static site generator", in which your content (HTML, Markdown, RST, anything that pandoc can interpret) is rendered into HTML and CSS when you pull the trigger. That produces a site which will have no exploitable security issues (because it's not interactive) and is blazingly fast on very little hardware (because all the computation was already done).

Everything you have asked for is doable in WordPress or any SSG. Take a look at https://blog.randomstring.org for my SSG-created site -- the SSG I use is called Pelican -- which features a time based archive, tags, about page, and so forth. There are services which run SSGs for you, at costs ranging from small to medium, and there are ways of hosting such a thing on GitHub or the like at nearly no cost at all. That last option does put you at the risk that GitHub (or whoever) will decide to drop a free service at some point.

[mdlbear]

Hugo - The world’s fastest framework for building websites

It's a static site generator, so all your content is contained in flat files (which you'd want to put under git control), and all formatting is done offline. WordPress stores content in a database, and constructs pages on the fly. Also it's written in PHP, so you'll occasionally have to upgrade it to plug security holes. There's nothing in a static site that can be hacked.

You might also want to look at Jekyll, which is the static site generator used for GitHub Pages.

[madfilkentist]

I'll add my voice in favor of the greatly underrated static HTML. It's the simplest, most secure, and easiest to back up.

[https://login.ubuntu.com/+id/hsFMttp]

Hi Monica - this is a perennial conundrum in my world. :o)

My favourite "small CMS" (which I've been using for many years) is in a bit of a development hiatus, so I won't suggest that just now. (It's poised to move forward, though, so will update this if it seems sensible, and you still haven't settled on your tool(s) of choice.)

However, Datenstrom Yellow (https://datenstrom.se/yellow/) is a nice half-way house between the "pure" static site generators and a CMS. It is built on just folders and (Markdown) files, with a few very simple management tools to facilitate content production and frontend display. It's been around for quite a few years (I've been using it off-and-on since 2014), it's actively developed (https://github.com/datenstrom/yellow), and very simple to deploy and use.

It tends to fly under the radar, so mention it, just in case some of the better known options are less than ideal for your situation.

Best wishes, as ever, from Edinburgh! David

[siderea]

I'd like to add a caution to what everyone else is saying about "Static Site Generators". When I went browsing SSGs, I discovered a whole lot of them are distressingly dynamic: they're dynamic on the client end, with heavy JS, particularly JS-based Responsive Design (tm) frameworks*. I found it extremely hard to weed out all the ones that don't generate actual, you know, static sites.

Anyways, I got fed up and just used PHP includes to manage my site navigation and handcode my HTML pages in emacs like we were born to.

* https://www.youtube.com/watch?v=Wm2h0cbvsw8

P.S. I feel I should also mention, SSGs are not generally meant for people in shared hosting environments, in that they typically require shell access, and sometimes (often?) require to set up that you have the authority to install programs on the server. Many companies offer SSH access for shared hosting customers on request; whether or not they will be willing to let you run arbitrary code on their server is another thing.