deanishe

Those are two different themes, as far as Alfred is concerned: Alfred doesn't have a concept of theme variants.
 
To set your light theme, choose an Alfred theme when the macOS colour scheme is light. To set your dark theme, choose a theme when macOS is in dark mode.
 
Alfred will remember those choices and switch between them when the OS switches between light and dark modes.

That's more requirement than preference.
 
Let's assume that Andrew has added the remote-from-anywhere feature exactly as you describe it. So now we have thousands of Alfred users with a new webserver running on their machine, serving a TLS certificate every browser on the planet will show a scary warning about. It's still not accessible from the Internet, of course, because they haven't punched a hole through their firewall with port forwarding yet. That done, they still can't access their machine from the Internet because they don't know how to find their router's WAN IP or they don't know how to set up dynamic DNS.
 
The things I've marked in bold are complex topics, and would cause lots and lots of support requests. As long as that is the case, the feature is effectively off the table.

@jth214 The line numbers in your error log do not correspond to the source code of the current version of the workflow. It looks like you're using an outdated version.
 
Please make sure you're using the latest version of a workflow (or any software, really) before reporting a problem with it: it may have already been fixed.

I am unfortunately a potato... 😕 
 
aha jk okay thank you for the reply and answer

@Mr Pennyworth To find URL schemes supported by an app, reading the ${app_path}/Contents/Info.plist file and looking for CFBundleURLSchemes tag if often enough. Or doing /usr/libexec/PlistBuddy -c 'print :CFBundleURLTypes' "${app_path}/Contents/Info.plist".

But I think you’ll like this more: /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump URLSchemeBinding. It shows every available URL scheme (on your machine).

As to how to use them, that’s the job of the developer’s documentation.

Nvm. Found your github repo (https://github.com/deanishe/alfred-workflow/blob/master/workflow/background.py). I'll go thru this and figure out myself. 
Didn't expect I was getting help from special forces!

i'm going to make this change for the next release, and I'll update the documentation to mention using arg when quicklookurl is not set.
 
If this causes a vast unexpected impact, I'll take a second look.

You don’t need arg: null, you can simply not set it.
 
But I’m curious as to why you want to disable QuickLook. Can’t you just not press the shortcut? And if the problem is that you’re using x-man-page://—assuming all results have it—why not remove that part and add it to the (presumed) Open URL you have later on? Same result, no need for for variables and no QuickLook.
 
That’s the issue with XY problems. There may be a solution that works for your case (like above) but we won’t know for sure unless you explain what the real problem is.

Then you need to not use a keyword that matches loads of other search results.
 
When you open Alfred and start typing, you are performing a regular Alfred search. If the query matches a workflow's keyword, that will also be run, and its results will be integrated with those from the regular search. If you want to run only the workflow, you have to "enter" it by actioning it in Alfred's search results (or using a Hotkey).
 
So to ensure you only get results from one workflow while you’re in Alfred’s main search mode, you need to pick a keyword that won’t match any other stuff. Prefixing your keyword with . usually works well, i.e. use .n, not n, and your query probably won’t match anything but the workflow keyword.
 

The library isn't compatible with Python 3.

Your try ... except is in the wrong place: the script will fail on read 99.9% of the time, not write. But in any case, you generally just put it around the entire per-item code:
 
from __future__ import print_function import json import sys n = 0 # number of files processed for path in sys.argv[1:]: try: with open(path) as fp: data = json.load(fp) with open(path, 'w') as fp: json.dump(data, fp, indent=4, separators=(',', ': ')) n += 1 except Exception as err: # anything written to STDERR goes to Alfred's debugger print('[error] file %s: %s' % (path, err), file=sys.stderr) plural = ('s', '')[n==1] # anything written to STDOUT goes to the next action (i.e. arg/{query}) print('Prettified %d file%s' % (n, plural), end='')  
 
Variables and arg/{query} are two different matters, and Script Filters and regular Run Script actions are two different things again.
 
In this case, you don’t really need to use variables, because you only need one output: the notification. So you can just print the notification text because anything you print becomes the next element’s arg/{query}.
 
Important: If you’re going to get into writing Python, you should stop using /usr/bin/python and use /usr/bin/python3 instead. (You’ll have to use Alfred's External File option for Language and the shebang #!/usr/bin/python3 to do that.) Python 2 is dead and will be gone soon, and Python 3 is easier to use, anyway.

This is my first workflow and my knowledge about coding is very limited so feel free to suggest anything, however small.
Basically this workflow allows you to push (send) any text or the current website to your pushbullet account. This is especially useful for:
those that own multiple devices and want to push something to all devices at once own an android, windows, or chromebook devices and want to bridge the gap with your MacOS device.   
You can download the workflow here.
Instructions
1. Login to Pushbullet.com. 
2. Get your API access token from https://www.pushbullet.com/#settings
3. Paste the token into the script, replacing the <API access token here>.
4. You can type push followed by any text and press return. To send the current tab, type push url.
 
Bonus: if you want to see your android notifications, or push something to your Mac from an android, use Noti.center which also uses pushbullet. You can push something to Mac by pushing it to your android, and it will mirror up to the Mac as well.  

This. Your suggestions can be focussed very tightly on your own specific needs, @Chris Messina. The all-important question is how well or poorly a change or feature would work for all Alfred users. Vítor and I give your requests a bit of a hard time because we're measuring them against that bar.
 
 
But what leads you to think what you're suggesting is the 80%, especially when you're implicitly excluding everybody who'd rather use something other than Markdown from the get-go? Why aren't we talking about the ability to run snippets through any processor? The same end result as far as you're concerned, but also useful to people who don't want to do exactly the same thing as you.
 
 
You'd want to put HTML on the clipboard as well (or perhaps instead), imo. That's the "proper" representation of something like Markdown, and some apps (yeah … Firefox) accept pasted HTML, but not rich text.
 
I think the ability to put multiple arbitrary types of data on the clipboard is more interesting in general, tbh. Without even getting into anything semi-complex like rendering Markdown, the ability to put a URL or file:// URL (or even a file list) on the clipboard would be broadly useful. It's a pain to do in code.
 

Your try ... except is in the wrong place: the script will fail on read 99.9% of the time, not write. But in any case, you generally just put it around the entire per-item code:
 
from __future__ import print_function import json import sys n = 0 # number of files processed for path in sys.argv[1:]: try: with open(path) as fp: data = json.load(fp) with open(path, 'w') as fp: json.dump(data, fp, indent=4, separators=(',', ': ')) n += 1 except Exception as err: # anything written to STDERR goes to Alfred's debugger print('[error] file %s: %s' % (path, err), file=sys.stderr) plural = ('s', '')[n==1] # anything written to STDOUT goes to the next action (i.e. arg/{query}) print('Prettified %d file%s' % (n, plural), end='')  
 
Variables and arg/{query} are two different matters, and Script Filters and regular Run Script actions are two different things again.
 
In this case, you don’t really need to use variables, because you only need one output: the notification. So you can just print the notification text because anything you print becomes the next element’s arg/{query}.
 
Important: If you’re going to get into writing Python, you should stop using /usr/bin/python and use /usr/bin/python3 instead. (You’ll have to use Alfred's External File option for Language and the shebang #!/usr/bin/python3 to do that.) Python 2 is dead and will be gone soon, and Python 3 is easier to use, anyway.

Right yeah, good point: workflows keep running when a Run Script action fails, so your original version also needs some kind of hand-rolled error check before the Write Text File.
 
But the script is inherently fail safe because it will error out decoding the file and never run the code that overwrites it.

One of my workflows logged so much, it broke Alfred.

Your workflow's set up the wrong way for that. A File Action can output an array, and a script can accept multiple arguments (provided you use argv), but most other elements can't handle multiple inputs and will squash them into a single string. Write Text File can only write one file, so if you need to handle multiple files, you have to do it in code. Like this.

Works on my Intel Mac, too, now. Awesome workflow. Extremely well done.

@Cyberskier @JakeS could you try the latest release and see if works on M1 macs?
(I don't have access to an M1 mac)
 
Technical details:
The workflow no longer depends on nodejs

Do you have a recent backup of your system? It sounds as though it's not merely Alfred that's affected so it might be better to restore the system from a recent backup.
 
In passing, I dislike apps like the one you mention and think they do more harm than good. I'm sorry that you've found that out the hard way and hope you can find some way of recovering what you need.
 
Stephen

Hotkeys can use the current selection as input, so you don't necessarily need to copy anything.

When Alfred runs a script or any code you’ve put in a Script box, its puts all your workflow variables in the process environment. {var:task} variable macros don’t work in Script boxes. Use the language’s mechanism for reading environment variables, instead. So in your case – bash – that’s just $task. Same as what you’re doing with $node_path by the looks of it.

I mean how best to implement it in the workflow, not how to make pipes.

Version 3.3
 
What's new?
Support for Firefox  
@deanishe I'm passing a named pipe to your trigger, then parsing the output from that "file".  That should prevent any race condition or polling between calling the trigger and getting the result.
 
GitHub: https://github.com/ajrosen/Alfred
Packal: http://www.packal.org/workflow/lastpass-accelerator

I'm no longer using Hey, but did use it, and it has a web app and a macOS app (which feels like a web wrapper, but I don't know for sure).