My blog site, thecave.com, is a static HTML site generated by Jekyll and hosted on Github Pages. I love that the site is static HTML as it means I can host the site virtually anywhere. But, unlike dynamic blog sites, like those powered by WordPress, I haven’t been able to publish new posts from my iPhone. And with the upcoming release of micro.blog, creating new micro-posts for thecave.com from my iPhone is something I want to do, but how? How can I update my Jekyll site, with its source code hosted on Github and custom plug-ins that can’t run on Github Pages, using my iPhone?
I set out to answer this question, and low and behold; I found the answer. Well, the answer that works for me.
There’s an App for That
First, I need an app on my iPhone that lets me push changes to my site’s Github repository. In other words, I need a git client on iOS. I decided to use Working Copy. It’s a great app and easy to use. Best of all you can try it out for free. The app developer offers a 1-week free trial that lets you push changes to a git repo. After the trial period expires, you must pay to unlock the push feature, but the $14.99 price tag is well worth it in my opinion.
Next, I need a way to write my posts. Working Copy has a Markdown editor built in, which is great for editing existing posts. But there are better editors in the App Store. First, I tried 1Writer since I already have it, and I use it for writing notes and such. Unfortunately, it didn’t play well with Working Copy, so I continued my search for the ideal editor.
Byword, the next app I looked at, looks beautiful, and reviewers have commented how they are using it with Working Copy. But I ended up not trying Byword because I discovered Editorial.
Editorial has a built-in workflow engine, and while this app might not look as pretty as Byword, it is much more powerful, thanks to a built-in workflow engine, and suited to my needs. I bought Editorial right away and started playing with different workflows that already work with Working Copy. After some trial and error, I created two workflows. One lets me publish a post to thecave.com, and the other lets me publish a micro-post.
The difference between the two workflows is subtle. The workflow I use to publish a post lets me pick a category and add tags. The micro-post workflow lets me choose a category and add other tags. For my micro-post to be picked up by micro.blog, I must use the tag “micropost,” and this workflow enforces this rule. Also, my micro-post workflow sets an empty title in the front matter YAML, which brings me to the question…
Why Do I Need These Workflows?
The workflows save me time and simplify the publish steps. For instance, Jekyll uses YAML as front matter for each post. There’s no way I want to write this front matter by hand on my iPhone each time. I can use TextExpander, but seeing the front matter can be distracting on my iPhone. So I let Editorial’s workflow work its magic to generate the YAML front matter before handing off the document to Working Copy.
The workflow also names the file with the appropriate YYYY-MM-DD prefix that Jekyll expects, and it does one other thing for me as well. It sends the appropriate commands to Working Copy so it can add, commit, and push the new document to my git repository. And after Working Copy finishes its job, it returns me back to Editorial.
Simply put, the Editorial workflow lets me publish a new post with just a few taps of my finger.
Sharing My Workflows
I shared my two workflows on Editorial Workflows, which is a directory of workflows. You can use them as is or tweak them to your liking. You must, however, set the key and repo name variables at the start of the workflow as these will be unique to your install of Working Copy.
Using Custom Jekyll Plug-ins
If you are using Jekyll to generate your blog site, and you host your site on Github Pages, then all you need is Editorial and Working Copy to publish new content from your iPhone. That is, assuming you are not using custom plug-ins. If you are not using custom plug-ins, then Github Pages will generate the Jekyll site for you when you push changes to the master branch. I, however, use a custom plug-ins for thecave.com, which means Github Pages will not generate my site for me.
Because I use custom plug-ins, I must generate my site locally using my laptop. This means I cannot publish new content from my iPhone. Or so I thought.
Using Continuous Integration to Build a Jekyll Site
It occurred to me that I can use a build server or continuous integration (CI) environment to build my site when changes are pushed to the master branch. After all, I do this with the iOS apps I make.
My CI of choice is Bitrise. It provides continuous integration and delivery services for mobile apps, but it can also be used to generate a Jekyll site. Best of all, their “free forever” Hobby plan can be used to generate a Jekyll site and push it out to Github Pages. Here’s my bitrise.yml that defines the Bitrise workflow steps that build and publish my Jekyll site.
And That’s How I Do It
That’s how I publish new content to thecave.com using my iPhone. I admit it’s a bit geeky, but know that it is setup, I can publish new posts from iPhone with a tap of my finger.
- Tags And Categories
- Redirect Jekyll Site To HTTPS On OpenShift
- Made Some Fixes To The Blog Site
- Advice for new iOS freelancers
- The Experienced Programmer's Guide to Getting Started with Swift
- From Trace To Slopes
- How To Do A Case Insensitive Search Using Parse SDK
- How To Present An Alert View Using UIAlertController When You Don't Have A View Controller
- My Upcoming Share Extension Talk At 360idev-Min
- Wish I Could Help But It's Not My App