Hugo Front Matter Aliases for Migration

Table of Contents

Use Hugo front matter aliases to handle migration from other platform such as Ghost or WordPress.


I have multiple posts about using mod_rewrite / redirect in various web servers to handle difference in base url when migrating from one blog platform to another. Following are a few examples:

From URL To URL Http Server Rules
WordPress /index.php/YYYY/MM/DD/<article> Hugo /blog/<article> Nginx location ~ “^/index.php/\d{4}/\d{2}/\d{2}/(.*)$” { return 301$1; }
WordPress /index.php/<article> Hugo /blog/<article> Nginx location ~ “^/index.php/(.*)$” { return 301$1; }
WordPress /index.php/YYYY/MM/DD/<article> WordPress /index.php/<article> Lighttpd url.redirect = (“^/index.php/\d{4}/\d{2}/\d{2}/(.*)$” => “/index.php/$1”)

However I encountered something that can’t be (or too risky) generalized into rules:

Ghost /<article> Hugo /blog/<article>

It looks simple by itself but it can be a big mess. The risk is high and I opted for static rules like following:

location /ghost-blog-custom-theme { return 301; }
location /ghost-blog-from-wordpress { return 301; }
location /ghost-blog-redirect-after-wordpress-migration { return 301; }
location /ghost-blog-self-hosted-with-https-using-nodejs-only { return 301; }
location /ghost-https-index-js-in-github { return 301; }

It look stupid but safe. I ended up with 43 of them plus other rules!!

Hugo Front Matter Aliases

As I use and explore Hugo more, I found that Hugo front matter support aliases1 and also a tools to extract front matter call front-matter-manipulator.

Script and front-matter-manipulator

I quickly put a script2 together and generated all the aliases I needed.

--- 2017/03/13

    - /
    - /index.php/
    - /index.php/2017/03/13/

--- 2017/02/07

    - /
    - /index.php/
    - /index.php/2017/02/07/

--- 2017/02/08

    - /
    - /index.php/
    - /index.php/2017/02/08/

--- 2017/02/25

    - /
    - /index.php/
    - /index.php/2017/02/25/

--- 2017/03/13

    - /
    - /index.php/
    - /index.php/2017/03/13/


I copy & paste them into my post one by one. Only 43 after all. The result is I can removed all web server rules except one.


The resulting site no longer need web server redirect rules to handle old urls. Especially the 43 rules specifically for migrating from Ghost.

The only remaining rule is for mapping old /tag/<tag> to /tags/<tag>, which is not important.

The site response time is faster as requests don’t have to go through rules. The bigger the site, the more performance is gained(or saved).

The site is 100% static with no dependency on redirect rules!


The public directory became flooded with static directories:

├── a-simple-global-variable-service-for-angular-2/
├── angular-simple-mq-service/
├── angular2-simple-timer-service/
├── apple-touch-icon.png/
├── before-and-after-d/
├── ghost-blog-custom-theme/
├── ghost-blog-from-wordpress/
├── ghost-blog-redirect-after-wordpress-migration/
├── ghost-blog-self-hosted-with-https-using-nodejs-only
├── ghost-https-index-js-in-github/
├── h2ghost/
├── how-to-configure-systemd-journal-remote/
├── let-ghost-be-ghost/
├── lighttpd-url-redirect-and-changing-wordpress-permalink-structure/
├── lighttpd-url-rewrite-for-latest-wordpress-jetpack/

But those are generated automatically and not my working directory, which is content.


I decided the PRO out weighted the CON in the long run and only a one time effort.

The switch freed my site from web server dependency and can move between different kind of hosting environment with ease.


John Siu
Minimize the Effort, Maximize the Effect!
comments powered by Disqus