Diskusie » Spätná väzba ku Greasy Fork
What are the current requirements for script URLs?
For Tampermonkey on Firefox - both https://greasyfork.org/scripts/1.user.js and https://greasyfork.org/scripts/1.user.js?version=1 trigger the install process.
Both last links opened the installation page on kiwi on Android with tamper monkey
I think that user.js is extremely needless to have if possible, but it's interesting to keep the script name instead of a random greasy fork Id.
Violentmonkey on Firefox - both work.
Greasemonkey on Firefox - https://greasyfork.org/scripts/1.user.js works, https://greasyfork.org/scripts/1.user.js?version=1 does not. https://greasyfork.org/scripts/1.user.js?version=1&d=.user.js does. Reported a long time ago but seems like it's a won't fix.
Tampermonkey and Violentmonkey on Chrome both work on both.
OK, I'm sticking with the &d=.user.js thing if there's a version parameter, but dropping the script name in the URL. The reason for this is to have better caching in case the script is renamed.
Could you do like https://greasyfork.org/scripts/latest/1.user.js and https://greasyfork.org/scripts/1.3.0/1.user.js ?
Suggestion
If possible, it would be great if the author can specify the script name in admin panel like
1.my-script.user.js
(only 0-9 a-z and hypen)
But default, it is off. i.e. 1.user.js only.
it will be useful for debug
i.e. {scriptID}.{scriptName}.user.js and {scriptID}.user.js are both available for downloading
Rule for custom naming: /^[a-zA-Z][a-zA-Z0-9-]{2,}$/
Custom naming would help the debug here. Also for users to report issue.
Hmm, so the console will display the filename based on where it was originally downloaded? That's a pretty useful thing...
Hmm, so the console will display the filename based on where it was originally downloaded? That's a pretty useful thing...
Yes.
For violentmonkey, it will be exactly the filename of the downloaded script. (as shown above)
For tampermonkey, it is not that obvious but when the cursor is pointed to the link, the filename will be shown.
OK, I will restore having the script name in the URL for this reason. I'm not going to make it customizable, though; I can't see any reason why you'd want it different than the script name.
I will also take the suggestion of putting the version in the path instead of as a parameter. This however will be the Greasy Fork version ID and not the version provided by the script, as Greasy Fork does not enforce unique version numbers and this would cause ambiguities.
Script URLs will be like this now:
I'm not going to make it customizable, though; I can't see any reason why you'd want it different than the script name.
It is because the script name could be too long.
For example,
The require url will be like this.
which is not human readable and make the @require too long.
The author might choose his own word to make it shorter.
e.g.
site: https://greasyfork.org/scripts/479631-vip-video-autoplay
script: https://update.greasyfork.org/scripts/479631/1279214/vip-video-autoplay.user.js
or it can also accept chinese
with customized name, it can shorten as https://greasyfork.org/scripts/469522-%E8%B6%85%E6%98%9F%E5%AD%A6%E4%B9%A0%E9%80%9A%E4%B9%9D%E4%B9%9D%E5%8A%A9%E6%89%8B
If the name is too long, it is also different to see in console log
I have just checked again your conversation in GitHub issue with another user.
Ignore my previous comments.
Understand that script name can be free to choose.
Might I confirm all these formats are considered as valid?
They all currently work, but eventually they're going to redirect to a specific format. It's not finalized yet.
The URL does not support Cross-Origin Resource Sharing (CORS), when it should send a response header like Access-Control-Allow-Origin: *
used the following urls for comparison.
- https://update.greasyfork.org/scripts/1/test.user.js
- https://greasyfork.org/scripts/1/code/abc.js
- https://cdnjs.cloudflare.com/ajax/libs/jszip/3.1.5/jszip.js
Access-Control-Allow-Origin: *is not yet set for new url.Transfer-Encodinglikechunked,gzipis not provided for new and old url.
What use case does setting the CORS headers have?
HTTP/2 disallows all uses of the Transfer-Encoding header other than the HTTP/2 specific: "trailers". HTTP 2 provides its own more efficient mechanisms for data streaming than chunked transfer and forbids the use of the header. Usage of the header in HTTP/2 may likely result in a specific protocol error as HTTP/2 Protocol prohibits the use.
Greasy Fork has been using a specific format for .user.js and .user.css URLs.
This was done to support user script managers at the time. I'm wondering if this is still necessary today or if we could start using URLs like
Please share if you know if this would work or not. Or try the second set of links (the 1.user.js versions) with your user script manager and let me know if it triggers the installation process.