Repository: python-discord/site

Issue:
Show font awesome icons in development
<details><summary> Old issue description</summary>

The site uses premium icons, but not all icons we use are premium.

Sometimes it is helpful for us to get a sense of how the icons look like, for free icons, when developing locally. This is especially so in PRs that involve colors or adding icons, such as #1210. My workaround is to change the `fontawesome_token` setting myself, but this is annoying when having to commit multiple changes together (especially when a change in settings.py is involved as well) -- to stage by-patch.

I propose that we add a `FONTAWESOME_TOKEN` to the envs, and then use that value in `settings.py` with the fallback being our actual font awesome token for production.

Files to be modified:
- `settings.py`
- Docs for contributing to site
  - Example `.env`
  - Instructions to how to create your kit on font awesome

---

</details>

**Problem**: We've surpassed the usage limits for the font awesome kit we've set in settings.py, and we need a way for icons to show up consistently in both production and local environments.

**Solutions**: Starting from lemon's first comment.

Further explanation on wookie's suggestion to use the font awesome django plugin:
https://discord.com/channels/267624335836053506/635950537262759947/1202436500856512583
> I meant <https://fontawesome.com/docs/web/use-with/python-django>, which would be a drop in replacement. It just bundles all the js/css/fonts into Django's static files so all that stuff would be served by us and we don't need to worry about kits/tokens/their cdn limits etc. (though the django plugin isn't really necessary for that, it could be better to just copy the files we need into the repo ourself)
> 
> Trying to manage each icon we want individually sounds like a bit more of a pain, the current way the icons are packaged using css and fonts is quite convenient, so I'm not sure if it would be worth adding complication just for a bit of a performance increase. I don't know exactly how that would work though so I can't really tell.


Discussion:
I may be misremembering but I think our font awesome license is from a former staff member that hasn‘t been on the server for a while. Shouldn‘t we then maybe instead try to use free icons (possibly not from FA)?

Are there any significant benefits to moving away from FA?

Either way, using some token that is set to be usable by everyone would be very helpful for development and this issue would no longer be needed.
> I may be misremembering but I think our font awesome license is from a former staff member that hasn‘t been on the server for a while.

I believe we switched to using the free plan so we control the token now.

> The site uses premium icons, but not all icons we use are premium.

Are you sure? I thought we only have the free plan.

Anyway, this proposal sounds sensible, though I don't really understand how fontawesome works. Currently icons seem to display normally in development for me, so would this be for when you want to use an icon that the site doesn't use already, and it's then that it would be useful to try out in development before adding it to the actual site kit?


> Are you sure? I thought we only have the free plan.

Ah, I asked this question in dev-contrib ~years ago~ and Scale told me we use premium icons. I guess this is no longer the case. 

Ref: https://discord.com/channels/267624335836053506/635950537262759947/1106044416566755328 (turns out it's just last year)

> Currently icons seem to display normally in development for me, so would this be for when you want to use an icon that the site doesn't use already, and it's then that it would be useful to try out in development before adding it to the actual site kit?

Really? None of the icons display for me in development. If what Scale said about setting allowed domains is correct, then the token in settings.py does not allow us to fetch icons for origins like 0.0.0.0 or localhost.

But yes, it is useful when we're adding more icons for some page, so we can see how it looks like in development. Note that afaik we don't need to add anything on fontawesome's side if we're just making use of free icons.

This issue was written because of the very fact that I can't see the icons in dev.

And anyway, if our kit is free, is there really a need to limit their usage to only the production site and netlify's preview?
It seems to work for `localhost` (what i've always used) but not `127.0.0.1`. Maybe it's only `localhost` that we set as allowed.

I'm also not sure why we'd need to limit it. I see a list of reasons here https://blog.fontawesome.com/protecting-your-kits-with-domains/ and none of them obviously seem to apply to us. I'll try and find out who has control over it at the moment.


Okay, so:
- I have access to the kit, and can make changes to it.
- But, there's no domain restriction for testing domains like `localhost`, they are always allowed by default.
- The reason it works on our website and not locally is probably because we are way over the included usage limits. we're at almost 20,000 views, only 10,000 are included in the free tier, so then it's gonna fail to fetch them "some of the time" according to FontAwesome. That explains the flakeyness we've seen in this thread.

My proposal for a solution is that we just stop using the kit, and instead just download and include the icons we want. FontAwesome will let us download all the icons for free, so they'd be the exact same, but we'd serve them ourselves.

For example, here's the one for the discord icon on /resources, which is one of the ones we're using FA for.

https://fontawesome.com/icons/discord?f=brands&s=solid

> Shouldn‘t we then maybe instead try to use free icons (possibly not from FA)?

@jchristgit The icons we're using _are_ free, but the problem with moving to something like https://css.gg is that none of those alternative icon sources have stuff like Discord, Goodreads, Github and so on, only FA seems to. I checked like 5 other providers.
It looks like FA has a django plugin, which could make this quite simple https://fontawesome.com/docs/web/use-with/python-django#add-the-font-awesome-free-requirement-and-app
This has become quite annoying while working on my other PRs. I'll solve this myself by implementing wookie's idea if there are no further comments.

Resolving patch:
diff --git a/pydis_site/settings.py b/pydis_site/settings.py
--- a/pydis_site/settings.py
+++ b/pydis_site/settings.py
@@ -369,7 +369,6 @@
         "bulma-dropdown",
         "bulma-navbar-burger",
     ],
-    "fontawesome_token": "ff22cb6f41",
 }
 
 # Information about site repository


Test patch: