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.

[cellio]

Ah! Yes, thank you. I don't need dynamic content and the vulnerabilities that come with it. I want to post static content, which can have links back to DW or Medium for comments. I was not thinking about "static" vs. "dynamic" when doing searches.

Ironic story: in 1995 I was working for a team that was doing micropayments via the web. Well, that was the idea, anyway. So we had a web site with a lot of static content (about us) and infrastructure for merchants and some other stuff. When I got there, all that static content was being maintained in individual HTML pages, including all the boilerplate stuff like page headers and nav buttons and stuff. When you wanted a new page you copied an existing one and edited.

Ok, it was 1995; there wasn't much in the way of tools and CSS hadn't been invented yet. This worked ok...until someone wanted to redesign some of that boilerplate, and every page was going to have to be edited.

I said "yo, there is an easier way", and built a minimal generation system that would do what we needed. It took inputs for page header, page footer, and the actual content. When we wanted to change the boilerplate we edited or added one of these templates. (Different sections of the site had different requirements, so there were several templates.) What I wrote was really simple-minded -- nothing dynamic, just concatenation and wrapping the standard HTML stuff around the output. It was a static page generator. :-) And I had completely forgotten about it until now.

[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.

[cellio]

Thanks! Hugo looks pretty simple (from looking at their quick-start). Yes, I would want to manage content in git. I take it I can use Jekyll without being dependent on GitHub -- that it's what they use, not part of their ecosystem?

[dsrtao]

Yes. Lots of people looked at Jekyll and said, "I can do better than that."

https://staticsitegenerators.net/ lists 460 SSGs right now. Try sorting by stars in the lefthand column.

[mdlbear]

Right. Jekyll is written in Ruby. There's also a clone written in golang, called gojekyll -- it's faster, and because go produces a statically-linked executable, you can compile it at home and upload it to your web host (which is exactly what I did for https://computer-curmudgeon.com/ ). I think Hugo would have been a better choice, but I started with a GitHub Pages site, and it seemed like a good idea at the time.

[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.

[cellio]

Thanks! Static HTML is what I want; I just didn't think to distinguish between static and dynamic, nor did I notice that things like Wordpress are all about dynamic content.

[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

[cellio]

Thanks David -- I appreciate the tips! I'll take a look at Datenstrom Yellow.

I hope you're doing well! I miss the old days of hanging out digitally together.

[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.

[cellio]

Love the song! So true.

Thanks for the heads-up about the loose definition of "static".

Can you say more about "used PHP includes to manage site navigation"? I've been editing HTML by hand in emacs since 1993; I don't mind doing that for my undemanding content here. I just don't want to have to wire up indexes and month-by-month archives and stuff by hand -- need automation there, which I assume any sane person going down the "edit the HTML yourself" path would need and so this should be a solved problem somehow.

I have shell access on my shared hosting server, but don't know what I can run there. On the other hand, I could generate content on my desktop machine and then FTP it there, which lets me test it out locally before deploying. What things about that might make me sad?

[siderea]

On the other hand, I could generate content on my desktop machine and then FTP it there, which lets me test it out locally before deploying.

I was just coming back to say that, yes; or better, use rsync (encrypted, and, well, you want to take down retired/moved pages on site publish, so not sure if FTP will do that right for you).

What things about that might make me sad?

Doing it that was has the apparently nice feature of your local version is a draft, and the version you send to the webserver is the live, but note this is a staging/prod system with the same potential problems:

• Out of syncness between what you're editing and what's on the server.

• Things working differently on the two different OSes involved. WARNING: case sensitivity in file names on Macs works differently than on Linux, which has bit me and others who have done staging/prod of HTML. (I don't remember the deets.)

[siderea]

Can you say more about "used PHP includes to manage site navigation"?

My architecture:

Every page is named "index.php". It resides in a directory that gives it its identity, e.g. "/about/index.php".

The ".php" suffix makes Apache run it through PHP before serving it. The "index" means it's the default page for its directory, so "/about/index.php" is what serves as "https://mydomain.tld/about/".

Every page opens with:

<?php
include '../inc_header.php';
?>
<body>

<div id="nav">
<?php 
include '../inc_nav.php';
?>
</div>


<div id="maincontent">

inc_header.php is just my invariant HTML header.

inc_nav.php has the logic for the navigation, which is hardcoded:

<?php
    $currentpage = $_SERVER['PHP_SELF'];
    $currentpage = explode('/', $currentpage);
    $temp='';
    foreach ($currentpage as $dir) {
        if (preg_match('/\.php/', $dir)) {
            next;
        } else {
            $temp=$temp . $dir  . '/';
        }
    } 
    $currentpage = $temp;
    # print($temp);
    
?>

[a bunch of attractive HTML goes here]

<p id="nav">
		<a href="/" <?=($currentpage == '/')?'class="currentpage"':''?>>Home</a> 
	| 	<a href="/contact" <?=($currentpage == '/contact/')?'class="currentpage"':''?>>Contact</a> 
	|	<a href="/about" <?=($currentpage == '/about/')?'class="currentpage"':''?>>About</a> 
	|	<a href="/location" <?=($currentpage == '/location/')?'class="currentpage"':''?>>Location</a> 
	</p>

Everything else is just HTML.

Obviously, this isn't even dynamic enough to figure out about new pages, itself; I have to add each new page manually (if I were to add one). I could make it "smarter" and have it interogate the OS, but this quickly comes back to the fundamental problem SSGs exist to solve: where do you park, and how do you manage, page meta-data, like "what is this page called by the humans, as opposed to the OS" and "does it have a date associated with it" and "how shall it be indexed/cross-referenced".

[cellio]

Thank you very much!