Updating the blog

A while back I wrote a post about how I had upgraded the blog during the summer vacation with new features. Most of these were actual features, like the search function on the sidebar or the new tags page. I also told you to stay tuned, because more were coming your way.

In one of my other recent posts I described how you can add custom functionality to Ghost using helpers. I wanted to use this technique for some pretty awesome stuff -- but this only works with Ghost 2.0, and I was still running an older version. So I decided to upgrade the blog engine and dug in :)

To be honest, it was long overdue. For one, the newer versions of Ghost have some pretty nice features, most important of which is probably the new Koenig editor. And for two, with the addition of these custom helpers I had a lot more code changed in the source code of the actual blog engine to just maintain the whole thing in sticky notes.

Creating my own fork

First I decided that I should create my own fork of Ghost, so I can maintain my changes and also merge any updates that come out.

But another important thing that I had to consider that I was running the blog in Azure. Last time I set up the blog I used this awesome repository by Chad Lee that contains all kinds of modifications that enable setting up the blog easily in an Azure App Service. Thankfully, he was maintaining the repository more-or-less in the meantime, so I forked his instead of the original. Done.

Adding Application insights

One of the changes I made to the blog early on is integrating Azure Application Insights into the blog for server side analytics (for the client side I've been using Google Analytics). This is just a small change, but if you consider that you also have to add the appropriate package it can become quite confusing and complicated when deploying the blog, so I added the package with yarn and also a couple of lines of code.

Changing app config

Some changes were required in the app config for the Let's Encrypt Azure site extension to work, as described in this post. Not a big thing, but easy to forget and since https is crucial, I decided to add it to the repo directly.

Adding the Azure Storage Adapter

Ghost has a nice way of adding your own custom storage adapters, so that your content is stored in a place where you specify, not on the local file system of the hosting environment. To be honest, I don't really like it, because as far as I can tell, there's no way to add the name of the post to the path of the uploaded image. That's why I've been maintaining my images for my posts myself: uploading them to an Azure blog account into a container whose name matches the post's slug and adding the reference to the image to the post also by hand. For this, I didn't need any storage adapter, so I just left everything by default and completely forgot about the other assets that I had on the blog: cover images for the blog, for the tags and my profile page. And now I had to add everyting again, which is not so nice. So I decided to keep to my original method for adding post images, but also add the Azure Storage Adapter to the blog engine that would handle all other assets. Some packages and some configuration is also required to make it work, so this was also a good candidate for tighter integration to the deployment pipeline via the repository.

Adding the custom helpers

And of course, the custom helpers. As described in my last post, there's a lot of coding involved when adding a new helper, so I decided to add them right into the source code. Again, this makes deployment easier.

The only problem is that you also have to modify the source of one of the npm packages, gscan. This packages is responsible for validating your themes, and if they contain any references to the custom helper, you have to make gscan aware of them. But the change is pretty small (you just have to add a value to an array for every new helper), and I didn't want to go through the usual method of forking the package and replacing the original in the site.

And fortunately, I didn't have to. I found the awesome patch-package tool that does just what I need: you can create "patches" that you can apply to the existing, downloaded packages after deployment, automatically. This was a lifesaver.

Wrapping up

And last but not least, I set up proper continous delivery in my Azure App Service so whenever I push to my fork, changes deployed automatically. This way I'll be (hopefully) able to easily integrate the upcoming releases into my site.

If you are interested in the changes, check out my Github fork.