vitor

Welcome @Henriknet, If I understood you correctly, you’re looking for https://www.ebay-kleinanzeigen.de/s-berlin/{query}/k0l3331. The way to figure this out is to complete a search with a dummy search term, then replace it with {query}. That can appear anywhere in the URL, it does not have to be at the end.

It’s not uncommon for people to want their favourite Workflow to show up in the default results. What the request tends to not take into account is how that would affect everyone else’s usage and Alfred’s performance. The choice of what shows up in the default results is very deliberate. It’s a set of predictable results which can always be retrieved fast. It doesn’t matter if it’s a Workflow or an integrated feature, this feature depends on the open app and throws a bunch of results. It’s not predictable and would overwhelm the other entries, which most people wouldn’t want. Making it an optional feature wouldn’t work either, because by now Alfred would have dozens of toggles for each of those, all competing with each other. If you want this Workflow as your default results: Remove your Alfred hotkey.Make a new empty Workflow.Add a Hotkey Trigger. Set it to what was your Alfred hotkey.Connect that to a Run Script Action, with Language /usr/bin/osascript (AppleScript). In the Script box write: tell application id "com.runningwithcrayons.Alfred" to search "KEYWORD_HERE" tell application "System Events" to keystroke "a" using {command down} Replace KEYWORD_HERE with whatever keyword you want, and you’re set. Whenever you press your Hotkey, you’ll get this Workflow running and the text will be auto-selected so you can just type to search something else. If you don’t want the text to be selected, remove the second line from the Script.

I know it does and that there are people using it like that. As long as you can see the files in the Finder, they should be accessible via this Workflow, just change the directory. But like you pointed out, this was made with one specific case in mind. It is optimised for that and is not guaranteed with anything else, because I haven’t tested every other provider.

Added.

You didn’t do that part. You’re not supposed to run the command, you add it to the script. Like so: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" php -f setup.php -- "{query}"

@Erik E Thank you for all the thanks! It’s rewarding to know it’s been a positive impact. As to your new question, go into the code and replace instances of +%D with +%m/%d.

Change set command to to do shell script.

Again, please upload your Workflow. It’s not productive to keep shooting in the dark.

Try https://transfer.sh/ That’s probably your issue. You’re trying to run the PHP interpreter inside the PHP interpreter. In the Run Script, add this line at the top: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and make sure the interpreter is /bin/bash. That should fix it.

Great! So Alfred will be able to search for those. This was only a quick way check if the data is there and searchable. Now that we know, you won’t have to repeat it. Yes, that’s the goal now! Specifically, you’ll use a File Filter.

The dynamic date placeholder doesn’t support that transformation; that would be too complex and it already does a ton as it is. You’ll need a little bit of code. Make a Workflow and add a Snippet Trigger. Connect it to a Run Script Action with default settings and the following code: case "$(date +%A)" in Thursday | Friday) date -v +4d +%D;; Saturday) date -v +3d +%D;; *) date -v +2d +%D;; esac Connect that to a Transform Utility set to Trim white space. Finally, connect that to a Copy to Clipboard Output (check Automatically paste to front most app). In it include your snippet text and use {query} where you want the date to show up. Basically what the code does is check the current day of the week, then add four days to the current date if it’s Thursday or Friday, three days if it’s Saturday; two days any other day.

When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. Debugging can already be hard with access to the code, even more so when all we have is a description.

Missed that one. Now fixed the repo in the Workflow. Just python works and will avoid the same issue in the future (or if you install the Workflow on an Intel machine).

Adding that to the regular search would probably make it slower. It’s the kind of thing which should be a Workflow instead, even if that means requiring a keyword. Here’s a Workflow which lists all running applications. Pressing ↵ on any will switch to it.

Welcome @Blacksmith, Probably yes, but it may depend on how the data is embedded. Here’s something you can try: run the troubleshooting to view file metadata and see if the information you want to search for is there. If it is, great! It means Spotlight indexes the data and Alfred can see it too. If you don’t see what you’re looking for, it will probably still be doable (can only say for sure after examining a couple). It means understanding how the data is embedded and how it can be read, then making a Workflow for it. We can help with that too.

Update. It will specifically not close the window on special actions. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Update. Made some changes and fixes for it to run smoother. But in particular, what you might notice: Turning off will now only terminate itself. This means that if you have other caffeinate processes running from other entities, those will be left alone. When running again to turn it off, if you previously picked a time frame it will tell you when it’s predicted to auto-turn off. Keep in mind that due to the nature of how Apple’s own caffeinate measures its timeout, the time might be somewhat off. The shortcut for preventing the display from going to sleep changed from ⌥ to ⌘. To update, download the latest version (same URL) or wait a few days and it’ll prompt you to on next usage, since it uses OneUpdater.

Welcome @CatsAndCoffee Can’t reproduce at all. Try downloading it again, it was updated recently. It’s useful that you give the machine details, but the Python 3 part is irrelevant. For one, the point of these Workflows is that they have to use Python 2. If you haven’t followed the knowledge base article to install it, these won’t work. But no macOS machine comes with Python 3, so saying it’s running but not how it’s installed is insufficient information. Again, it doesn’t matter in this case, only pointing it out for future debugging.

I cannot force notifications on users, nor would I want to. Permissions for notifications is something you have to control yourself, and that is a good thing.

This makes the code more complex, because in addition to asking the browser to open the window now it also needs to know which browser to do it for. Make a Run Script Action with Language /usr/bin/osascript (JavaScript), and in Script, paste: const frontmost_app_name = Application('System Events').applicationProcesses.where({ frontmost: true }).name()[0] const frontmost_app = Application(frontmost_app_name) frontmost_app.includeStandardAdditions = true const chromium_variants = ['Google Chrome', 'Chromium', 'Opera', 'Vivaldi', 'Brave Browser', 'Microsoft Edge'] const webkit_variants = ['Safari', 'Webkit'] if (chromium_variants.some(app_name => frontmost_app_name.startsWith(app_name))) { frontmost_app.Window().make() } else if (webkit_variants.some(app_name => frontmost_app_name.startsWith(app_name))) { frontmost_app.Document().make() } else { throw new Error('You need a supported browser as your frontmost app') } function run(argv) { frontmost_app.openLocation(argv[0]) } That takes in whatever URL you send from the previous object and opens it in a new tab in the frontmost browser app, whatever that is (again, not Firefox). If you want it to open in a new tab and in a new window, use this instead: function run(argv) { const frontmost_app_name = Application('System Events').applicationProcesses.where({ frontmost: true }).name()[0] const frontmost_app = Application(frontmost_app_name) frontmost_app.includeStandardAdditions = true const chromium_variants = ['Google Chrome', 'Chromium', 'Opera', 'Vivaldi', 'Brave Browser', 'Microsoft Edge'] const webkit_variants = ['Safari', 'Webkit'] if (chromium_variants.some(app_name => frontmost_app_name.startsWith(app_name))) { frontmost_app.openLocation(argv[0]) frontmost_app.Window().make() } else if (webkit_variants.some(app_name => frontmost_app_name.startsWith(app_name))) { frontmost_app.openLocation(argv[0]) frontmost_app.Document().make() } else { throw new Error('You need a supported browser as your frontmost app') } frontmost_app.openLocation(argv[0]) }

Here’s a Workflow for it.

The first thing to understand is that you can’t do this with the default custom searches, you must recreate the ones you want in a Workflow because you’ll need to run code to open the new browser window. So you want it twice with one run?

It’s neither; it’s a directory you can freely inspect by right clicking then “Show Package Contents”. You can just backup the workflows directory from there, but it’s bound to be the biggest one anyway; it makes sense to back up it all.

In theory yes, but in practice a blanket search like that delivers a lot of undesirable results, such as things in ~/Library generated by apps. Those searches work better when focused to specific directories, which is why it’s the solution I ended up with for RecentlyAdded.

Welcome @bo9, It depends entirely on your browser. You need to ask it specifically to open a new window with the search. Here’s an example which searches Google with Safari. If you need something different, please specify throughly what you want to accomplish and which browser you’re using. Quick note: if it’s Firefox, no luck.