deanishe

That's not possible with Alfred's built-in actions. You need to write your own workflow that implements the "if URL matches *.sharepoint.com*, open in Chrome in my VM" logic. In Sierra and earlier, you can filter Safari's bookmarks with a File Action, but in High Sierra it has become significantly more complicated to read Safari's bookmarks in a workflow. Basically, you have to parse the property list they live in. Not quite. Ultimately, it needs a valid URL, but it supports the {query} and {var:XYZ} macros in the URL field. So you can set the URL to, say, https://{var:subdomain}.web.sharepoint.com/{var:path} and pass in path and subdomain variables to alter the actual URL that is opened.

No, it isn't. There is the occasional post about a workflow on the Alfred blog, but the actual Alfred team don't appear to be particularly heavy users of workflows. As there's no central source of Alfred workflows, there's no way to calculate a top 10 or the like. I have some stats from Packal that Shawn gave me, but they're very out of date. There are a few places, like the awesome Alfred workflow list, but I'd take that with a pinch of salt, as the main inclusion criterion appears to be submitting a pull request to add a workflow (i.e. actual awesomeness doesn't appear to be a requirement). You can also search GitHub for repos tagged with "alfred-workflow", but a lot of developers put all their workflows in a single repo, and so the utility of the search is somewhat limited by that.

It sounds like you should use a List Filter. Put the URLs, or just the differing parts, in there and connect it to one single Open URL action.

When you create a workflow in Alfred, you can right-click to open it in Finder. You can then drag the folder from Finder to a Save dialog to navigate to that directory. BTW, the docs live at http://www.deanishe.net/alfred-workflow/ I don’t know if the page you’re looking at is up to date.

I have no idea how this File Stream works, but no, If Spotlight doesn’t know about the files, neither does Alfred. If you can enable indexing on the volume, then it will work with both. I suggest you google that, or ask on a Google forum or macOS forum, like Ask Different. Someone on here might be able to help you, but at heart it’s a Google Drive/Spotlight question, not an Alfred one.

I don’t think semver is particularly relevant: workflows don’t usually have a public API. Sure. You can increment it on every release if you want. Google Chrome’s on version 64 already. As a rule, new major versions tend to be synonymous with paid upgrades, which isn’t relevant to free software. If your workflow is associated with an app, you might use the same major version as the app for workflow versions that work with that app version. Otherwise, I don’t think it matters much as long as the version numbers always go up… I tend to go with “significant rewrite/new features = new major version”, but only because that’s what I know from most apps. I haven’t actually tried to develop a concrete concept for versioning.

Does Spotlight find the files? macOS doesn't index remote volumes (except afp:// ones).

It's not quite that simple. A favicon is often tiny (max. 48px), as it's meant to be displayed in browser tabs or bookmark lists. Alfred icons are (ideally) 256px. I agree that it would be pretty cool if Alfred tried to fetch an icon for web searches that don't have one, but if you check the output of RealFaviconGenerator, you'll see that favicons are fairly Serious Business. There's quite a bit of effort involved in extracting the right favicon from an HTML page (assuming an appropriate one is even available). Disagree, tbh. Alfred is fundamentally an English-language tool (its UI is English-only, so Alfred users pretty much need to be comfortable with English). As such, it makes sense to include a bunch of English-language searches, as they're likely to be at least useable for (if not useful to) all users. If Alfred went down the "Baidu rabbit hole" and included Baidu and Yandex etc., there would be a lot of clutter that is of zero interest to the majority of users. What I would suggest instead would be a stickied thread in the forum where we can keep a list of the best web searches for different languages. That way, someone could add a whole bunch of searches for the language(s) they're interested in within a couple of minutes. How does that sound?

Moving this thread to "Closed". It's not an Alfred bug, and I've fixed the issue with the workflow.

Sorry, I forgot to reply to your message. Use "PHP", not "php". Lowercase currencies only work as long as they don't conflict with built-in units. As far as pint (the library that does all the converting) is concerned, p is the prefix for "pico" and hp is "horsepower", so "php" means "picohorsepower".

Update to v3.0.2. Works around an incompatibility of the pint library with non-ASCII paths discovered by @Canor.

It's not. It's an issue with a library the workflow uses. In future, please don't post any issues with workflows in this forum. It's very unlikely that a crashing workflow is due to an Alfred bug, not a bug in the workflow. They belong in the thread for the workflow or the workflow's GitHub issue tracker. If the problem is then determined to lie with Alfred, a post can be opened here. In this case, the problem appears to be with the pint library used by the workflow, or a library used by pint.

The problem is that High Sierra has a different version of Ruby, so the workflow is looking in the wrong directory for its gems. You need to dig around in the workflow and rename the directory the gems are in to match the version number of your installed Ruby (2.3.0). That should fix it.

It can be added as a fallback by adding a Fallback Search trigger, but it would be difficult, and not a great idea (see below), to add them to the default search. As you've probably noticed, the only things that you can add to the default search results that Alfred doesn't natively support are additional filetypes. As such, adding any data that aren't already individual files requires exporting them to individual files and creating an application that declares and handles your new filetype. Trying to do that with browser tabs would require you to run a program that retrieves a list of open tabs from your browser(s) every few seconds via AppleScript. That's going to suck.

Not even a "thank you" for adding 12 new apps?