Thank you for the kind words. RSS and dates will definitely be needed! I can also see myself wanting to embed shaders and web games in the future... hopefully without increasing the complexity too much. I think your blog is perfect!
Cache plugins still go through the PHP interpreter. I'm under the impression there still isn't anything faster than serving HTML files.
Better is use a static site plugin, then you don't have to bother with configuring any caching or external services.
Best is also use the SQLite Database Integration plugin, so the server doesn't even have to run MySQL/MariaDB (other than initial installation), and on an otherwise light server, the filesystem will effectively keep the site in page cache while using less memory, if I understand that correctly.
The WordPress interface can be kept behind HTTP auth or client cert.
> Cache plugins still go through the PHP interpreter. I'm under the impression there still isn't anything faster than serving HTML files.
Several WordPress caching plugins, like W3TC (https://wordpress.org/plugins/w3-total-cache/), actually add rules to your Apache/Nginx server so that the cached HTML pages are served statically without touching PHP.
Thanks! Yeah, I find this a lot easier. And yes, hosting is an exercise left to the reader :-) I might write about my hosting setup in an upcoming blog post.
• Trailing slashes in HTML content (apart from SVG/MathML) are completely useless, unless you’re serving the document in XML syntax (which you can’t do by accident). I personally think they’re harmful, because they encourage an incorrect belief, and are seldom even applied consistently.
• <html>, <head>, </head>, <body>, </body> and <html> are all optional. In practice, you should have an <html lang> attribute so that you can’t omit that tag, but the others can normally all be omitted.
• In case-insensitive things, lowercase will normally compress better. But Brotli messes things up because it’s a popularity contest of the HTML that people actually write, so that <!DOCTYPE html> compresses better than <!doctype html>, and even <meta charset="utf-8"> compresses better than <meta charset=utf-8>. Anyway, <meta charset="UTF-8" /> would be better as <meta charset="utf-8">.
• In <meta name="viewport" content="width=device-width, initial-scale=1.0" />, the space after the comma, and the .0 in initial-scale, are unnecessary. (In fact, in theory the .0 might not even be parsed: the badly-incomplete-and-extremely-dodgy spec says to use strtod, which is locale-dependent, so a French machine might parse initial-scale=1.5 as only one, ignoring the .5 because it’s not ,5. In practice I’d be mildly surprised if browsers used the real locale-dependent strtod, though I haven’t checked. If some spec somewhere says “assume LC_ALL=C in such cases”, which would also largely resolve the problem, I’d like to know.)
All up (and with title fixed to be a proper placeholder, as discussed):
Kind of not /s, there’s currently no way to escape the template tags to make them appear in the output (except adding invisible Unicode characters or so).
Since RSS is a pretty simple format, it doesn't require any automation, just a little copy and paste. "Handwriting your RSS feed"[0] makes the case for doing it that way.
The difference in taste of Jolt is too large to be attributed to only caffeine and beet sugar.
While it's not open source, there is a successor to Jolt Cola in Germany called Volt Cola. It's supposedly the same recipe as Jolt, except it has more caffeine. Jolt was too long ago for me to compare the taste, but it's good.
Yes! I find the easiest way for me is to just open a new tab in my code editor and typing.
Exif is a real gotcha. I'm planning to compress images anyway, so this could be done in the same step.