Jump to content

Search the Community

Showing results for tags 'how-to'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Alfred 3
  • Make the Most of Alfred
    • Discussion & Help
    • Bug Reports
    • Alfred Feature Suggestions
    • Themes
  • Alfred Workflows
    • Share your Workflows
    • Workflow Help & Questions
  • Alfred v2 Themes
  • Alfred Remote for iOS
    • Alfred Remote Discussion & Help
    • Remote Connection Troubleshooting


  • Articles
    • Forum Integration
    • Frontpage
  • Pages
  • Miscellaneous
    • Databases
    • Templates
    • Media

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start




Website URL




Found 3 results

  1. Is there a fast/easy way to enable/disable all Workflows? I'm able to Select All Workflows, but the only contextual menus are Category and Delete: Use case: I'm trying to create screenshots of my Workflows and want to isolate on the results from ONE Workflow... which means disabling the rest.
  2. Introduction Alfred workflows are simply zipped directories with an altered extension. Those are great news if you want to automate packaging your workflows for distribution, as you can simply (using ditto in this example, but zip would work just as well): ditto -ck "{{/path/to/your/workflow_directory}}" "{{/path/to/your/output_file}}.alfredworkflow" And that’s it. A zipped directory of your workflow with the custom .alfredworkflow extension. Names enclosed in double curly brackets are examples (they dependend on your situation and must be edited accordingly). Problem The trouble with that solution is that it packages your workflow as it is. Most of the time that won’t be a problem, but it becomes one when you have Workflow Environment Variables with “Don't Export” activated. Alfred knows not to save the value of those variables when exporting your workflow, but your zipping utility does not. Because of that, if you want to package your workflow yourself you need to set those variables (and only those) to empty values. Solution # You need only set these two variables, and the rest will work as is readonly workflow_dir="{{/path/to/your/workflow_directory}}" readonly output_file="{{/path/to/your/output_file}}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${workflow_dir}/info.plist" &> /dev/null; then readonly workflow_dir_to_package="$(mktemp -d)" cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist" /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${tmp_info_plist}" | grep ' ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "set variables:'{}' ''" "${tmp_info_plist}" else readonly workflow_dir_to_package="${workflow_dir}" fi ditto -ck "${workflow_dir_to_package}" "${workflow_file}" So, what does this do? Check the info.plist in your workflow directory for the variablesdontexport property. If the property does not exist, package your workflow directory without any modifications. Our work is done. If the property exists, copy your entire workflow to a temporary directory (we’ll make changes to the info.plist and don’t want to do them on our current one). Check every variable in variablesdontexport and set them to empty values in the info.plist of the copied directory (we don’t want to outright delete the variables as the reference would be lost as well). Package the copied directory. Our work is done. Solution as a script #!/bin/bash readonly workflow_dir="${1}" readonly info_plist="${workflow_dir}/info.plist" if [[ "$#" -ne 1 ]] || [[ ! -f "${info_plist}" ]]; then echo 'You need to give this script a single argument: the path to a valid workflow directory.' exit 1 fi readonly workflow_name="$(/usr/libexec/PlistBuddy -c 'print name' "${info_plist}")" readonly workflow_file="${HOME}/Desktop/${workflow_name}.alfredworkflow" if /usr/libexec/PlistBuddy -c 'print variablesdontexport' "${info_plist}" &> /dev/null; then readonly workflow_dir_to_package="$(mktemp -d)" cp -R "${workflow_dir}/"* "${workflow_dir_to_package}" readonly tmp_info_plist="${workflow_dir_to_package}/info.plist" /usr/libexec/PlistBuddy -c 'Print variablesdontexport' "${tmp_info_plist}" | grep ' ' | sed -E 's/ {4}//' | xargs -I {} /usr/libexec/PlistBuddy -c "Set variables:'{}' ''" "${tmp_info_plist}" else readonly workflow_dir_to_package="${workflow_dir}" fi ditto -ck "${workflow_dir_to_package}" "${workflow_file}" echo "Exported worflow to ${workflow_file}." To use that script, give it a single argument: the path to the workflow you want to package. It’ll save it to the Desktop with the name automatically determined.
  3. Welcome to the bug report forum. You're likely here because you've experienced behaviour in Alfred that feels unexpected. Please ensure you're always using the latest build before reporting an issue, as Andrew works so fast, he might've already fixed the issue and released a new build! In Alfred's Update tab, you can choose "Pre-releases" and grab the latest pre-release. Next, please check the forum for possible solutions to your issue: Use the search as questions and answers may have been posted elsewhere on the forum Check existing bug report threads before creating one as it may already be a known issue If the issue you're seeing hasn't been reported, please post one thread per bug report with the following information: What you were doing when the issue happened Whether you were able to replicate it a second time by performing the same action (Update any third-party apps and restart your Mac if relevant) Include any screenshots that might help us Include the Alfred version & build number you are using Include your macOS version Include the version number of any third-party apps relevant to your issue The clearer the bug report, the more likely and easily we'll be able to fix it! We may ask you to email your Diagnostics file, which you can get by typing "?diagnostics" into Alfred. Once you've reported it, we will test your bug report and, if valid, Andrew will aim to fix it in the upcoming builds. Once fixed, the thread you started will be closed, confirming we have all the information we need to fix it. For those curious about the additional notes in square brackets you might see, we may add these status updates after responding: Accepted: Bug has been moved to our bug tracker and will be looked into soon. Fixed: Bug has been resolved, so check for the latest build if you still encounter this issue. Resolved: Issues that are not bugs but required an explanation/info. Noted: If we're unable to make changes, we'll make a note for future reference and report it to Apple (e.g. macOS bugs) Not a bug: Invalid reports or issues that are not bugs. Please don't post feature requests in this forum as they'll be moved to the Feature Suggestions forum.
  • Create New...