anyway, I now have a test here locally that successfully checks all of the proposed providers, except for community_bridge, polar, thanks_dev, and obviously custom.

Ok so, after searching GitHub for public funding configs, I found a few possible candidates for issuehunt, ko_fi, buy_me_a_coffee, and thanks_dev, but I can't vouch for their longevity. Unfortunatly, it seems there are some issues, especially with the other two providers:

CommunityBridge

community_bridge's redirect appears to actually be incorrect. For example, something like community_bridge: kubernetes (https://funding.communitybridge.org/projects/kubernetes) redirects to https://crowdfunding.linuxfoundation.org/projects/kubernetes, which is 404. However, going via the site to find Kubernetes leads me rather to https://crowdfunding.linuxfoundation.org/initiatives/kubernetes. (Note the difference of /projects/* and /initiatives/*.) I wonder if we should change our template to the new URL directly, so that even though it's broken on GitHub, Forgejo's works.

Incidentally, I had a lot of trouble finding any serious public funding configs with a community_bridge entry, possibly in part because of the broken redirect, so there's a very slim chance anyone migrating here will find their funding config broken on arrival if Forgejo simply did not support community_bridge. That provider clearly didn't prioritize not breaking its users' profile links with the move, so Forgejo not offering first-class support for it seems reasonable until they become more established again.

On the other hand, given that this is the first provider that GitHub advertises in its doc for this feature, it would be kinda neat if Forgejo happened to have a working version.

Either solution (fix our template past the redirect, or drop support) or any other is ok with me.

Polar

polar has a similar situation, except they didn't even bother with a redirect. After searching GitHub for public funding configs, I came across two which might once have been reliable. One of which is still published, at https://github.com/amalshaji/portr, but the link GitHub presents in the Sponsor modal is broken. Wayback suggests that the link was good as recently as last year. I found another such case from 2024 through an old fork of one of the user's projects (whose original funding config, which only listed polar, no longer exists).

Today, TailwindCSS directs users to https://tailwindcss.com/insiders, which contains a link to Polar, but instead of a profile it's to a checkout form, which may just be a branded Stripe checkout form on a custom domain. The URL is inscrutable, with no trace of a readable username on its own, but the format is familiar to Stripe's, so there's that.

We could simply alter our template for polar to the one that would work with a Stripe Polar customer ID like Tailwind's case, but I think it would be more sustainable to actually remove polar as a built-in option and let users use custom for whatever new shenaniganry Polar comes up with next.

thanks.dev

thanks_dev links work well enough, however it seems to respond HTTP 403 regardless of whether or not the profile actually exists. This completely breaks the mock webserver, which asserts internally that the return status is less than 400. The test would need to either load the webpage to ensure the profile exists, or try to emulate its JS network calls. The easiest fix seems to be to test thanks.dev using Playwright instead. 😕

Ko-fi

This one seems to block Go's default User-Agent header, so changing the header in the mock webserver to something like forgejo-test-client/1.0 instead seems to do the trick here, and probably will continue to do so unless they decide to block this (hopefully very infrequent) test as well.

Comment

Not sure if this is the right place to report this, but it looks like some sort of false positive related to bot-blocking, so here goes..

I followed a link to https://codeberg.org/freebsd/freebsd-ports/src/branch/main/sysutils/desktop-installer, and noticed a scary-looking red banner on top that says "Error 403 when calling /FreeBSD/freebsd-ports/lastcommit/ec77dc5a2c4c1aef7213dc7e06602e89979ae378/sysutils/desktop-installer: Bye".

I can load the main page of that repo just fine, but trying to view most of the direct subdirectories (by clicking on the links on the page) leads to a plaintext page that only says Bye and an error 403 in the net log. This occurs regardless of login state.

Lowercasing the username in the URL at least gets the webpage to load, but then the banner appears, suggesting that the /lastcommit REST call might be triggering some kind of bot trap by getting the username "wrong".

I've tried a repo on my own account, but the site works fine regardless of whether my username is used as-is or lowercased, so I'm not sure what is happening differently with the FreeBSD account's one 😕

I'm not sure it's something that needs to be built right away.

As for where to find funding links to test against, Forgejo's own package-lock.json file might be a place to start, once we get around to doing this.

That makes sense, but I'm not sure it's something that needs to be built right away.

@limiting-factor wrote in #13361 (comment):

Small note, I found found a case of "Hidden as resolved" on GitHub in the wild, and it turns out that anonymous users can reveal those still: https://github.com/rust-lang/rust/issues/154046#issuecomment-4303975612

this implies that GitHub's implementation has different visibility properties for each Hidden reason. That would be an interesting direction to go with this, but I'm not really fond of the verbiage of "Hidden as resolved" tbh. Not sure why just yet, but comment resolution feels like a different feature from Hide this comment I think.

I wonder if there's a way to have the {{svg}} template do a fallback in the event an icon isn't found. That would simplify this part of the code, and let instance admins define logos more easily.

@wetneb wrote in #13435 (comment):

it would be neat to have something like liberapay: forgejo in a funding config in forgejo/forgejo tbh, if the team were willing to maintain the info there alongside the links in various spots in forgejo/website

doc PR: forgejo/docs#2068

Doc change for forgejo/forgejo!13361

@aahlenst wrote in #6994 (comment):

Taking a poke at this, it looks like GitHub's UI requires one of several pre-defined Reason marks, which are as follows:

Drafting for refactor based on discussion at #13435 (comment)