Local custom fonts solution for WordCamp Sites

[aurooba]

Pulling this discussion out of the Make Slack into GitHub:

Now that Google Fonts has come under scrutiny from a privacy perspective, it would be really helpful if we had a way to upload/include custom fonts locally for WordCamp sites. There are third-party plugins available that provide this capability, however, understandably, since this is a large MU network, whatever decision we arrive at needs to be given a lot of thought and consideration.

As we start planning for WordCamp US 2022, we want to be able to use custom fonts but still be as privacy-forward as we can be. I'm happy to help in whatever way I can to expedite this process. :)

[ryelle]

Would the webfonts work done in gutenberg help here at all?

[timiwahalahti]

This might be a bigger issue, as we probably have multiple sites using Google hosted fonts because those are included wc-fonts. In a perfect world, we'd switch Google hosted fonts on all existing sites to be hosted from somewhere else if we want to be extra cautious. What makes that really hard, is the fact that wc-fonts for Google is just a textarea that allows @import's from fonts.googleapis.com 😅

Do I remember correctly @ryelle, that something related to Google fonts was done on the wordpress.org side?

[aurooba]

Would the webfonts work done in gutenberg help here at all?

Perhaps!

Although I had a simpler solution in mind: right now there is no way to upload custom font files into a site (.ttf, .woff, .woff2). If we had the ability to upload font file types, we could just link to them in an @import in Additional CSS or in Remote CSS.I know font files can pose a security risk, is there some way we can mitigate that?

[ryelle]

I don't think we should force WordCamps to switch away from google fonts entirely. We can (probably) add the ability to load local fonts, and existing camps can opt in to using that instead.

something related to Google fonts was done on the wordpress.org side?

Are you thinking of the fonts mu-plugin? This was added for use in wp.org themes, and only loads Inter & EB Garamond.

right now there is no way to upload custom font files into a site

Yeah, I was hoping the gutenberg work, which includes local fonts, might have solved that somehow, but at first glance it looks like not yet. The security implications of loading fonts is probably the biggest issue here, and not something I'm familiar with. Any info on this would be useful 🙂

[0aveRyan]

If we did want to migrate away from Google-hosted fonts, @fontsource is a great API and set of npm packages that make self-hosting Google Fonts easy and pulling from other open foundries like League of Movable Type that aren't all on Google. One benefit of using packages instead of Google-hosted is they're version-locked, unlike the hosted variants, so we can offer legacy versions if/when changes are made that affect existing sites.

Little napkin architecture...

• Hit fontsource API
• Download packages with font files (we could use a config on our end to curate if desired)
• Register fonts using new WordPress Webfonts API and sit behind a CDN

It sounds like the most legwork would be migrating wc-fonts usage of Google Fonts into the Fontsource equivalent, but all the weights, subsets and unicode range are available in the API responses. Also, if anything happens to fontsource, we can continue serving fonts without interruption because they'd be local to the Multisite.

[aurooba]

Fontsource looks awesome. I'm loving the solution you're proposing @0aveRyan!

[aurooba]

They seem to support a number of fonts and support for more can be added as well. https://github.com/fontsource/fontsource/blob/main/FONTLIST.md, while it's not as flexible as add whatever custom font you want it's a very reasonable list to work with.

[0aveRyan]

I won't pretend it's a small amount of work 😅 But it's a potentially viable path (I also believe Jetpack is exploring a Google Fonts integration). If the first pass is just offering new camps self-hosted fonts and then circling back to migrating legacy sites would probably make it a more manageable task and let new camps kick the tires.

But I like that as an API, we could setup a GitHub Action or something to periodically crawl and download/register new fonts as they become available. And that we can preserve font choice while also protecting visitor privacy.

[aurooba]

Agreed. I think offering it as a new feature and later migrating older sites is a good move. This allows anyone to go into their WordCamp site and switch to using the new feature manually instead if they want too, for example, perhaps WordCamp Europe wants to go in and manually switch to using Work Sans from the new API setup instead of using the current setup provided in wc-fonts.

Then later taking any site using the old implementation and migrating it to the new one, after it's been a bit battle tested.

Edited to add:

Keep in mind that unless the Jetpack solution downloads the used font onto the actual site's server, it is still violating the same principle that Google Fonts is violating: sharing IP addresses of visitors with a third-party without their consent. So that's not really a viable solution from a privacy perspective.

[iandunn]

I think this is a duplicate of #584

[aurooba]

@iandunn I did a quick read of #584, it seems that is about adding support for additional third party font hosts. This issue is to add support for local fonts within wordcamp.org to alleviate the privacy issues around pulling fonts from a third party.

[iandunn]

that's a fair point, it'd probably be more accurate to say that adding fontsquirrel here would resolve that one as well 👍🏻

[aurooba]

I can mock something up later this weekend, but I'm thinking that we use something like select2 to allow for multiselect, which populates the fonts from the fontsource fontlist which folks can select.

But we probably want to get pretty granular here right? So that folks are only adding/loading the specific weights/styles of a font they want to use. That could make for a very long and intense list though.

Does it make more sense to keep an updated and accessible list somewhere that is linked from the fonts page instead? Folks choose the ones they want and add it into a text field?

[dd32]

fontsource [....] One benefit of using packages instead of Google-hosted is they're version-locked, unlike the hosted variants, so we can offer legacy versions if/when changes are made that affect existing sites.

I see three major problems with fontsource for our usage:

• WordCamp organisers need a good UI to select fonts, weights, etc. I don't think building the UI ourselves will help anyone.
• The latest version of the fonts is arguably what we want; For some companies using a static version might be more in line with their level of trust, but for us, the latest font is probably what's wanted.
• Being built around npm modules is not helpful for us, although I realise a custom client can be built, it's not providing the same benefit as it would to a designer who is using it from scratch for import into SASS.

---

I think a possible way forward here might be a combination of #584 to allow more font-sources, and then also tacking on a local-hosting mod to it.

There's two options I can think of:

• Download the fonts to the uploads directory upon wc-fonts save, based on the @import rules given
  • There's might be a plugin that could be used here?
  • This has the "downside" that it wouldn't get automatic updates for new font versions. But that might be a compromise that's worth making.
• Proxy the fonts "on demand" from the source, ie. rewrite it from https://fonts.googleapis.com/css2?... to https://wordcamp.org/wp-json/fonts/v1/google?....
  • ie. the wp-json endpoint would load the google url, cache it, and output the fonts as needed.
  • This is probably not-so-good from a caching perspective though, unless a CDN such as s.w.org was used.

Both are not massive amounts of work, but both are more work than ideal, importantly though, it doesn't move the ongoing management of fonts and selection UI to being a WordCamp responsibility. Organisers can still use the Google Fonts/Typekit/Bootstrap (or any future supported font service...) selection UI which is always going to be much better than whatever we have.

[aurooba]

Being built around npm modules is not helpful for us, although I realise a custom client can be built, it's not providing the same benefit as it would to a designer who is using it from scratch for import into SASS.

I'm not sure I understand this point, can you elaborate a bit more? The npm modules are just a way to access the font files, how would that affect a designer? They would still use imports.

Both are not massive amounts of work, but both are more work than ideal, importantly though, it doesn't move the ongoing management of fonts and selection UI to being a WordCamp responsibility. Organisers can still use the Google Fonts/Typekit/Bootstrap (or any future supported font service...) selection UI which is always going to be much better than whatever we have.

I see your point here. The way I see it, we could then just do the same text field setup we have right now, and just download fonts from fontsource if we wanted. All the fonts fontsource serves can be previewed and explored here or at their respective original sources: Google, League, Material.

[dd32]

I'm not sure I understand this point, can you elaborate a bit more? The npm modules are just a way to access the font files, how would that affect a designer? They would still use imports.

My point was that it's "simpler" for usage when building a site using node/sass/etc as a self-contained project: https://fontsource.org/docs/getting-started and using their previewer, also only provides the npm steps: https://fontsource.org/fonts/asap-condensed

It's not designed for a situation like WordCamp, where copy-paste of the @import declarations is "simpler".

Perhaps it's not really that bad though, but the idea is that the npm modules are "simpler" to use, as they wrap everything into one bundle (ie. require open-sans? Download and install the 366 files totalling 7MB) rather than the api which requires you do select which ones to download.

I'm not saying we shouldn't support fontsource, I'm saying, that it's not as straight forward or lightweight as it would be if you were using it with a local package manager.

That all being said, If there's not a standalone fontsource WordPress plugin, I'd probably start with that, and then suggest integrating wc-fonts with that.

[ayuhito]

Although I'm a bit late to this conversation, I'd love to hear in what ways I can add to or change the Fontsource API to better support your usecases if this topic is still relevant (I ended up here after investigating a huge uptick in Wordpress related websites hitting the API aha).

While the project started off as an NPM "convenience wrapper", nowadays I've been nudging the project's goals to democratize the distribution of fonts as the open-source solution, so it may overlap with your needs here.