A markdown document might contain additional --- for horizontal lines. I think this would break the code of @ccc. If the document is well formed and wrapping the YAML front matter in two --- the following line should work even with more --- in the text:

yaml_dict = yaml.load(editor.get_text().partition('---')[2].partition('---')[0])

I'm a python novice myself, so I hope I'm not talking nonsense.

I just found that this x-callback problem was already reported in this forum 9 month ago.

@omz Can you please have a look into that?

@MartinPacker Depending of the destination app the result is either double escaped text or the same.

@ccc I did not use either of them. Just the built-in escape ([%] button) of the "x-callback url" action. I also tried the "url escape" action with the same result. The latter one gave me the possibility to examine the encoded url by using the "pause before running" option in the following "x-callback url" action.

Yes, the URL is encoded (or escaped to use the naming of Editorial). Both symbols are correctly encoded to %26 and %3d. If you copy the URL including the encoded text and paste it into Safari's address bar, the x-callback is executed like it should.

I ran into a problem with the action "Open x-callback URL". This happens if you want to send the (escaped) text of a document to another app using its url scheme. I'm using an iPhone 5 and an iPad 3, both running 8.4.1.

• If the document text contains the symbol &, only the text up to the symbol is transferred (iPhone and iPad)
• If the document text contains the symbol =, no text is transferred (iPhone and iPad)
• If the document text contains both symbols & and =, either the content of the ios clipboard (iPad) or no text (iPhone) is transferred

To test this I created a simple workflow on both devices:

Step 1: "Get Document Text"
Step 2: "Open x-callback URL" with the url "drafts4://x-callback-url/create?text=Input" (Input is the variable) and the [%] button set.

The problem is not related to the destination app. I tried Working Copy with the same result. I also checked the content of the variable "Input", which is escaped correctly.

Seems to be a bug.