[greasyfork] Add Greasy Fork service badges

[DenverCoder1]

Closes #8074
Partially resolved issues: #5505, #829

Reverted rating badges

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @DenverCoder1!

Generated by 🚫 dangerJS against 6f06d33

[calebcartwright]

#5157 too

[calebcartwright]

Could you help me understand the difference between daily and total installs, and why the total installs field is represented as users?

[DenverCoder1]

Total installs = total number of installs
Daily installs = average installs per day

I suppose total installs could be under "downloads" instead of users.

I think I will change it to dt (consistent with Eclipse Marketplace)

I was basing it mostly on the "Mozilla Add-on" badges code.

[calebcartwright]

I think I will change it to dt (consistent with Eclipse Marketplace)

Yeah let's do that, dd and dt variants would be consistent with how we handle downloads available over different intervals https://github.com/badges/shields/blob/master/doc/badge-urls.md#badge-url-conventions

[DenverCoder1]

I have updated the code with the discussed change

[calebcartwright]

Thanks for this! This is looking good overall, with a few inline questions and requests for changes below

[calebcartwright]

Everything else looks good to me, so happy to move forward once we get the ratings badges pulled out to a separate PR or issue for discussion

[DenverCoder1]

Thanks, I have removed them from this PR

[calebcartwright]

Thanks a ton! This has been requested a few times over the years so will be nice to get this to users

[Martii]

@DenverCoder1

As I'm not on GF usually you may want to double check multiple licenses and any other key that normally supports more than a single JSON key value pair just like was done on OUJS. As I mentioned on the OUJS PR all key value pairs in all .user.js engines are required to be LIFO. I don't know if GF reverses the arrays for multiple key or not like they should be.

OUJS Admin

[DenverCoder1]

@Martii

As I'm not on GF usually you may want to double check multiple licenses and any other key that normally supports more than a single JSON key value pair just like was done on OUJS. As I mentioned on the OUJS PR all key value pairs in all .user.js engines are required to be LIFO. I don't know if GF reverses the arrays for multiple key or not like they should be.

I have tested it and found that GF does not seem to do anything about multiple licenses. If the key appears multiple times, only the first license appears in the JSON.

As the value appears to only ever be a string, the solution I've done here seems to be the only option unless they change it on their end.

(eg: see https://greasyfork.org/en/scripts/446487/code?version=1060911 and https://greasyfork.org/en/scripts/446487.json?version=1060911)

[Martii]

As the value appears to only ever be a string, the solution I've done here seems to be the only option unless they change it on their end.

Agreed. When he adopted our SPDX code implementation I think he may have missed that long time .user.js standard... perhaps even before that adoption.

[calebcartwright]

TBH I'm not 100% sure I followed all the recent commentary, but it sounds like it's sorted?

@DenverCoder1 - I spotted one last minor thing, and if you could also rebase/merge to get your branch updated with the latest, or allow the maintainers to edit your PR (so our bots can do their thing) that'd be great. We have the branch protection policy enabled that requires branches be up to date, so that will be required for merging

[DenverCoder1]

Yeah, everything should be good.

I'm not sure I see an option to allow maintainer edits and I'm not sure why it would be disabled, but I've gone ahead and merged master.

[calebcartwright]

Yeah, everything should be good.

I'm not sure I see an option to allow maintainer edits and I'm not sure why it would be disabled, but I've gone ahead and merged master.

This article may help, although there could just be something funky going on with GitHub

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork

[DenverCoder1]

This article may help, although there could just be something funky going on with GitHub

docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork

Yeah, I've looked before and I'm still not seeing that option. Possibly it could have to do with contributing from an organization account? I'm not sure.

[calebcartwright]

Possibly it could have to do with contributing from an organization account? I'm not sure.

Yup that's it. Didn't realize your account was setup as an org. Will just be something to keep an eye on for current open PRs and any potential future ones