Replace X with Y

We're always looking to replace something with something else - something new, exciting, shiny, better.

Better is both objective and incredibly subjective. Something can be demonstrably better than something else due to quality, features, ease of use or price. But better is also relative and subject to our personal whims and foibles.

All the features in the world won't make a difference if they don't sit well with our way of doing things or experience. New and improved is often a euphemism for "oh no, they've broken it!"

During a couple of conversations with Tim Nahumck it came up about replacing Ulysses with Drafts once the current beta was stable enough but, the way I have been heading, I would actually love to replace Workflow.

Workflow is fantastic and allows you to perform some pretty complex actions with a single tap but being able to do so much natively within Drafts, without relying on anything else, is an absolute joy.

I make no secret of my concern for the future of Workflow post its acquisition by Apple. While I would absolutely welcome the integration of its capabilities in future versions of iOS, I fear any integration will be limited to the most popular tasks leaving those with less common uses high and dry should Apple decide to sunset the app.

Being a note-taking app, Drafts will never support many of the actions currently made possible by Workflow but its JavaScript engine provides a power that belies its apparent simplicity.

As good as it is, frustrations with how it handles code blocks aside, Ulysses is already on thin ice with really only one use case preventing me from dropping it.

The addition of a few extra features to Drafts would mean that I could almost completely replace both Ulysses and Workflow with something subjectively better due to its self-containment.

1 comment: click to readComments

Indieweb replacements

With a view to replacing Workflow with Drafts (at least as far as is currently possible) I decided to look at posting #indieweb like and replies directly from the app itself.

I was wondering how to pull in the post title using JavaScript but then realised this would just be duplicating effort as my Likes and Replies plugin already does the heavy lifting. All I would need to do was pass the URL as part of the HTTP request so it could be used as the relevant custom field.

The catch, however, is that custom fields are not exposed via the API by default.

Luckily, we can extend the API response and expose extra fields.

Hooking into rest_api_init and using the register_rest_field method you can add a field and specify the callback functions for retrieving or updating that field via the API:

add_action( 'rest_api_init', 'slug_register_like' );
function slug_register_like() {
  register_rest_field( 'post',
      'get_callback'    => 'slug_get_like',
      'update_callback' => 'slug_update_like',
      'schema'          => null,

The above sets up the "Liked" custom field for items of type "post" then defines the functions used to retrieve or update. I've not done anything special, just taken it directly from the API Handbook.

This means that I can update the post data as seen before with the custom field, where url is the web page to be liked or replied to:

"data": {
  "title": draft.title,
  "content": draft.content,
  "status": "draft",
  "format": "status",
  "comment_status": "open",
  "Liked": url

I've then created new actions in Drafts which take the URL from the clipboard, or prompt for one if the clipboard doesn't hold one, and submit a post as before. The only difference is that I have to update the post after submission for the Likes and Replies plugin to trigger.

Performing likes or replies using Workflow meant that I was typing into a small, plain text box. The new aproach means that I can type what I want to say in advance, with the benefits of Markdown support, and then trigger the process.

1 comment: click to readComments


Learning isn't always about having things committed to memory but knowing that they are possible and where to go to remind yourself of how.


Colin Walker Colin Walker colin@colinwalker.blog