Jekyll Create & Publish

[jarhead]

A simple workflow for creating Jekyll content (posts, drafts & pages). Markdown files are created & opened in Byword for editing. Also keywords for running Jekyll locally (including watching for changes) and publishing via rsync.

 

 

A complete walkthrough available here. Also available on Github.

[vitor]

Why open -a "Byword" ~/jekyll/_posts/"$file" and not simply open ~/jekyll/_posts/"$file"? Not specifying an app would work much better, as users would simply have their default Markdown editor open by default.

[jarhead]

Why open -a "Byword" ~/jekyll/_posts/"$file" and not simply open ~/jekyll/_posts/"$file"? Not specifying an app would work much better, as users would simply have their default Markdown editor open by default.

 

I prefer Byword for my Jekyll posts. All other Markdown files I edit via Sublime Text. You can obviously edit it to your liking.

[vitor]

I prefer Byword for my Jekyll posts. All other Markdown files I edit via Sublime Text. You can obviously edit it to your liking.

To be clear, I’m in no way questioning your preferences. I’m asking since you’re sharing the workflow with the rest of the community, why do it this way, since it uses a specific paid app many may not have? In this situation you could, for example (since the workflow itself already uses a bunch of keyword triggers anyway), have a trigger that would set the default editor, used by all the other commands.

From my experience on these forums, Alfred users like having workflows work just right with their needs/usage patterns (which is natural, giving Alfred’s nature), so having some customisation, specially on that kind of critical options, is a big plus.

[razzi]

I've modified the script to add the correct YAML header as well

 

file=$(echo "$( date '+%Y-%m-%d-' ){query}.md" | tr " " "-")
touch ~/<site>/_posts/"$file" && echo -e "---\nlayout: post\ntitle:  "{query}"\ndate:   $( date '+%Y-%m-%d %T' )\ncategories: \n---" > ~/<site>/_posts/"$file" && open -a "Byword" ~/<site>/_posts/"$file"

[deanishe]

I'd just like to second what Vítor said.

Best to use the default Markdown editor in a distributed workflow. There's no reason to expect that other users have Byword installed, or that they prefer it if they do.

Hard-coding an editor that most users probably don't have installed is a recipe for endless support requests.

[jarhead]

I'd just like to second what Vítor said.

Best to use the default Markdown editor in a distributed workflow. There's no reason to expect that other users have Byword installed, or that they prefer it if they do.

Hard-coding an editor that most users probably don't have installed is a recipe for endless support requests.

 

I really don't see what the problem is. I simply shared MY workflow (per the forum name). It is not hard at all to replace Byword with your editor of choice. You literally replace the text Byword with the name of your editor OR you can modify it to your liking.

[smarg19]

I really don't see what the problem is. I simply shared MY workflow (per the forum name). It is not hard at all to replace Byword with your editor of choice. You literally replace the text Byword with the name of your editor OR you can modify it to your liking.

 

It's just a matter of best practice for sharing workflows. There are certain things that make workflows easier for a wide array of users to download and use. As Vitor said, users would much prefer to download a helpful workflow (which this is) and have it work "out of the box". Many users don't understand and aren't interested in understanding the code under the hood, and won't want to or be comfortable fiddling with the internals of the workflow (how many wouldn't even know how to find the internals?). I've found that it simply kinder to simplify the workflow version that you share on the forums, and then customize your personal version. That works best for everyone.