I followed Jaipal_Singh’s steps from here Thought asylum / Alfred 4 workflow issue and got my dlog command working. But somehow it’s only adding to whatever draft I’ve already got going for the day (or sometimes even a past draft), as opposed to creating a new draft and putting the entry there?
I feel so close and yet so far away!
In the immortal words of Leeloo, “Help please?”
Did you try the shared version of the workflow in the thread?
I am not sure how it could match to an old log as it should be matching utilising a date stamp in the title, which I would expect would preclude older logs from being picked up. Can you identify any pattern to this behaviour? I would need a starting point, such as a pattern, to begin tracking this down. Similarly for the draft you have open scenario.
I did try the shared version of the workflow in the thread. That worked for me in the same way, it added to any random draft it could find.
I made a video to show you the action “in action” and my setup in Alfred preferences: CleanShot 2022-04-01 at 16.56.21 · CleanShot Cloud
I’ve just double checked mine is still working okay and no external updates have broken it. It is, so I’m pretty confident it still comes down to something localised for you.
Can you do the following couple of things please?
Until I add this into the next thing, I think the easiest way to get this is by looking at the title of the workflow when you select it in Alfred’s preferences.
The latest release at the time of writing is version 1.7.0
drdiagRun the drdiag Doctor Drafts flow via Alfred. This runs some diagnostics to determine you have everything set up correctly. Put the results (screenshot or copy & paste the text) into your reply - but DO NOT expand/include the Alfred PowerPack or Drafts Pro) subscription information. Those specific details are not relevant here and should not be publicly shared.
For example, here’s how my drdiag results look:
My initial guess is that it isn’t appending to random drafts as you noted in your first reply, but only what draft you have open last as you mention for your example case in the video and I think suggest in your original post. Based on that assumption, it leads me to suspect you may have skipped some of the Doctor Drafts set up instructions, or that something failed when you were following them.
The drlog flow has a block noted as “Match {query} in title and pass out UUID”. It runs a launcher shell script to run a Python script, which executes in the background and identifies what draft is the daily log using the command ./runpythonscript.sh match_title.py $argv.
Ref: You can view details, including the flow layout, for this on the Doctor Drafts web site - Flow: drlog.
I think the script may fail to run, pass back something, but not a UUID for today’s log draft, and the resulting append then defaults to the current/last viewed draft.
But, this is just a first guess based on very limited information and not being able to reproduce the issue. Hopefully, the answers to the questions above will help get a bit closer, and may even confirm my theory.
As a final point of note, in your video it appears you have added your custom dlog flow to the Doctor Drafts workflow. I would recommend against doing this, and instead putting it in a separate workflow. That way you won’t lose anything when you update (and I will continue to put out updates), you won’t accidentally override anything in the original workflow, etc.
I structure my own additional flows like this, and even the examples I use on the website. I do this for exactly these reasons.
Ahhh, many thanks for the instruction on the addition to the workflow - I’ve separated that out now.
I am on the most current version of Doctor Drafts. I had gotten a little overwhelmed by the whole Python instruction set and don’t think I completed it correctly on my first try. But then I got the rest of the way through it and after that I deleted Doctor Drafts and reinstalled it.
I do see that I don’t have as many $PATH variables as you do…
Okay… I noticed that I had no default set and not as many paths as you. The step I got the most stuck on was Step 4.
I will have to google how to reset this and try again (unless you happen to be so kind as to explain but I’m not expecting free labor!).
Looking at that screenshot, your eval command text is trying to be added to the PATH variable. That should be a separate line as in the screenshot from the instructions so that it can be executed as a command. Don’t worry about the other paths. They get added as you do and add more stuff at the command line.
I agree that the shim path should be appearing in your PATH output; hopefuly correcting your .zshrc file will resolve that.
Subsequently, when you get to step 7 in the instructions, that will set your default Python version.
I should add, if you, or anyone else, have any suggestions for making the instructions clearer, do let me know. I wrote those instructions earlier this year because there are so many confusing and convoluted sets of instructions out there that people were having problems following. I figured it was worth me trying to do a clearer one to support Doctor Drafts, but I’m always happy to revise and tweak to make it easier and clearer for future users.
Thanks so much for your time - I went back and tried again starting with step 4 and nothing changed. 
I made a video showing all of the steps and they look successful: CleanShot 2022-04-03 at 20.47.51 · CleanShot Cloud
I’ve watched the video, and there are a few points to note.
eval command on the same line as the PAtH. As shown in the instructions, and as I noted above, you should have these on separate lines as they are separate instructions. As it stands I suspect the computer tries to rcarry out that line and effectively fails as it won’t be able to understand the intent of those two instructions concatenate together like that.zsh several releases ago, which is why I tend to put everything into zsh when I publish. But, there are many possible shells to use. For example my default shell is fish. I would have expected yours to be zsh, but apparently you have stayed on bash or switched to bash. That’s why exec $SHELL could give you a bash shell execution. I’ll have a think about the best place to tweak the instructions for that (I’m thinking maybe ensure the user is switched to zsh explicitly, earlier, just to accommodate this command).Please review the above and check what difference that makes.
Interesting… in settings it says I’m on zsh.
Sorry, I missed the note above about the path entries. Got it now!
How did you get on? Is your issue now resolved?
Thank you for checking in, I got stuck trying to troubleshoot why the command isn’t working for me - as you can see in my screenshot my default is zsh but somehow when I’m following the steps I get switched to bash. I will update here again when I’m able to make any progress on it.
I’m actually having this same issue. I’ve been putting some outputs to check what each step is returning to see if I can figure out where the problem lies.
I’ve found that the step where it calls match_title.py systematically returns the UUID of the currently open draft instead of the one matching the input to the script. Going into the directory containing the python code and calling ./runpythonscript.sh match_title.py "TEST DRAFT TITLE" gives the same result.
If I instead do python3 match_title.py "TEST DRAFT TITLE" I get an empty result (expected as there is no Draft with this title created).
If I run both commands using a title that does appear in my library:
with runpythonscript: UUID of currently open draft
with pyhon3 call directory: UUID of matching draft.
Figured it out: In the event that PYVER_DEFAULT isn’t 3, but PYVER_3 = 3, then the command issued is python3 $1 so it calls
python3 match_title.py
It’s missing the actual argument and should match the call earlier in the script structure of
python3 $1 {@:2}
Would only experience this on systems that dont have a python command but has python3 (from home-brew).
Thanks @Richard_Cool - I’ll have that change out in the next update this weekend 
When I made this change back in January, I put out a call for beta testers as it was quite a big change to how I was triggering Python scripts and unfortunately there was no feedback at that time 
A new version of the workflow, containing this bug fix is now available.
