My Jekyll workflow: Part 2
Read time: 3 min
In part 1 I wrote about my basic workflow. It worked fine but the most important part, the writing experience, was not that great. So I decided to leave move on and leave the built-in Working Copy editor for another one which would have improved my blogging experience.
A better editor: iA Writer
I really like iA Writer, it’s well designed and makes you focus on what you type. I still use it for all my writing needs.
What’s more, their new feature called templates lets you customise the markdown rendering in Preview mode. So I’ve build a template using the same CSS code from the blog to preview posts on desktop and mobile without committing and pushing.
Handling static resources
The downside effect of the above changes is I wasn’t able to preview post images in iA Writer, because the path (starting
site.baseurl) couldn’t be rendered as a correct and publicly accessible url.
Therefore, I excluded static files from the website repo to be able to put them online without needing to commit and to make the repo much smaller. To upload resources, I do via SFTP. On desktop many options are available, from Cyberduck to command line, on the go there are the free Documents by Readdle on iOS and ES File Manager on Android. With static files online and publicly accessible, I just have to write their url (e.g.
https://fpira.com/static/...) in the blog post to get a working preview in iA Writer (provided an Internet connection, of course).
Improving static resources handling
While the above solution works fine, it doesn’t fit in case you have to change your website domain or the
baseurl. Although those aren’t common actions and editing all the posts can be done in batch by a bash script, they break the Jekyll repo concept and best practises.
For this reason, replacing the domain (e.g.
site.baseurl variable is needed.
Option 1: the built-in one
Before exporting from iA Writer to Working Copy or committing on desktop, do a quick Find & Replace right in the text editor.
Option 2: a bit of automation
I wrote a little script for Pythonista, a cool iOS app which provides a full Python IDE and environment.
The script (available here) takes text shared to it as input, performs the substitutions and prompts you the share menu, ready to export text to Working Copy. Look at the video below.
Deploying without SSH-ing: jekyll-deployer
Deploying on the go using an ssh client is cool but typing the same commands over and over is not, so I decided to improve this using Pythonista once again. I wrote jekyll-deployer, a tiny flask app and a Python script to act as client on iOS.
The flask app handles a POST request made the script and notifies to me on the Pushbullet app. To make it dead-simple, there’s no login and security is obtained using a randomly generated 20-chars-long alpha-numeric url. The url is actually a location in the nginx configuration (it acts as proxy to the app listening on port
The POST contains the branch to deploy and a flag to tell the server if that branch is for production deploy. It helps not to put configuration for stable deploys straight into the Pythonista script, just because is much easier to break into our phone than on a good set up VPS. Configuration includes the target directory and the Jekyll command to run (e.g.
jekyll build for stable, and
jekyll build --drafts --future, for testing). Launching the script popups a native iOS menu to let you choose which branch to deploy. You can see it in action below.
The flask app in jekyll-deployer could be modified to handle POSTs from BitBucket/GitHub. That would work as a webhook waiting for pushes to master branch.
Furthermore static resources could be served by a CDN or stored on Amazon S3 with the LFS repo as backup. But this is a topic for another post.
Thanks for reading.
Got some words you want to share? Tell me!