REGENESIS III (back home?)

so i want to preface this by the fact that it took me over 10 hours to set all of this up. it was a bitch and a half. but we're finally free. thank fuck.

anyways -- let's come out with it: i now have a CMS

now, the tech-savvy amongst you might say "well that's not impressive". the others are wondering what a CMS is, so let me clear this up.

Step I: The CMS

a CMS is a Content Management Solution. putting it another way, it's a service that gives you a pretty nice interface to interact with whatever content you'd like to share, be it images, blogposts, videos - you name it, it can manage it.

now, the reason why you'd want this only starts to become pretty damn clear once you get deep into the weeds about hosting this stuff yourself. most popular CMS are just services that let you sign up, and manage everything from the internet - with it eventually resulting in a site. which is why the tech-savvy wouldn't be too impressed.

however, as those same dorks have likely surmised by now - hell, they may have surmised it when I said 10 hours - yes, I am self-hosting every single aspect of this. well, on a Hetzner server - but I'd say that counts as self-hosting. maybe they should make a term for that. anyways.

though i can get into the technicals from the get go, i would like to walk people down memory lane with me - which technically starts all the way back when I still used netlify.

Step II: Memory Lane

Part A: Netlify

don't worry. this won't take long.

infact this section might be a wet fart of a part, because it was so limiting. i mean, it was a nice start to get into having a website and working on deploying it, but it also felt like a demo more than anything. i had to go entirely with frontend logic, with my only access to the backend being functions that had some pretty eh quotas - meaning they couldn't be used as often.

which, forget self hosting your CMS, this thing won't let you do anything that has a private API. and most CMS will require some credentials to hit their API, with the only way of doing that being with edge functions. i think that's what they were called. or are called? it's been a while.

anyways, then i learned that vercel let you actually do server side logic.

Part B: Vercel

this is where my true journey began.

the moment you have any access to the server side logic, you'll never want to go back. that's how i felt. back then, I used Nuxt, which is based on Vue.

If you saw that last bit, you can see where the benefits start. You unlock server side rendering, where the server renders the page, and hands it off to the end-user. This is nice, because with client side rendering you have to do all of it on the browser - which also means the website can flash as it takes time to load. Amongst other things. But that was part of why I was so interested.

The other part being Embeds. When you paste a link somewhere, and it gets formatted all nicely -- that's an embed, and is using information from the website for that. Client side rendering means you'd have to execute Javascript - and a lot of bots stop before that, because that's too much work. Server side rendering means that your server just serves up the HTML directly. That means basically no work for anyone checking the page - they can just get it, and the information is there already, baked in.

These feel obvious now, but back then this was all foreign to me. I had to stumble my way through the entire process. But I did eventually do it... up until I realised something else.

...what if I wanted to store information?

Part Bi: Spiralling

See, you didn't really have a server. You just had a very limited environment that runs on a server. All you get is the one thing.

This started to annoy me.

For example, I wanted to implement a ticker on my website. I did this via JSON, but that meant I had to touch the code and trigger a redeployment every time I wanted to change the ticker. I wanted to do it remotely.

I looked around and found all kinds of services, but I just... didn't want to get yet another thing to host my site. I just wanted the one thing. And when you want the one thing, there's only one place that can take you.

But that felt too daunting... I mean come on, a server? That sounds like it'd be a complicated nightmare to work with. Plus I'd have to actually pay at that point, so if I couldn't get something working I'm basically wasting money... Is this even wise?

So I kept putting it off. I did find a very atrocious hack for the Ticker by the way -- I just used Notion. I was already using it for notes at the time, and apparently it had an API, so I registered for it and decided to treat a note as a list of strings. It worked. Pretty well, actually. But it felt like such a hack.

Eventually I talked to some friends (hi bee), and eventually went hey, what the hell. Let's go for a server. All that was left was finding the one provider.

...

It didn't take long.

Part C: Hetzner

and I'm still here to this day. but id say it covers around 90% of my journey. i started off just having the one site, and trying to make it work correctly - then I found out about NGINX which lets me specify domain names, which also lets me about having every website be an IP with a Port on the side. 49.12.76.246:8392 isn't as memorable as ratfuck.enbyss.com, right?

anyways, I won't talk about everything I did here because that'll take me forever, though do let me know if you're interested. instead, i'll focus on the blogposts and the images.

Step II: Bumbling Around

let's get blogposts out of the way. the way they've always worked is by having markdown files in the source code that I then deploy. which also means anytime I want to update or create anything I'd have to rebuild my entire site and deploy it. which you know, isn't optimal. imagine if every time you made a post, you had to turn on your computer, go to a specific folder, add some file, build the project which takes a while, and then deploy it. every time.

...that stayed for a long while.

but images had more of a journey. at first I used the ol' reliable NGINX in order to expose images outside - which solved the issue of making nice links for my images, but didn't solve the issue of how hard it was to add files. so for that, I just setup an FTP server - which lets me use something like Filezilla to just log on, and dump a bunch of files on there.

however, there's a bit of an issue that's not obvious when you're still starting out. what if you have an image that's like, really huge - say 3000x4000? if you release it like that, then anyone with a slow internet connection or using mobile data would likely scream at you. but if you compress it, then you can't reveal the full image to people who do wanna see it. of course you can just store both files, but then that's inefficient, annoying, and several other adjectives.

which led me to using image proxies or whatever they're called. there was one whose name I forget that did work but had problems with not taking a while to present any images - and then I switched to imageproxy which was nicer to work with. all they do is basically act like a server that exposes an API to get images. in the URL you'd be able to specify like, width of 500, and instead of just hitting the raw file directly, the proxy would compress the file into the requested size and parameters, and then serve it. it'd also cache it, so if you made the same request again the image would be in your server already processed.

that worked well! but just one issue. it's still a pain to deposit files. the whole FTP approach was annoying - I mean you'd have to log in via FTP and then deposit a file. it sounds small, but it compounds - especially when you want to send over multiple files, and when it's compared to just going to a website and pressing an upload button... yeah.

the last non-CMS solution I tried was to just use SSH. that's the main way you'd access your server - and real quick for the non-techies, the way SSH works is that you have two files on your machine - one called your public key, and the other your private key. if something wanted to let you SSH into it - meaning your terminal would connect to their system - you'd give them your public key. then when you connect, they'd check for your private key to see if it matches with the expected result.

this is really nice, especially when combined with a tool like rsync which lets you move a whole bunch of files to and fro a server you can SSH into. and that's what I did! I basically just made a script to try and make this nicer.

#!/usr/bin/env bash
if (( $# !=  2 )); then
    echo -e "the script requires 2 arguments"
    echo -e "\t [Argument 1]: The local file you want to upload."
    echo -e "\t [Argument 2]: Where you want the file to be uploaded."
    exit 1
fi

# ssh into the server to create the directory
ssh webserver "mkdir -p /ftp/_data/images/$2"

echo "OLD --- IGNORE"
echo $(pwd)/$1 to /ftp/_data/images/$2
echo ""
echo "NEW --- ACKNOWLEDGE"

dest_dir=$(dirname $2)
copy_name=$(basename $1)
dest_name=$(basename $2)
copy_path="$(pwd)/$1"

echo "from $copy_path into $dest_dir as $dest_name"

mv $copy_path "./$dest_name"

# rsync drop the files in the server
rsync -chavzP --stats $dest_name webserver:/ftp/_data/images/$dest_dir

# notify
notify-send -t 3000 "Upload done!"

unfortunately, not nice enough to actually get me to regularly add to stuff still.

so then I stumbled onto a thing called Lychee - and you can as of writing this access it via https://gallery.enbyss.com . it has a single album on it, and will likely be let go, because then I heard about Payload CMS. and spent way too much time setting the fucking thing up.

Step III: The CMS, Again

So, we mentioned CMS before, now it's time for the one I actually picked - Payload. Why? Because the thing lets you self host it entirely. Which means I don't have to sign up for some fuckin thing and depend on its graces for me to not get fucked over. Instead I can self-host, and worst case scenario everything breaks, and I just need to fix it. Which I prefer over trusting some random service to not fuck you over by raising prices after making you dependent on them.

However, the thing with self-hosting, is that it's on you. And that's where the 10 hours went in.

See, this requires a bit of a pipeline, and I'm not even fully done at this point - but I got the hard part done. Which allows me to be writing this from another website that I am self-hosting, instead of having to touch my code.

Payload's big thing is that you self-host it by basically creating your very own app, which they make easy with something like create-payload-app that does it for you, however it means you can add whatever functionality you want.

Which is nice. But also means that, for example, tags aren't a thing by default until you've set them up. I can't do inline-code, at least as far as I know. I also currently can only do code blocks in Javascript, Typescript, and CSS. Which is why that block above is syntax highlighted like it went into a dumptruck.

BUT!

I can finally add and update posts remotely. And that's worth the bit of extra effort it'll take to add features.

That wasn't the hard part though, the hard part was linking this to my blog. By default, Payload exposes the post as JSON - so that it has more of a structure that makes it easier to work with. Unfortunately my blog uses markdown. So I needed to convert the JSON into markdown which, luckily, Payload exposes that functionality - though only within the code.

Then on the blog side I'd have to get the contents of that API, and render it. I wanted to reuse the same config, which then led me to add remark and rehype on the blog, because there isn't a way you can just reuse the thing that Astro uses.

Conclusion: too many todos

Unfortunately it's not all done, like I said. Firstly, I want to put images on there and use that to build my own app to present the images. Secondly, there's a lotta things this Payload doesn't support by default - like, for example, the code block that I thought got rendered but was actually just presented as a generic Block Field.

But for now, I am fuckin tired. So I'll leave that for future me to care about.

UPDATE (15:15): I've managed to implement the code block. Turns out, converting everything to markdown is a bad idea, especially because there's literally a library for Astro that lets you turn Payload's Lexical Block into HTML directly. Which also lets me deal with custom blocks, letting me do components remotely. Kinda. A new component needs work to implement, but once it's there, reusing it is trivial.

I should probably list some of the stuff I learned about Payload CMS at some point.

Also! Everything before this point has basically been a beta test. This is where shit gets real. Wish I could expressive code's component for code blocks though but eh, we make do.

...I mean maybe I can. I haven't checked too hard after all.