I’m trying to install the ThoughtAsylum Drafts Library and I understand that I need to install the core action group which provides a JavaScript library for the other related action groups. The problem is that I can’t find the link to download this core action group. I’ve attached a screenshot of the ThoughtAsylum page in the Drafts action directory for reference.
I must be missing something basic.
Any suggestions?
Charlie
That is the page in the directory for the core group itself. If you scroll to the bottom of that page, there is an “Install” button.
The links are out to the other related groups.
Wel,l I knew it was something basic. Thanks
I’ll join Charlie in the “I’m sure I am missing something basic” department.
I was just listening to the very interesting episode of the always fun and useful Automators podcast with Stephen Millard as their main guest. That’s how I decided to explore ThoughtAsylum myself.
Bravo Stephen if you read this! And thanks for all your work. I had seen some reference to ThoughtAsylum and I might even have installed it together with almost any other action in the repository in my first weeks of fascination with Drafts (also big thanks to Greg Pierce for creating such incredibly useful tool which I also discovered via the Automators podcast!). Even though I still have not managed to get it to work, hearing about what you have accomplished and the amount of work you’ve put into it makes me have a lot of respect and appreciation for you.
Now, here’s the problem. Even though, I made sure I paid attention to Rosemary Orchard’s reminder to install the core action group first, I can’t get any of the actions in ThoughtAsylum to work. When I try, I get the following error message:
“Script Error: Error: The file “tad.js” couldn’t be opened because there is no such file.”
What is the something basic that I’m missing? Can anybody lend me a hand? Thanks in advance.
Josep M.
Having installed that core action group, you also need to run the TAD-Setup/Refresh action from within that group. The action downloads the necessary JavaScript libraries for the other actions.
From the ThoughtAsylum website:
First of all, before you use any of the ThoughtAsylum action groups, you must run the TAD-Setup/Refresh action in this action group. This action will download some JavaScript libraries, one of which the vast majority of actions in the set of ThoughtAsylum action groups are built on.
Hope this helps.
Ooops 
! I was not missing something very basic; I just had not paid enough attention. This is something that was also mentioned in the Automators podcast: Stephen had done a great job with the documentation and people should read the documentation. I obviously didn’t.
My apologies and thanks wightwizard for your help and patience!
Glad to hear folks are trying it out, but I’m wondering, is there anything I can do to make it more obvious that this set-up step has to be run on first download (and subsequent updates)?
It’s at the top of the description of each of the action group descriptions in the directory, but do I need to make the instruction more prominent in some way?
I think there will always be a (large?) proportion of people that don’t read instructions before trying something, be that a new phone, TV or application. Part of the difficulty you face here here is that, in Drafts actions, we are so used to just downloading the action/group and it being ready to use.
I know this would be a pain and don’t know if it would even be possible, but is there a way to trap the missing JavaScript error and change the message to say you need to run this action first or (and this would probably slow execution down) at the start of each action run a test to see if the JavaScript modules exist?
Perhaps you could have the set-up action in an action group of its own at the very top of the list and name the action TAD-Setup/Refresh - RUN FIRST or something of that ilk?
Otherwise, I can’t think of a way to get the message more seen.
Just quick ideas off the top of my head. I don’t know how plausible any of them are.
Thanks for writing and publishing the suite. I have only used a very small percentage of it, but that is expanding as I get to know it. It is a fantastic and useful resource.
Because the call to the main library action (TAD) gets used so frequently I always wanted to keep it as lean as possible on checking and downloading content. Also, there’s a bit of a dance to do about downloading the library files before trying to use them. But on the other hand it is loading an ever growing file, and I do want to make things as easy as possible for people without triggering any of the file checking activities that do slow things down; checking iCloud from Drafts can be slower than expected sometimes and that would not be a great experience when running an otherwise quick action.
I’m going to mull this one over a bit more. I’ve had a few ideas come to mind that are worth exploring I think.
Thanks for making me re-check my thinking on this 
You might start thinking about the large library dependency, in general. It’s pretty fast to load, but not free.
I’ve played around with a variety of actions in the group and haven’t noticed any lag, per se, but there is some point at which having the load that library will be a noticeable hit on performance…especially, say, in an action you use frequently with a keyboard shortcut while typing to format text.
Every time an action that relies on it runs, it has to load the file and the JavaScript interpreter has to compile it.
I have not profiled it, and like I said it’s not noticeable in my testing - but I’m running on recent hardware. I may be overrating it as a possible concern, but worth remaining aware of as your action set grows.
I’ve been keeping an eye on that since day one. I had some issues loading it from file at one point which is why there’s an option hidden away in the core action group to actually load the library from an action. But that issue only lasted for one beta build - I can’t even recall which one it was. Since then it’s simply flown no matter what I’ve run it on, and while my Mac is relatively recent, my i*OS hardware is far from being new!
But rest assured, it will be something I keep an eye on. If it does become an issue, I’ll look into compressing the code. I’m pretty sure I can’t just get away with minifying it. But I’ll tackle that when it’s an issue and I can test against something.
The ThoughtAsylum action groups have been updated today. The update includes auto update of library files, which I hope will make it easier for new and less-tech savvy/experienced users.
While I have attempted to make the checking as performant as possible, it does add some processing overhead.
The automatic checking is enabled by default, but there is an action in the core action group that allows you to toggle the auto update on/off (TAD-Toggle Auto Library Update). The auto update setting is per device (the flag is stored in local file storage - it was faster to access than iCloud in my tests).
The update process worked with my testing, but there’s nothing like real-world use to highlight issues, so I’ll see how it pans out in subsequent updates. I’m considering this feature “in beta” for now. Hopefully it will be smooth, but if it proves too cumbersome I may remove this in the future and revert to the manual only updates. Hopefully, it’ll be fine and it’ll be the best of both worlds.
I’m getting this error 
also.
What I’ve done:
'TAD-Setup/Refresh' actionAny thoughts? Thanks. See below:
That’s very strange! By default, the setup/refresh should no longer be required. There should be a check for what version of the library is required and it should try to update if the library isn’t found. There is a setting to enable/disable this (TAD-Toggle Auto Library Update sets this). When disabled, then you need to run the TAD-Setup/Refresh which will always go and fetch the latest files direct from the web site and put them in your Drafts library.
I ran it this morning after reading this, and it updated the files.
It would be worth looking in your iCloud Drive at the Drafts/Library/Scripts folder just to see if any of the library files are in there.
I’ve not had anyone else report an issue with this as yet, and the process hasn’t had any changes applied to it for several releases. Maybe there is a local issue? Maybe you have an edge case of some sort?
So, what to do? Here’s what I can suggest at this point.
Library/Scripts/ folder. I’m pretty sure that it is standard, but there is always the chance that for some reason it did not get created. If it is not there, create it, and then run the TAD-Setup/Refresh action and see if the JS files get populated into the folder and if you can run the actions.Do let me know what you find, do and the result. The process should not really take any extra troubleshooting, so if there is anything I need to consider and adjust to cover the set-up, I’d like to do so. I dare say that I’ve shaved a few corners for the sake of speed in the auto-updating, but I probably have some wiggle room if I need to add directory existence checks/creation for example.
Hope that helps.
It wasn’t there but when I created it in iCloud and ran the TAD-Setup/Refresh action it created the files and now my actions are working! I’m new to Drafts so it’s possible that I did something wrong along the way. Thanks for the troubleshooting!