I'm an independent Product & Engagement Marketing helping Shopify focused businesses. In addition to my personal articles here, I also run Leader of the Pack, a blog dedicated to reviewing travel bags and accessories for people on the move. You'll also find me occasionally posting on Twitter and Instagram.
October 23, 2017
Over the last few months I’ve been making some minor adjustments to this site, and the Back to Front Show site, both of which run on Jekyll. One thing I have found really useful is having the ability to chain multiple
config files together — especially when developing locally.
I currently use Cloudinary to serve blog post images. I plan on writing a bit more on the “why and how” of using Cloudinary in another post but essentially when developing locally the Cloudinary based URLs will only work if the original image has been made available online. Cloudinary uses an origin-pull method to add images to it’s own network and therefore has no knowledge of new images that aren’t available via a public URL.
When adding a new post I create images locally and add them to a folder within my Jekyll site — which are then available locally for preview. Once the post is complete I push the images and markdown file to GitHub which regenerates the site. However, given that my
figure element include file (below) references Cloudinary I am unable to preview the images during a local preview as Cloudinary has no concept of the image stored on my local machine. Previewing locally only results in a 404 error on any image referencing the Cloudinary URL.
After some head scratching I came across the option of chaining multiple
config files together. This option allowed me to make use of a single
config variable that is loaded in for local development and can be used to change the logic within the templates to load the images locally.
It’s actually pretty simple to implement. In
_config.yml I created a variable called
environment and defined it as follows:
This is the default
config file that GitHub will use when building the site so it should reflect our
production settings. Next I created a new
.yml file called
_config.dev.yml and saved it in the root of my Jekyll project. It also contains a definition for the
environment variable, this time set to
In effect this is simple overriding the setting in the main
config file. This variable then allows me to run a simple
if statement in my
figure include as follows:
Simply put if the
environment variable equals
development then the site will be built using my local image path, if not then it will use the Cloudinary URL.
All good in theory but how to put it into practice. The “magic” happens when starting Jekyll from the terminal. Using Bundler I normally fire up Jekyll as follows:
In order to chain our
config files together we need to add in the
--config flag as follows:
--config takes a comma separated list of filenames as it’s argument. In the example above I am loading our base
config file followed by the
config file containing the variable override.
I’ve been using the above method quite happily but there’s also another, perhaps you could argue the “proper”, way of achieving the same result.
It’s also possible to specify a Jekyll environment value when building or serving a Jekyll site. This will then be available to use in conditional statements in your code.
The Jekyll docs use the following example:
When firing up your Jekyll site (using build or serve) the above statement will only run if the environment value has been passed in.
In order to pass it in using
serve and Bundler you need to prepend it to the beginning of your command:
It’s worth noting that he default value for
development. Therefore if you omit
JEKYLL_ENV from the build or serve arguments, the default value will always be
Using this approach you can avoid having to change value in your configuration files but it has the exact same end result as using chained