Push to WordPress v1.1

Push to WordPress Date Picker

When I shared my original workflow that publishing text in Ulysses to WordPress, I knew it wasn’t perfect. When run, Workflow asked for the URL slug, tags, post type, custom field contents, and didn’t actually publish the post — only saving it as a draft, meaning you’d have to hit publish from the WordPress dashboard. All of that has changed with version 1.1 of Push to WordPress.

What makes all this possible is the new template I’m using for writing. I first discussed the new template when I shared my Launch Ulysses Workflow and more recently mentioned it in my update to Push to Ulysses. The latest template is only a slight modification of the original, but makes a world of difference when paired with this new version of Push to WordPress.

The Writing Template

The first line of my template is always the title and uses a second level header for feature articles and a third level header for links. The different headers are important because the workflow uses that information to determine what category to use when publishing and whether or not to look for custom field content.

The second and third line of my template is the URL slug and tags, respectively. This data is grabbed by the workflow with a regular expression and passed on to WordPress automatically. This is perhaps the most important change from the previous version because this information is now saved in Ulysses alongside the post content, rather than only existing in your WordPress database.

After the post tags I leave a line of white space followed by the post content. The white space is there to provide a visual differentiation between the contents of the piece and the administrative information. It could probably be omitted if you’d prefer to — I haven’t tested it, but I’d love to hear if you do.

And when I’m composing links, the URL I’d like in the custom field is placed on the very last line of the Ulysses sheet. This is also separated from the post content by a single line of white space, for clarity. Push to WordPress (v1.1) only looks for custom field content when you’re publishing a link — again, differentiated from feature articles based on the title’s header level.

The Workflow

Push to WordPress (v1.1) is all about streamlining the publishing process. I grew to hate the numerous prompts I was given after initiating Push to WordPress and I made every effort to eliminate as many as possible. I’m happy to say that the new workflow asks for a single piece of information when run — the publish date.

Setting the publish date wasn’t even a feature of the original Push to WordPress workflow. The idea was to give myself an opportunity to preview the piece from WordPress’ dashboard before scheduling it to publish. In real world testing, though, I was almost never hitting the preview button. Rather than continue to pass the user off to Safari to set the publish date, I’ve implemented it within the Workflow.

But there are still occassions where I’d like to preview a post before it goes live. For those instances I’ve added a Copy to Clipboard action immediately following the Post to WordPress action. What this does is save a URL to the clipboard that uses the article’s post ID. If you’d like to preview before publishing, simply choose a future time for publishing and paste the URL into safari after the workflow’s completion. If anything looks off, you’ll have the opportunity to fix it before it goes live.

Another major pain point with the previous version of Push to WordPress was that the workflow asked you to choose the custom field URL from a list. This was due to my own hesitation about allowing workflow to grab it automatically. I was concerned that I’d end up with the wrong URL in my custom field and used the Choose from List action as a crutch.

My concerns weren’t completely unfounded, though. I did run into a problem when publishing links to Daring Fireball articles. After some testing, I realized that Ulysses automatically inserted backslashes, on imported text, before characters that would normally be used to markup text in Markdown. I remedied the bug by implementing a Replace Text action that swaps any instance of a backslash followed by an underscore in the custom field location with just an underscore. Now, as long as you’re following the template guidelines, Push to WordPress (v1.1) never uses the wrong URL or a botched URL for custom fields.

Push to WordPress Version 1.1

Push to WordPress (v1.1) is activated from the “Run Workflow” action extension, when viewing Ulysses’ export screen, and performs the following process:

  • The exported text is saved as the variable “Raw”.
  • The top line of text is isolated with a regular expression, converted to rich text, capitalized with title case, and the result is saved as the variable “Title”.
  • Workflow loads the original input text, removes the first line, and save as the variable “Sans Title”.
  • The new top line is isolated with a regular expression, changed to lowercase, any spaces are replaced with dashes, and the result is saved as the variable “Slug”.
  • Workflow loads the variable “Sans Title”, removes the first line, and saves the rest as the variable “Sans Title Slug”.
  • The first line of “Sans Title Slug” is saved as the variable “Tags” and the rest as the variable “Sans Title Slug Tags”.
  • Workflow asks you to input a date and time and sets it as the variable “Date”.
  • Workflow gets the variable “Raw” — the original input text — and looks at the first line to see if it’s written as header 3, which would indicate that you’re publishing a link.
  • If you’re publishing a link:
    • Workflow gets the variable “Sans Title Slug Tags”, and looks at the last line for URLs, removes any backslashes preceding underscores, and saves it as the variable “Link URL”.
    • The bottom line of “Sans Title Slug Tags” is removed and what’s left is converted into rich text and passed to the Post to WordPress action.
    • Workflow publishes the post with the proper title, tags, URL slug, publish date, and custom field data.
    • The resulting post’s URL is saved to the clipboard for previewing.
  • If you’re publishing a Feature article:
    • The variable “Sans Title Slug Tags” is converted to rich text and passed on to the Post to WordPress action.
    • Workflow publishes the post with the proper title, tags, URL slug, publish date, and custom field data.
    • The resulting post’s URL is saved to the clipboard for previewing.

It’s important to remember that this workflow is designed to accept plain text, written in Markdown, from Ulysses (these are my export settings). My guess is it’ll work with any text editor that can export Markdown as plain text, but I’ve only ever tested it with Ulysses. If you decide to give it a go with another editor, let me know how it works for you.

And of course, it’s unlikely that you’ll be able to use this workflow right out of the box. I doubt there are too many people that have the exact same needs and setup as I do. But the great thing about Workflow is that you can borrow, alter, and extend upon other users’ work until you have ts something that suits your needs. Just think of Push to WordPress (v1.1) as a starting point for your own publishing workflow.

If you’d like more context about where this workflow came from and my thinking behind its initial build, my piece introducing the original version — alongside links to download it — will continue to be available.