The road to SoaPatrickTen (Part 2)

I'm not really in the mood for another blog post about the road to SoaPatrickTen but I think by starting to write I might end up writing the whole thing anyway. So let's get started.

Structure

Switching from WordPress to Kirby meant also rethinking certain things, as I wrote in a previous blog post. Kirby is not WordPress so there is no point in trying to fit Kirby into WordPress, meaning trying to recreate everything feature from the past into this new version.

Let's take the permalink structure for blog posts for example. In WordPress, the most popular way permalink structure is having the year, the month, and maybe the day as well with the slug of the posts' name at the end. I've been doing this for years as well and I pushed it so far that I build the whole storage part based on that structure. Kirby doesn't work like this, well not out of the box, so to make things easy for myself I decided that all there needs to be is the URL of the blog part followed by the blog posts' slug. Of course, this means no two blog posts can have the same slug, but I think that's doable.

This idea of shortening and simplifying the URLs was adapted to all other parts of the website. There are no subpages, all parts of the website lie directly in the root folder. Ok, I admit I did that because I was lazy and I didn't want to invest too much time and energy into Kirby's routing.

What followed was the way the Gutenberg Editor worked. Kirby has a very simple but effective block editor. Sure Gutenberg is really really simple and fast but the endless options each block nowadays offers are getting frustrating (one of the reasons I was looking for a new CMS). So I looked at what Kirby had to offer, what I really needed, and what each block needed in terms of options.

Let's take the alignment option. A lot of blocks offer different alignment options like left, right, center, none, wide and full. Most of the time I only needed two, default and wide. I never aligned text centered or right and I hardly ever aligned something to the full width of the website. So I reduced the options down to only two, default and wide, because that's all I ever needed, and if I ever need something else, I just name it correctly and add it as an option to that block. That's the customization beauty of Kirby.

That was the process of a lot of inner discussions I had, what do I really need this block to have in terms of options and I reduced them to the absolute minimum. And on the other end of the spectrum, I added custom blocks for simple content blocks that do exactly one thing. I thought it would be easier to add feature blocks instead of blocks that do 10 different things.

All this meant that I could go through all those blog posts once more and chose the right option for the blocks, chose a regular or a large quote, make this image wide or regular, same with gallery or video block. The gallery and image block for example went through different iterations with a lot more options like croping and crop-ratio until I decided that I will probably never crop my images inside Kirby but do that in Photoshop beforehand.

The default Kirby video block only has an url field for embedded videos from YouTube or Vimeo, so I added the ability to add self hosted videos, but in the end I made a sperate video block for those to decrease complexity of the block.

Through all those questions I learned a lot about Kirby, about it's possibilities but also about it's limits and there are not a lot of limits and with each problem I solved because Kirby is build in a clever and fully customizable way, I fell in love even more with this CMS.

Now I've been writing a lot about blog posts, but that's because most of the content on this website is blog posts, but there are of course other content types as well. Like Factory or Lab items, Log entries, and a newly created Like (which is not yet live because I first need to write the actual content for that one). And adding new content types and giving those just the fields that they actually need was such a breeze. Same as how you can arrange the fields in the backend. A Factory item for example is similar to a blog post but with lesser fields (no category and no post format). The Lab item is even simpler because a Lab item consists of only an image, or video and a tag field. The Log entry has just a date and category. What I mean by all that is Kirby allowed me to tailor each content type to its needs. There are no fields that are just there but are not used, every field serves a purpose.

Now because I build this whole thing in a bit of a hurry I wrote some ugly code and it's definitely not DRY. But I had to release this website at some point and I knew that there is always room for improvement. This brings me to the theming process. WordPress always worked by having different themes you can switch on and change the look and feel of the website in an instant. Kirby has, at least to my knowledge, no such feature. With Kirby, the look of the website is much more entangled with everything else.

In the past when I wanted to redesign my website, I created a new repository and started a new theme from scratch, and once I was done I just switched themes and the new design was live, Now I have just one repository.

The moment I went live, I tagged the last commit with version 10.0.0. Meaning from now on every change and every redesign will be within the same repository and once I release a new version, I just bump the tag version. This allows me to easily go back to an old version later down the road. For external resources like Kirby or Kirby Plugins, there is a composer file that is also used to install and update those resources on the server. For now, no Bitbucket Pipeline is set up because I still use the same process I used during the development. I wrote some rsync commands which are tied to the build process which uploads all the changes to the server instantly. There are also two rsync commands that push and pull the changes to my local development environment.

This process is really fast and right now I don't see a need for an automated pipeline, also because there is no staging environment anymore. I used that in the last 3 years primarily to get myself familiar with the git-flow process. But when working alone this can be a bit overkill.

---

Ok, this turned out longer than I anticipated. I'm sure it could use some editing, but frankly, I'm tired and just want to go to bed. I might edit this later when I take a look at it again, but for now, I just publish it. In the last part of this 'road to SP10' series, I will focus on the design process of this new version and what I did differently this time.