Day 6
Our update today is a bit more on the modest side, but still somewhat useful. You can now easily create custom HTTP response pages, and also use them however you like.
“Custom HTTP response pages” is a bit wordy, but to simply call them “error pages” would be doing the feature a disservice. Sometimes you just need to respond a certain way, you know? And it’s not always an error.
Anyway. Let’s dive in.
HTTP responses
First, let’s talk about why you’d ever want to use this. The main use case, I think, is what we’d call a “custom 404 page”—what you’d want your visitors to see if they try to view a page on your weblog that doesn’t exist.
To make one, just create a page with Type: Page and Title: 404 in your metadata. The page content might look like this:
Date: 2022-12-05 21:15
Type: Page
Title: 404
# Not found
The requested page could not be found.
[Go home.](/)
That’s it! You now have a custom 404 page, and it’ll be served whenever it’s needed.
404 might the most recognizable HTTP response code, but it’s certainly not the only one. In 2011, weblogger and overall genius Mark Pilgrim reminded us about 410 when he withdrew from the internet. Maybe you don’t want to withdraw from the internet entirely, but just want one specific weblog post to return a 410 instead of a 404. Easy. First, whip up a 410 page following the same process as above. Then, on the post that you want to return 410, add this metadata: HTTP Response: 410. Now when someone visits that post, they’ll receive the HTTP 410 response code and they’ll see your custom message.
This works for any HTTP response code, but note that some codes make some browsers behave oddly. So maybe don’t go too crazy with it. Oh, also, you don’t actually have to create a page just for the response code — you could do HTTP Response: 418 on a post or page without having a 418 page created, and requests for that item will receive the 418 response code with no content. Cool, right?
Other updates
- Fixed an issue that prevented drafts from being hidden
- Added the
{permalink}tag, which is replaced with the URL to the currently-viewed post/page - Fixed an issue with timestamp parsing in posts
- Fixed an issue with custom paths
- Added a new Atom feed type (use it with
{atom}in your template’s<head>, or if you’re already using{feeds}you’ll receive a link to it there as well)
That’s it for today. See you tomorrow, behind another advent door!
— Adam