Website on Flo's Thoughts

Note to Self: On Working With Hugo

Thu, 19 Feb 2026 21:07:22 +0100

In early 2026, I had the urge to start using my website again. I had a few ideas for some blog posts that I want to write about. While checking out the page and updating what’s been here, I had to figure a few things out. This is just for me to remember what I did for the next time I have to do a major jump.

Updating the theme Link to heading

At the time of writing, I’m using the theme hugo-coder. I did not install it as a submodule but as a plain copy. When updating to the newest version, I had to replace a few files.

To always link to a link post’s url of to the associated external link: themes/hugo-coder/layouts/posts/li.html {{ .Date | time.Format (.Site.Params.dateFormat | default “January 2, 2006” ) }} {{ .Title }}
To display link post’s title with an arrow: themes/hugo-coder/layouts/posts/single.html … {{ if .Params.ExternalLink }} → {{ .Title }} {{ else }} {{ .Title }} …

Overview Link to heading

I liked this video tutorial by Luke Smith that helped me understand how Hugo works.

Hey Kirby!

Tue, 16 Feb 2016 19:14:37 +0200

For the last couple of years I have been using Jekyll for this website and I really enjoyed it. It’s nerdy nature spoke to my inner, well, nerd. Unfortunately, this nerdism isn’t always practical. Jekyll requires you to rebuild your website and sync the resulting website files to your host. I know there are solutions to this but they all seemed kinda hacky to me. This was fun for a while but I felt like it got more and more in the way when just wanting to quickly share something. Hey, who would’ve thought a backend can make total sense when you want to manage contents?

So I started looking at different solutions and what stuck with me is Kirby by Bastian Allgeier. The migration process took quite some manual labour as I wanted to migrate my old post and I wasn’t able to find an automated way to that. But now that I have moved everything over I’m glad to have a backend which I can also use on my iPad. Unfortunately, I don’t speak any CSS anymore. Therefore, I’ll have to stick with the default theme for now. But that doesn’t look to bad anyway, if you asked me.

So, welcome to my site, Kirby!

Jekyll Auto-Build With Git Hooks

Tue, 13 Oct 2015 19:26:26 +0200

tl;dr: Use the full path to your jekyll executable when running it from a git hook.

As much as I love Jekyll for it’s nerdiness and it’s speed, as much can it be annoying at times when you have to “compile” your website and upload it to your server every time you fix a comma. This situation lends itself to get automated.

First things first: I host my website on Uberspace. I mentioned before that they’re just the best, right¹? Anyway, at Uberspace, they don’t have Jekyll pre-installed so you have to install it yourself. And since you can’t just install it for the entire machine, you have to install it on a per-user basis:

gem install --user jekyll

This allows you to still run jekyll from the terminal as you normally would. However, this doesn’t seem to apply when working executing a post-receive git hook included in your server repository.

Therefore, I had to enter the full path² to the jekyll executable to the example provided on the official Jekyll site. So, what I ended up with looks like this:

GIT_REPO=$HOME/git/flohei.de.git
TMP_GIT_CLONE=$HOME/tmp/myrepo
PUBLIC_WWW=$HOME/html

git clone $GIT_REPO $TMP_GIT_CLONE
cd $TMP_GIT_CLONE
~/.gem/ruby/1.9.1/bin/jekyll build -s $TMP_GIT_CLONE -d $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

I assume that this applies to any setup where you’re not able to install software on a machine-level but only on your user account. So feel free to drop me a line if this helped you, even with another setup.

If you can see this post, this means that this system is working as intended.

They operate on a pay-what-you-want basis and offer a shit-ton of features. Besides, their support is insane. And I mean that in the best possible way. ↩︎
If you don’t know how to find that full path just run which jekyll. ↩︎

Trying Medium

Thu, 08 Oct 2015 19:38:31 +0200

Cat just found my post on Geofencing and the follow-up on my site and suggested that I should cross-post them to Medium, just to reach a wider audience. So I decided to give it a shot. If you prefer reading some of my posts on Medium, you can now do so. As usual, my profile can be found @flohei.

Combining Matt Gemmell's Staging Script and Jekyll-Post-Link

Sun, 08 Feb 2015 15:00:00 +0200

Last week, Matt Gemmell released a pretty handy staging script for Jekyll.¹ This temporarily removes all your posts from your site and copies a draft into _posts. This way, building your Jekyll site with your new draft post is way faster than your regular builds with all your content.

Unfortunately, this does not work when you’re using the jekyll-post-link in one of your pages. (Yes, I mean pages, not posts.) The build process for your staged website will fail with an error like this:

Liquid Exception: Could not find post "2015-02-05-foo bar" in tag 'post_link'. Make sure the post exists and the name and date is correct. in baz.md

This morning I talked to Matt about this over on Twitter. He mentioned, that it should be fairly easy to make it work. And he was right. I forked the jekyll-post-link project and made it check if we’re in staging mode before failing on us when a “broken” link appears.

Whenever it finds a post link now, it replaces it with a dummy link. Next time you do the actual build outside of staging mode everything will be back to normal.

You can find my version on GitHub. Hope this helps. If you have any questions or suggestions feel free to get in touch.

Thanks to Matt and Liam for their great plugins!

As of today, it’s also available as a Ruby gem with multi-site support. ↩︎

Two New Jekyll Scripts

Sat, 07 Feb 2015 14:00:00 +0200

Every now and then I try to make the process of writing posts in Jekyll a bit more pleasant. Last time, I shared a script that was supposed to make the post creation process a bit easier. It turned out, though, that I almost never really use this script because of its complexity. There are just too many switches and configuration options. (Of which some don’t even work reliably.)

Though this script did not help me as much as I hoped it would, it led me to two new, extremely simple scripts in my toolchain.¹

draft.sh Link to heading

This one just takes the title of the new draft as an argument and creates the appropriate file markdown file inside my general purpose drafts folder on my Dropbox² and opens it in TextMate.

#!/bin/sh
# variables
site_path=~/Sites/example.com
drafts_path=~/Dropbox/Drafts
title=$1
# create the file name
lowercase=`echo $title | awk '{print tolower($0)}'`
stripped=`echo ${lowercase// /-}`
filename=$stripped.md
file_path=$drafts_path/$filename
echo "File path: $file_path"
# create the file and add content
echo "---\n" >> $file_path
echo "title: \"$title\"" >> $file_path
echo "layout: post" >> $file_path
echo "published: false" >> $file_path
echo "categories: " >> $file_path
echo "tags: " >> $file_path
echo "date: " >> $file_path
echo "\n---\n" >> $file_path
echo "Content goes here." >> $file_path
# open file if wanted
mate $file_path
# done
exit 0

This way I get a basic post file and I can just start typing right away. I usually fill in details like tags, categories and the date later.

publish.sh Link to heading

When I feel like publishing that new draft as a post on the site I could just locate it in Finder, move it to _posts, rename it, open it, add the additional information, rebuild the site and upload it to my server.

publish.sh takes the draft’s name as a single argument, renames it, moves it to _posts and opens it in TextMate so I can make some final changes before going into build mode.

#!/bin/sh
# variables
site_path=~/Sites/flohei.de
drafts_path=~/Dropbox/Drafts
file_name=$1
file=$drafts_path/$file_name
# check if the draft exists
if [ ! -e $file ]; then
	echo "draft $file does not exist"
	exit 1
fi
# create the file name
post_date=`date +%Y-%m-%d`
target=$site_path/_posts/$post_date-$file_name
# move and open the file
mv $file $target
mate $target
exit 0

I’m rather confident that I will use these simple scripts way more often than the other bulky one.

Hope this helps.

I keep all my site-related scripts in a _script folder in my Jekyll site directory. This way I can easily access them when needed. ↩︎
I switched to storing drafts on Dropbox because it’s way easier to access the files on there from my iOS devices via 1Writer (http://1writerapp.com), for example. ↩︎

Password Protected Pages With Jekyll

Wed, 12 Nov 2014 15:04:06 +0200

When I moved to Jekyll I didn’t have a way to password protect pages. Actually, I didn’t really need it so it wasn’t a real concern to me and I did not yet look into it. Until today. I was contacted by Osama of TimeSvr who asked me about this and so I thought it might be a good idea to share what we came up with.

Since we only needed to protect pages within a certain context we decided that .htaccess protection would be sufficient enough.

Update 2014-11-18: This does only apply to Apache installations. If you’re using nginx or something else you might not be able to make use of this approach.

Project Structure Link to heading

The setup for password protected pages looks like this:

my-website.com
|-my-project
 |-index.md
 |-htaccess
 |-htpasswd
|-...

Based on this suggestion I created template files for htaccess and htpasswd jekyll style using an appropriate front matter (which basically only defines the permalink to the actual, hidden .ht* files).

---
layout: null
permalink: my-project/.htaccess
---

(For htaccess; adapt for htpasswd appropriately.)

Additionally, htaccess needs the configuration:

AuthType Basic
AuthName "Protected Area"
AuthUserFile /full/path/to/.htpasswd
Require valid-user

index.md is the template for the website with the protected content. Just a basic Jekyll page.

Creating Credentials Link to heading

This actually caused some trouble for me. I first started googling for webservices that offered credential creation for .htaccess files, since I wasn’t aware of the appropriate way to do it: The official htpasswd tool. The credentials created by the websites did somehow never work for me. I’m not a hundred percent certain that it wasn’t my fault, though…

Anyway, htpasswd -m -c /path/to/my-website.com/my-project/tempcreds foo creates a file tempcreds containing the user foo and the encrypted password (which you’ll be asked for after hitting return). Next, I had to take this entire string and added it to the end of my htpasswd file.

Publishing Link to heading

After re-building my site I uploaded _site/my-project/ to my server. Make sure to not forget the hidden .ht* files as well. That’s it!

Hope this helps.

Jekyll: Script To Easily Create New Posts

Sat, 16 Aug 2014 19:39:12 +0200

Jekyll is amazing for me. It gives me full control over all my content in an easy to maintain way while keeping it in a sustainable format.

Though creating a new post is as simple as creating a new Markdown file and setting some variables within the front matter, this usually takes a few moments and most of these steps are the same over and over again.

To make life a little bit easier (and to just have something to fiddle around with, to be fair) I wrote a small script that helps jump-start on new posts. It creates the file, sets the title and date and tags and categories if I wish to and opens that new file in my favorite text editor.

So,

./jekyll-new-post.sh -n "New Cool Post" -d "2014-08-17 15:23:45" -o -t "Jekyll" -c "Development, Thoughts"

would create a new file called 2014-08-17-new-fancy-post.md with the front matter date property set to August 17, 2014 at 15:23:45, the categories and tags set as well and open it in your preferred text editor.

You can find this script over on GitHub.

So, I you find yourself using Jekyll and keeping a Terminal window open all day this might be for you. Feel free to adapt it to your needs. I will probably fix the remaining todos and add some features I still have on my list. So you should consider this beta.

Searching Jekyll

Sat, 26 Jul 2014 23:39:57 +0200

Using a static site generator like Jekyll for your personal blog brings a few new challenges in some areas. Searching, for example is not possible in pure HTML. There are a few different options to find posts on your website, though.

tl;dr Link to heading

jekyll-lunr-js-search is great, just head over to GitHub and get started.

External Search Engine Link to heading

Both Google and DuckDuckGo offer search engines for your own website which are more or less easy to integrate in your own site. Unfortunately, DDG did not seem to index my site {% post_link 2014-07-02-moving-to-jekyll since I installed Jekyll %} and this plugin a few weeks ago.

Besides that, integrating an external service ruins the whole point of being mostly independent with your site. Everything that’s on here should still work if the rest of the world collapses. Well, there are some videos and external photos that would not be displayed anymore but most of the content and functionality of the site would still be available.

Local Search Engine Link to heading

So I started looking into search engines that work locally on my own server. Starting on Brett Terpstra’s site I found out that he uses a custom solution which basically works the same way the two following ones do. They all create an index file (search.json) which can then be used to filter all the posts based on a keyword with some JavaScript.

`jekyll-dynamic-search` Link to heading

The documentation on this one is a bit minimalistic so I had a hard time integrating it into my site. If you’re more adventurous than I’m check out the project on GitHub.

`jekyll-lunr-js-search` Link to heading

Talking to Brett and Oliver Nightingale on Twitter I got pointed to this plugin based on lunr.js.

lunr.js is a simple full text search engine for your client side applications. It is designed to be small, yet full featured, enabling you to provide a great search experience without the need for external, server side, search services.

Here the documentation is way better and it’s rather easy to integrate. The only pitfall I ran into is the fact that it did not work for me when I added the search.min.js file at the and of my new search page. So I had to integrate it right above that script part. If you’re curious you can find my template on GitHub.

Re-Routing RSS Feed

Sun, 06 Jul 2014 15:08:30 +0200

Quick follow-up on the Feed Forwarding section from that other post on Jekyll: Turns out, the forwarding in the header of that HTML file did not work as expected. Opening the URL in the browser passed you through to your favorite RSS reader if you have one installed. Feed readers that had already subscribed to the original feed before did not get any updates, though.

So I changed that re-routing to be handled in my .htaccess file.

RewriteRule ^feed/?$ /feed.xml [L,NC]

This line fixes the issue. For more information about .htaccess files and the syntax see the “Apache mod_rewrite Introduction”.

Moving to Jekyll

Wed, 02 Jul 2014 21:48:05 +0200

Listening to Brett Terpstra’s podcast Systematic, I found out about the static website generator Jekyll. After hearing and reading about it for a while I started wanting to try it for my own website.

There are some great tutorials out there that describe the basic setup of a new Jekyll website, like Jekyll From Scratch by Mike Greiling, so I don’t want to talk about that. What I want to talk about, though, are the bits and pieces that these tutorials were missing for my very own situation. There might be some more people with a similar setup. There were three major questions I still had after reading the different tutorials:

How do I migrate my old posts?
How do I reflect password-protected pages?
How do I make the website handle old links?
How do I handle stats? I somehow don’t want to use Google Analytics.

My website up until today was a self-hosted WordPress at blog.flohei.de. flohei.de would automatically redirect to the subdomain and not hold any information itself. I was using pages and posts for my content. A few pages were kinda hidden and password protected. I was watching the site stats using the built-in Jetpack module. I was the only author.

Import Link to heading

Jekyll comes with importers for different other blogging systems. The importer for self hosted WordPress instances did not work for me so I tried using the one for WordPress.com sites. That one uses an WordPress export file that your backend can provide.¹

ruby -rubygems -e 'require "jekyll-import"; 
JekyllImport::Importers::WordpressDotCom.run({ "source" => 
"/Users/flohei/Downloads/wordpress.xml" })'

Cleanup Link to heading

After that import I got a bunch of HTML files for all those old posts and pages.

First things first: As always, when moving my blog, I revisit my old posts and remove/archive the most embarrassing ones as they’re probably to no good use for anybody. I think that’s only fair to all the internet people.

All the remaining posts were then manually converted from HTML to markdown. That took some time but it also gave me the chance to fix some typos and adapt some of the old links.

Most of the important pages were just recreated in markdown since they’re not that many. I got rid of the old ones as well.

Password protected pages Link to heading

Unfortunately, I did not yet find a way to migrate my password protected pages. I’ll let you know once I find a way. If you have an idea feel free to drop me a line.

Update 2014-11-12: I wrote a post about a htaccess based approach.

Links Link to heading

Keeping the links up was one of my main goals. The problem was divisible into two sub-problems.

Keeping the Permalinks Link to heading

In WordPress I used /YYYY/mm/title for my permalinks. Setting the same format in _config.yml was easy. The corresponding line looks like this:

permalink: /:year/:month/:title/

This would keep all the old links up once I replace the WordPress site with the Jekyll data at blog.flohei.de.

Re-routing Requests Link to heading

I had the idea to take the migration a step further and drop the blog subdomain in favor for the cleaner flohei.de itself. I remembered, that there was an option for the .htaccess file to re-route requests by preserving everything behind the TLD. A quick question on StackOverflow brought up the solution:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^blog\.(flohei\.de)$ [NC]
RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301,NE]

This works like a charm.²

Feed-Forwarding Link to heading

Update 2014-07-06: Turns out, the original approach did not work. I wrote an extra post about how to fix it here. Hint: It works using the .htaccess file.

Stats Link to heading

As I said, I somehow did not want to use Google Analytics. So I remembered that Daniel used Piwik for a few web projects in the past. I don’t care too much about my stats so I’m not that familiar with all the features these tools have but from what I can tell Piwik looks a lot more useful than Jetpack and a lot less cluttered than Google Analytics.

The setup was as easy as downloading the package to the server, unzipping it in a special subdomain, creating a database and following the on-screen instructions.

Todos Link to heading

There are still some bullet-points on my list left to figure out. I might want to adapt the style a bit (though I kinda like this clean and simple layout), I might want to include the old tags and categories somewhere on the site and I might want to add the comments back. I migrated them to Disqus before leaving WordPress so I still have them. But I’m not too sure if I need them anyway.

Creating a Staging Environment for Your WordPress Installation

Mon, 27 Aug 2012 19:56:10 +0200

For yesterday’s attempt to cleanup my database and fix the post id > 2³¹-1 issue I did not just want to fire the scripts and tests at my live site. So I quickly set up a WordPress staging environment. In my case, I created a special subdomain on my server, which makes things fairly easy. If you can do that as well: great, read on. If not: go check out Moving WordPress. They described how to move your site for a few more different scenarios.

Back to my situation. First log in to your server and create a new directory for the staging environment and copy all the content from your original WordPress directory to that new location. Then head over to your database management system and export your WP database. You should make the export file be able to create the tables. Import that export file into a new database. While being here on the database server open up the wp_options table and alter values for siteurl and home. Set them to your new subdomain. Of course, if you did not create that one yet, go and do that now. Then jump back three sentences. Last but not least you’ve got to tell the wp-config.php the new database name.

For me that was all I needed to do to have a save environment to play around with. Hope that helps.

Fixing the Post Id > 2³¹-1 Issue

Sun, 26 Aug 2012 19:47:03 +0200

Regarding my WordPress issues, which I actually did not want to tackle anymore, I accidentally stumbled upon an interesting post over on StackExchange, when I was looking for another issue. But as it turns out, this does fix the former issues as well. Nice.

The new issue did appear to me when I clicked through the Jetpack stats pages. Top Pages & Posts did only show one entry which looked like this:

I had no clue what that meant, so I checked out another WordPress installation I’m maintaining. That blog showed the post titles (yes, more than one) without the enormous number just fine.

Every post’s id > 2³¹-1 (> 2,147,483,647) was being max’d to that number, it seems. The above mentioned post explains, that these huge numbers come from Tumblr imports. Tumblr uses such high numbers to identify it’s posts. I actually did the import from Tumblr when I set up this new blog. Mystery solved!

But how do we fix this? Luckily, the guy who answered the post over at StackExchange had an idea that seemed to work: Just go through all your database entries and shrink the numbers manually. Yeah, well. It’s not that many posts on my site but lazy as I am even about 350 are too many to tackle them all manually. So I wrote a little script that did that for me. It can be found here. I know, it’s spaghetti code and not beautiful, but for me it did the trick. And as I will probably only use it once that’s ok.

So, let’s just go through the whole process step by step:

Export the needed tables. For me it was wp_comments, wp_postmeta, wp_posts and wp_term_relationships. If you have a more complex setup than me you might need to export more tables (and adjust the script appropriately). In order for the script to work you will need .sql files (one for every table) with the permission to drop the old table and re-create it when it’s being imported.
Run the script on all the exported files (see my warning below!). You should now have a second file for every single table you need to alter. If you looked at the script you might be wondering why I started $post_count at 20 instead of 0. For me, my wp_term_relationships had some entries that had normal looking ids (up to 19) and as I wanted to avoid conflicts I thought starting one higher might be a good idea. These few entries had to be adapted manually because my script does not cover them. So I opened up both the original and the just created file and fixed these few lines.
If you did a backup of your website (of course you did, right?) and if the new files are prepared you can go ahead and import them into your database (Again, see my warning below!). If you did it like described, this will drop your original tables, re-create them, and import the data afterwards.
Check your website. That should be it.

My site is still working fine and I hope so is yours. ~~Though I’m not sure if Jetpack will show the titles (I think this might take until tomorrow or until more posts have been clicked)~~ Update: It worked, my stats are being displayed nicely. And I’m happy the WordPress iOS apps aren’t confused anymore.

So, thanks again to that guy on StackExchange for figuring this out. For a detailed explanation I suggest checking out his answer.

I hope this helps someone.

Warning

Do only use the script and instructions at your own risk and if you know what you’re doing! I cannot guarantee that it’ll work with your configuration. You might blow up your machine or even the whole data center! Maybe. Also, you should adjust it to your needs. You might also consider to set up [a staging environment] for your blog to play around with.

The WordPress Issues I Had After Importing My Old Posts

Tue, 21 Aug 2012 20:03:34 +0200

Since I began using WordPress my website had this weird issue where it would show all my blog posts once you add the feed to an RSS reader but would never show new entries. Also, the official iOS app somehow mixed posts and pages and showed some of them multiple times and the newer ones (the ones I wrote after importing everything into WP) did only occasionally show up in there.

I know, this is like the worst error descriptions ever, but unfortunately I had no chance to figure out what actually went wrong during the setup and import of that new WP site.

So I began asking for help on this in different places to get this sorted out. Unfortunately, my problem description was probably to inaccurate to get valuable feedback. So I tried a few things myself like cleaning up the WP database using WP-Optimize and checking the database manually. Though I was not able to find anything suspicious in there. Damien tried to help me over on StackExchange and we figured out, that the feed issue seems to be gone. I assume, that that has something to do with cleaning up the database since that’s the only thing I tried that was manipulating my data.

The iOS apps are still not working but that’s ok for now. MarsEdit (App Store: de, us; affiliate links) does work perfectly and the WP backend is not that bad so I think I can live with that.

Moving

Mon, 11 Jun 2012 23:51:04 +0200

Those who follow me on Twitter might have noticed that I’m currently in the middle of a move from Nuremberg back to the country side. Which is awesome. :) But that’s not what I wanted to talk about.

A few years back, when I was still doing .NET stuff, I registered my name domain florian-heiber.de and a .NET webspace (with centron) to set up a BlogEngine.NET blog on there. A while later I registered my other domain flohei.de just to have a nice and short domain name for my personal email. The A-Record for that domain moved from one hip new service to the next. The last one was Tumblr.

I was getting kinda tired about having all my stuff in different places and developed the idea of moving it all back into one space. Since I’m that kind of person who does not blog that much and therefor does not want to lose all the old (and sometime a little bit embarrassing ;-)) content, I needed a new space (a server would be oversized) and a new blog engine, which would let me import the posts from Tumblr and a BlogML file, that stuck around on my computer for quite a few years. After some time of research and comparison I decided to go with the German hoster Uberspace.de¹ and WordPress.

Now I’m happy to have all my stuff in one place again. Not only my physical goods.

Uberspace is awesome. They let you decide what you want to pay for your space and even give you full SSH access to it. Besides that, you’ll get a ton of features (http://uberspace.de/tech). ↩︎