I am sure I am missing something very obvious, but I am struggling to get a Things URL to work as desired.
My draft is as follows:
things:///add?title=My Task Name¬es=Some task notes&checklist-items=&when=Tuesday at 7am&deadline=Thursday&tags=MyTag&list=Work&show-quick-entry=true&reveal=true
My action consists just of a URL, where I have selected the “Open in Drafts”, and the “Encode URL tags” options, but when I run the Action I get an error.
If I create the draft and replace the spaces with a %20, disable there URL encode option within the URL action, then the action runs fine, so it seems to something weird going on with the URL encoding.
I have read about the option to wrap the [[draft]] tag with curly brackets to force the draft to be URL encoded, but this does not seem to work.
The annoying thing is, I have had the action working fine in the past, but deleted the action, so I am having to re-create it now.
By the way, the draft is created with a TextExpander snippet, (I type “thingurl” and it takes me to Text Expander where I can fill in things like the Task name, notes, task tags. Dates,deadlines etc…
The output from Text Expander then gets dropped into my draft and I choose my URL action to create the task within Things.
I know I am close, but just need some guidance on what might be wrong.
Sorry to say it, but that actually sounds correct to me, not weird. When encoding you should be encoding data components, not the whole URL. For the example it is sufficient just to encode the spaces. When you encode everything you are encoding parts of the URL that are not data so the output then stops being an actionable URL.
Because your data could contain more than just spaces that need encoding, a one step find and replace of spaces is insufficient.
What you need to do is split out all the component data for encoding, encode them and output the combined total for opening. You have various options around this.
Ones that immediately spring to mind are listed below along with some thoughts on what each approach would mean in practical terms.
This approach would give you a TextExpander snippet available across apps.
Output the content from TextExpander into Drafts in such a way as a Draft action could parse the draft content and encode the relevant sections, and remove whatever temporary markers you may have used. I’m pretty sure just a judicious use of double curly braces to wrap each of the fields you’re capturing in TextExpander for output output into Drafts would be sufficient.
This is probably the least amount of effort from your starting point, but will tie your TextExpander snippet to Drafts only use.
Use a Drafts action (incorporating one or more prompts) to capture and encode the data components and output the URL.
This makes your solution independent of TextExpander, but is probably the most effort to apply as you would be starting from scratch. On the positive side, I suspect it would run faster as you only need one step to trigger and you would be staying within one app.
OK so I finally got some time to dig into this and have the following solution thanks to your suggestions. I only envisaged using this TextExpander snippet within Drafts, so my snippet in TextExpander looks like: