realliyifei

I can't tell you anything from 1.5 error messages. Please provide the full error report from the workflow debugger and/or log files.
 
Bear in mind that this workflow is abandonware. If it's not compatible with your version of Safari, I'm not fixing it.

The workflow contains an unsigned binary. All the message means in practice is that the developer didn't pay Apple to not show that warning.

@realliyifei See https://github.com/deanishe/awgo/wiki/Catalina

You enter the variable name in the box, not the value. The default is "focusedapp"
 
You can get the variable in AppleScript with set _appname to (system attribute "focusedapp")
 

Check OneUpdater (disclaimer, I’m the author). It’s a simple way to create update checks for simple Workflows.

OneUpdater is an updater you can plug with minimal configuration into workflows, to keep them up-to-date in users’ machines.

Easiest way to use it is to copy one of its OneUpdater nodes (the pink ones, with the note) to another workflow.

If the workflow actions anything (you press ↵ at some point during usage), copy the top node (Run Script). Connect it to the most used action and double click to edit it. Fill the top variables with the correct values and you’re done.



If the workflow doesn’t action anything (Script Filters with no connections), copy the bottom node (Script Filter) instead and make its Keyword the same as the most used in the workflow. Edit the top variables the same way.

The top lines must be set, and the rest of the code should be left untouched.
remote_info_plist is the URL to the workflow’s up-to-date info.plist on a server. workflow_url and download_type work in tandem. download_type must be one of direct, page, or github_release. When direct, workflow_url must be a direct link to a Workflow file. When page, workflow_url must be a link to a download page. When github_release, workflow_url must be of the form username/repo. frequency_check is the number of day between update checks. Set it to when testing, so it fires on every use.
Example:
readonly remote_info_plist='https://raw.githubusercontent.com/vitorgalvao/alfred-workflows/master/ShortFilms/source/info.plist'  readonly workflow_url='https://raw.githubusercontent.com/vitorgalvao/alfred-workflows/master/ShortFilms/ShortFilms.alfredworkflow' readonly download_type='direct' readonly frequency_check='4'
For it to work you need only update the workflow version in the configuration sheet (which should be done anyway). When any update happens, the user will be informed via a notification. It will be delivered by one of (in order and stopping at the first it finds) notificator, terminal-notifier, or plain AppleScript-called notification.

With both direct and github_release, new Workflow versions will be downloaded directly and opened (github_release grabs the first file from the latest release of the repository). page will open a page on the default web browser.
 
Download | Source

It sounds like you need to put a rich-text hyperlink on the clipboard. Alfred can put RTF on the clipboard, but you'll have to generate the RTF yourself.

It'll be great useful if we can use snippet groups only when some specific applications activated. 

I’m a newbie to both Alfred development and GitHub version control. 
 
I built a new Alfred workflow called Sequential Strings Creator published on Github. 
 
I read some documents such as "Exporting and Sharing Workflows” but still confuse about the mechanism of shared release. 
 
That is, how should I release the next version so that other Alfred users can get it via the bundle ID?
 
I plan to release the next version by the following steps:
 
Clone the repo from Github remote to local Modify the files and fix the bugs Push the new repo back to the GitHub  Release a new version by GitHub with the corresponding alfredworkflow file  
Is it true that by these procedures, this new version would be received by other Alfred users who use this workflow? Otherwise, what else should I do?
 
Also, is there any method to check whether the release is successfully received by others?

Shouldn't be necessary: it defaults to False, IIRC.
 
 
The example in the docs is just a context-free example, not real, working code.
 
I wouldn’t recommend putting the code in the if __name__ == '__main__' clause. It can raise an exception, so it should be wrapped by wf.run(), and it logically belongs with the other item-generation code, not the "execute if this is the main script" code.