Finally… I made my life somewhat easier!
I’ve mentioned on my previous post that I was looking into static site generators to make my job with creating these posts a lot easier. Guess what? I’ve done it! What you’re looking at now is still the same website I’ve been building since last month, but now built with Hugo. I mentioned this since last week as I was trying to get the hang of this thing (I still am).
Every journey has it’s story.
This whole thing took me roughly a week to do, with a lot of hurdles along the way. One of which is the fact that I know jack crap about Hugo; how it’s structured, and coded, are WAY different to what I am used to. I wished I’d document my journey into learning Hugo, and building this website as I go along. The best I can do now is to try to remember the journey and recount it to you, chronologically as much as possible.
Sometimes you want to change your ride
Before I even locked in with Hugo, I initially wanted to build the whole website using Jekyll. It’s equally as confusing to me as Hugo; almost using the same kind of templating style (with the whole {{ thingy here }}
kind of thing, forgive me if I used the wrong term for this). What made me switch to Hugo is equal parts frustration with learning how to use Jekyll (not that they’re any different in hindsight), and from the videos of how Hugo’s great and all with it’s blazing rendering speeds while I was looking for Jekyll videos (bruh). With that, I’ve made my decision to hop into Hugo.
Now the fun begins!
The first few days was filled with confusion as I was trying to read the official documentation. None of it made sense to me, like how do I make the html and other thingys? It only made more sense when I looked for other resources to learn how to use Hugo. This post’s first few points helped me tremendously to get started with actually porting my website to Hugo. The included default theme when you generate one helped me learn what goes what and the nature of making the templates and the website and everything!!!
I think my strength lies in analyzing what on this space-rock-humans-reside is going on in the code and seeing the results of mucking around it. That’s also how I learned how to use the asset pipeline better than the documentation honestly. Importing my scripts (used to display my stream information and randomizes the message below the site title) became easier too once I got the hang of things.
Some quality-of-life changes and additions won’t hurt!
Once I’m done with porting my website, I went ahead and made some addition and changes to the website as well.
It’s good to UPDATE y’all once-in-a-while.
One addition that would also solve one of my problems is the updates page. With Hugo, I didn’t how to make my bite-sized update posts work. The homepage _index.md
is already filled with the “about me” blurb that you would most likely see first when you land in my homepage. I contemplated on repurposing it to hold the current status of yours truly, but then I wondered, “How can I make another markdown content file to display on the homepage?” Then it hit me. I realized that the posts are using a system that could display the information about the posts programatically, which also includes the very content inside of it! So why not make another page for my updates as well while I’m at it!
I also found out along the way to make is so that the markup file doesn’t create another page while having its content still be displayed in another page.
---
date: '{{ .Date }}'
title: '{{ .Date | time.Format "December 26" }}'
type: 'update'
build:
list: 'always'
publishResources: false
render: 'never'
---
Unfortunately, I couldn’t archive the updates before December 23 because that was the oldest update post I have on file. Well I lied, there’s an update post way before that (on December 6) but it was part of a string of updates pertaining to the fate of that week’s stream. Ultimately, I decided not to include it.
You can hit me up using my CONTACT information.
This addition didn’t really do much other than to display my email on which you can contact me through.
A better mobile navbar because it will be too long if I left it be!
With new main pages, comes new entries in the navigation bar! On mobile, this is displayed as a list of pages you can navigate to. Convienient isn’t it? But that convienience is rather moot if it takes up almost 60-70% of the screen when you load into a page on mobile. So I decided I would implement one of those collapsible navigation menus in my website! I’m not sure if you can implement it without some Javascript… took a while to make it work too!
A much better time display of this week’s stream schedule!
Now this one was added after I made the automated deployment system on GitHub (more on that below). I painstakingly made is so that the time of the next stream would display it in a more readable format.
This part of the website is still dependent on Javascript for the very fact that it can be used to display the time in your timezone!
This was a bit more painful to me because I have to manually name all of the Months and Day in an array for it to display to you. I have it here in case you need it too:
// I typed this all down by hand, and I am not a fast typer.
const monthName = ["January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
const dayName = ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"];
Along with this change is how I update this piece of information. I also learned how to use JSON inside of Hugo, and I failed to make my javascript read it. Instead of making the script read the JSON file (which by the way is not being included in the website files), I learned that I can use the data-
attribute in HTML to store any data I want! Now the script reads from a tag that has the data, and use that instead!
404: Solution Not Found. (yet)
One of the problems I needed to solve looks trivial from the outside, but Hugo and Neocites have different views on what to name the 404 page file; Hugo generates it as 404.html
, while Neocities calls it not_found.html
. I tried looking up how to change the filename of Hugo’s 404 file, then I tried to look up if Neocities recognizes 404.html
as a legitimate 404 page. Spoilers: no. This is the one problem that took me the longest to solve, barring actually learning the ins-and-outs of Hugo.
At first, I thought that maybe not_found.html
could redirect people to the 404 page Hugo generates with the follow code in the not_found.html
:
<!DOCTYPE html>
<html>
<head>
<!-- replace the URL with your directory to your 404.html page -->
<meta http-equiv="Refresh" content="0; URL=https://rippandsterritory.neocities.org/404.html" />
</head>
<body>
nothing to see here b0ss
</body>
</html>
It works, but I got a nagging feeling that I should stay away from this approach. For now while I think of a good solution, I decided to look into automating the website update deployment using GitHub Actions. That’s when I found my answers to this thorn on my side.
Automation is a thing of beauty…
At this point, I haven’t even told you about the fact that I made a repository for the website on GitHub. Before you ask, no I won’t make the repository public; at least not yet. Anyways, GitHub has this feature where you can tell them to do certain actions when you upload your changes to their storage that has your code in it (btw, that’s what an ELI5 definition of a repository). You can even tell them to build the website with Hugo, and ship the build to your Neocities websites with the right tools.
This post from another Neocites site tells us exactly the tools needed to make it work. To make things better, bro also laid out the solution to the whole 404 page problem I was having earlier! I made some changes to their workflow so it uses the latest version of those tools:
name: Deploy to Neocities
# only run on changes to main. Use main or master depending on whatever your default branch is called.
on:
push:
branches:
- main
concurrency: # prevent concurrent deploys doing strange things
group: deploy-to-neocities
cancel-in-progress: true
jobs:
deploy:
name: Build and deploy Hugo site
runs-on: ubuntu-latest
steps:
# Install Hugo in the runner
- name: Hugo setup
uses: peaceiris/actions-hugo@v3.0.0
with:
hugo-version: 'latest'
extended: true
# Check out the source for the site
- name: Checkout
uses: actions/checkout@v4
with:
submodules: recursive
# Build the site with Hugo
- name: Build with Hugo
run: hugo --minify --gc
# Rename the 404 page to not_found.html
- name: Rename 404 page
run: mv public/404.html public/not_found.html
# Push the rendered site to Neocities and
# clean up any orphaned files
- name: Deploy to Neocities
uses: bcomnes/deploy-to-neocities@v3
with:
api_key: ${{ secrets.NEOCITIES_API_TOKEN }}
cleanup: true
dist_dir: public
Thing is, it took me a while to learn how to use GitHub Action. Then there’s also the embarassing amount of time I tried to install the base Deploy to Neocities action before I realized that bro already has their workflow laid out in front of me. Whoops!
But why all of this trouble?
My reason for needing a static site generator is so that when I want to make a change on the whole website (e.g. more menus in my navbar), I won’t have to edit every single page manually. It’s no so bad right now, seeing as there’s only a couple of pages. The problem will only rear itself on its head when I, inevitably, have a lot of blog posts. That means I’d have to sift thru a lot of pages, possibly 100s of ’em in the future, if I want to make even a miniscule of change. It’ll be worse if I want to change the whole layout or make an overhaul of the website.
One benefit I’ve found while porting my website, is the fact that I can make posts (such as this one) in markdown. It doesn’t seem much at first, but while I was porting the previous post and writing this one it clicked. I don’t have to encase my paragraphs in HTML tags anymore; I can just treat this like I am typing in a word document or notepad! If making website updating easier not a selling point of Hugo (or any static site generator), then this takes the proverbial cake!
Are there any other alternatives to this?
Yes. Yes there is.
Aside from other static site generators and outside of using GUI website builders (where’s the fun in that?), Zonelets is a good alternative if you just wanna blog. Although, I got the feeling that it might not work out well in the long-run. It feels like you’ll have the same problem of going through a lot of pages if you want to make changes to the layout. I may be wrong about that, and I hope I am wrong about that. Even then. you’d still need to make your posts in HTML.
I must admit I took a path more rocky than what I could’ve done instead, but it was all worth it for me; knowing that I could change the face of this website and not have to go through a lot of tedium just to accomplish that. Plus, the fact that I can make my posts faster made it even more worth my while.
Resources for the dreamers willing to take action.
If you also want to make your site with Hugo, wherever it will be hosted on, here’s some references you can use to get started:
- The post I mentioned that helped me a ton to get started
- A guide on the structure of Hugo, which helped me make sense of it
- I didn’t use this one for myself, but it may of great help to you
- The guide to deploy the website to Neocities using GitHub Actions
- Last, but not least: the official documentation. It still helped me when I got the hang of it
Of course, this assumes that you know how to make websites using HTML + CSS. Don’t worry though if you don’t know how, it’s FAR easier to learn than Hugo. Trust me! There’s a lot of resources to learn from! This one has a TON of resources not only to learn how to make a website, but also where you can host your website and then some!
That’s all there is to it… for now.
I may create some posts or videos about creating a Hugo site, cause I can’t seem to find one that’s more beginner friendly and explains stuff and concepts to you like you were born yesterday. Might as well step up to the plate and deliver that.
There’s more stuff that I want to do with this site. The-one-that-is knows I need to improve the contact page by a mile. For now though, I am cooking up a Roblox-story-thingy video for the primary channel about the rise and fall of my Roblox yakuza clan. As always, I will be stream this Saturday (the one just after New Year) where I continue my misadventure in Black Mesa (Half-Life, not the fan-turned-kinda-official remake).
Thank you for reading all of that yapping about code and stuff (if you’ve been reading from start to end, otherwise thanks anyways!). This is the longest post I’ve made and I don’t think this will be the last time a post will be this long or even longer. Happy New Year, and I hope you’ll have a fruitful one!