Bundle the Open Sans font

[johnbillion]

Several contributors are looking at how we can bundle the Open Sans font rather than loading it from Google's CDN as we are currently.

Opening this ticket as there isn't one for this currently.

Previously: #25858.

[SergeyBiryukov]

Related: #26063

[iammattthomas]

This comment from the Make/Core thread has some important considerations around internationalization, file formats, and hinting. ​http://make.wordpress.org/core/2013/11/11/open-sans-bundling-vs-linking/#comment-11426

[samuelsidler]

An updates here? We at least need to make a firm decision on this one way or another before RC.

[dd32]

Unfortunately, as much as I don't want to rely upon a 3rd party, there really isn't any viable option of including Open Sans in core while supporting all languages and browsers.
Fonts (other than SVG) are not designed to have different character subsets conditionally served, they're designed for best compression assuming they'll never be modified after being built.
Since we can't just load every subset of the font (due to file size / loading times, and some browsers not supporting large files), we'd have to include a bunch of permutations of the various files in core.. that'd significantly increase the package size past acceptable limits.

Even with the Google font loading in core right now, it's not ideal for non-English character sets, a translation has to specifically state which character sets to load - that's not something which should be left to a translation.. but it's the best we've got..

So really.. Web fonts are cool, but unless it's being used as something like Dashicons, supporting every browser & language isn't really possible for a web application (without relying upon a 3rd party) and they should probably look and work with what fonts systems provide them with..

[johnbillion]

My preference is strongly to drop Open Sans (as beautiful as it is) if our only option is to continue loading it via Google Fonts.

Sure, Google has almost non-existent downtime, but the reliance is still there. If the Google font service goes down, my admin area becomes a pain in the ass to use. Not to mention working on local sites while offline (it's just about possible to ignore Gravatars that don't load; not so with fonts).

Other concerns raised in ​the make/core thread include privacy and analytics, which should be heeded. We're introducing a default reliance on a third party service whose philosophies may not align with those of WordPress.

tl;dr From a technical point of view, reliance on Google Fonts isn't a great concern. From a philosophical point of view, I'm not so sure.

[dd32]

We're introducing a default reliance on a third party service whose philosophies may not align with those of WordPress.

Not sure if it'd even be possible, but what if Open Sans was loaded from a WordPress.org controlled CDN? basically a caching proxy of the existing Google-hosted font? That is more acceptable to me from a philosophical pov.. but would still raise privacy concerns from some people, and may shift more liability towards wporg in certain cases.

[iammattthomas]

Replying to johnbillion:

Sure, Google has almost non-existent downtime, but the reliance is still there. If the Google font service goes down, my admin area becomes a pain in the ass to use. Not to mention working on local sites while offline (it's just about possible to ignore Gravatars that don't load; not so with fonts).

Could you share what steps you took to experience this result? In all of my testing, when I simulate fonts.googleapis.com being unavailable, my browser simply loads the default sans-serif fallback font.

Other concerns raised in ​the make/core thread include privacy and analytics, which should be heeded.

Mostly what I've seen so far is along the lines of "what if Google..." (tracked us, shut down, whatever). I'm not aware of any concerns backed up by specific examples. If there are specific, documentable concerns we should detail them now so we can figure out how to overcome them.

We're introducing a default reliance on a third party service whose philosophies may not align with those of WordPress.

Webfonts are an enhancement, not a matter of reliance. If we loaded jQuery from an external source, *that* would be a reliance. If the webfonts don't load, the admin doesn't look nearly as nice but no functionality is lost. This mirrors Twenty Twelve's reliance on Google Fonts for Open Sans.

If we're considering philosophical reasons to remove Open Sans altogether or make it an option, the principles of designing for the majority and making decisions, not options are pretty applicable here. The vast majority of WordPress users will never know or care where Open Sans is loaded from, and most users, even if they were given an option to disable linking to Google Fonts, wouldn't use it.

[iammattthomas]

Replying to dd32:

Not sure if it'd even be possible, but what if Open Sans was loaded from a WordPress.org controlled CDN? basically a caching proxy of the existing Google-hosted font? That is more acceptable to me from a philosophical pov.. but would still raise privacy concerns from some people, and may shift more liability towards wporg in certain cases.

I think this would probably be the only good way to serve Open Sans if not from Google; considering the need to have multiple formats of the font available for browser compatibility that currently make bundling a bad solution.

[SergeyBiryukov]

Replying to iammattthomas:

In all of my testing, when I simulate fonts.googleapis.com being unavailable, my browser simply loads the default sans-serif fallback font.

Confirmed.

[mindctrl]

Replying to iammattthomas:

Mostly what I've seen so far is along the lines of "what if Google..." (tracked us, shut down, whatever). I'm not aware of any concerns backed up by specific examples. If there are specific, documentable concerns we should detail them now so we can figure out how to overcome them.

When a page is accessed that requests the Google fonts, the referring URL is sent to Google. To illustrate, I redirected fonts.googleapis.com to one of my own sites, and here are the requests:

x.x.x.x - - [02/Dec/2013:20:59:32 -0500] "GET /css?family=Open+Sans:400italic,700italic,400,700&subset=latin,latin-ext HTTP/1.1" 404 3065 "​http://localhost/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1686.0 Safari/537.36"
x.x.x.x - - [02/Dec/2013:20:59:36 -0500] "GET /css?family=Open+Sans:400italic,700italic,400,700&subset=latin,latin-ext HTTP/1.1" 404 3065 "​http://localhost/jobs-page/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1686.0 Safari/537.36"

Any number of sensitive things could be revealed to Google this way. In my opinion, people shouldn't have to opt out of such privacy issues. Just by using the core WP 3.8 product as it currently is in trunk, people are automatically, and unknowningly, opting in to giving Google information about their habits, interests, products, etc.

[iammattthomas]

Replying to mindctrl:

Any number of sensitive things could be revealed to Google this way. In my opinion, people shouldn't have to opt out of such privacy issues. Just by using the core WP 3.8 product as it currently is in trunk, people are automatically, and unknowningly, opting in to giving Google information about their habits, interests, products, etc.

This still seems like a pretty theoretical concern; I'm not aware of any evidence that Google Fonts is being used for nefarious tracking purposes.

[mindctrl]

Replying to iammattthomas:

This still seems like a pretty theoretical concern; I'm not aware of any evidence that Google Fonts is being used for nefarious tracking purposes.

That's sort of the point. We can't possibly know how they use the information. Why would be decide to do such a thing given these facts?

Maybe better questions are: what benefit does bundling Google Fonts bring to WP core? Are those benefits more important than privacy? Is the world of open publishing best served with this?

I love Open Sans too, and use it often - even from Google. I'm just opposed to bundling any hosted fonts in WP core, with the unknowns.

[johnbillion]

Replying to iammattthomas:

This still seems like a pretty theoretical concern; I'm not aware of any evidence that Google Fonts is being used for nefarious tracking purposes.

It's not about what's done in theory or in practice, it's about principle. I'm not a privacy nut by a long shot, but defaulting to giving a company like Google the opportunity to operate tracking and analytics of the admin area of every WordPress site on the planet doesn't sit well with me.

Maybe it's not such a problem and very few people could care less. Just my two cents.

[jeremyfelt]

+1 for the vote of caution on this. Would prefer we bundle anything that is used by default in the admin.

[nacin]

I would prefer we bundle anything that is used by default, too. But in this case, practically speaking, it is a far inferior option.

Google does some smart things. For example, it conditionally serves the file type (there are four of them) based on the browser. And it is a global CDN. If you visit multiple WordPress sites, that's going to be far faster to use.

The problem with bundling Opens Sans is it is extremely heavy. We're talking six faces, seven character subsets, and four file types. Add those up and you're talking a lot of different combinations — four subset combinations times six faces times four file types. If you bundle everything together and serve all characters to everyone, you're slowing down every single site. Either way, you're adding a lot (we're measuring in the megabytes) to the download package size. Maybe someone could calculate how much, so we're not flying completely blind here.

WordPress still works without this. If you already have Open Sans installed, then that gets used instead. And if you're running WordPress behind a firewall, your browser simply uses the default sans serif font. If Google shuts down the site (which it uses for its own site, and has clearly and openly encouraged others to use), your browser simply uses the default sans serif font.

Something that has been proposed is using the WordPress.org CDN for this. I have zero qualms with this. But, there's a lot that needs to be built to actually serve all of the edge cases. If you want to do the research and scrape the few dozen font packages (and actually build a script to keep them updated — do they get updated?) and implement proper caching headers for the CSS file and such, then do it. There's a ​comment on make/core that describes all sorts of other possible considerations (as well as why trusting Google is probably a better play here), like hinting and CFF and such.

I hate saying this, but vote with your feet. If you want WordPress.org to use its CDN for this, then come up with a plan and patch it. Because I don't have the time for it, and while I enjoy wearing a tinfoil hat from time to time, I also recognize that Google has done some good things for the web, just a few of which are hosting open source libraries and open source fonts. What Google has works, so when I'm wearing my let's-be-practical-here hat, this just isn't a priority for me.

[nacin]

To be clear: this is not a blocker for 3.8's release. 3.8 will ship as-is if there isn't a solution in the works.

[mindctrl]

Replying to nacin:

I would prefer we bundle anything that is used by default, too. But in this case, practically speaking, it is a far inferior option.

WordPress still works without this. If you already have Open Sans installed, then that gets used instead. And if you're running WordPress behind a firewall, your browser simply uses the default sans serif font. If Google shuts down the site (which it uses for its own site, and has clearly and openly encouraged others to use), your browser simply uses the default sans serif font.

I hate saying this, but vote with your feet. If you want WordPress.org to use its CDN for this, then come up with a plan and patch it. Because I don't have the time for it, and while I enjoy wearing a tinfoil hat from time to time, I also recognize that Google has done some good things for the web, just a few of which are hosting open source libraries and open source fonts. What Google has works, so when I'm wearing my let's-be-practical-here hat, this just isn't a priority for me.

I could put on my tin foil hat and ask why only Audrey and Automattic employees are the ones stumping for this while ignoring the legitimate technical and privacy concerns of others. I could grin at the clever attempt to marginalize others with phrases like tin foil hat. I could conflate Google's good deeds and privacy and technical issues.

But I'd rather wear my let's-be-practical-hat, and submit a patch requesting the removal of Open Sans completely, since practically speaking it's the superior option of all.

[matt]

A patch doing something you want but has been decided against might be cathartic, but a plugin disabling or bundling all the Open Sans files could be genuinely useful for people who are concerned about this, or perhaps someone could start to approximate PHP that does the sophisticated serving Google and services like Typekit do, but for core, for 3.8, I think the currently-there solution is the best.

[nacin]

There's still a good solution described in comment 16 for a WP.org CDN solution.

[dimadin]

In make/core thread I already voted for complete removal of Open Sans since I believe it doesn't belong in core considering circumstances.

For anyone concerned, I made a plugin that stops WordPress from loading font stylesheet from Google: ​http://wordpress.org/plugins/disable-google-fonts/

[mindctrl]

@matt: That's the first time I've heard anyone suggest patching WP admin is cathartic, so for the shake-the-walls belly laugh I thank you.

For those of us who don't understand the decision, is there a public archive where the topic of including Google hosted fonts in core was discussed?

@dimadin: thanks for your wonderful plugin.

[rawreef]

Replying to mindctrl:

Just want to add my voice to this debate. I think Open Sans should definitely be abandoned for as long as it has to be loaded from Google's CDN. WordPress's core values are (or should be) completely irreconcilable with Google's when it comes to privacy and personal data.

The thinking on this matter has been completely the wrong way around. Open Sans (yes, it's a gorgeous font – but looks aren't everything, right?! How perfectly a Google-loaded Open Sans demonstrates how shallow beauty can be. But I digress...) should never have been considered until it could be served up from within WordPress itself. The argument "Oh, we'll only rely on Google for the Open Sans font until we can provide it ourselves" is not much different from saying "Oh, I'll only sell out for a couple of years working for this soulless corporation, and then I'll leave and do something worthwhile instead". Ten years down the line, has that person moved on? Seems unlikely. Sorry to be so dramatic, but I think this issue is really, really important.

[iammattthomas]

This is linked at the very top of this ticket, but maybe worth a re-link: ​http://make.wordpress.org/core/2013/11/11/open-sans-bundling-vs-linking/#comment-11426

This comment outlines the things Google Fonts does that would be difficult to replicate in a self-hosted environment. Difficult, but not impossible, I think. I would welcome and be glad to assist anyone interested in making a patch to serve Open Sans locally from within WordPress. If anyone is interested, I'd highly recommend skimming over that entire discussion thread to understand the internationalization and browser support issues behind what stopped us from being able to implement it in 3.8.

[helgatheviking]

Put me down for removing the font. It really drags down my admin speed (esp when working locally) or if something if off with the CDN it destroys it completely... written as I can't administrate my comments because comments.php won't load (And yes, the network console says it is hanging on google fonts).

If the font has to stay, can I move to at least properly enqueue it so that I (and others) can easily disable it?

[SergeyBiryukov]

Replying to helgatheviking:

If the font has to stay, can I move to at least properly enqueue it so that I (and others) can easily disable it?

There's a plugin (linked above) to disable it: ​http://wordpress.org/plugins/disable-google-fonts/.

[helgatheviking]

I already use that plugin. It's great. But it seems weird to tell users to use wp_enqueue_script and then have scripts and styles in core that aren't enqueued. Enqueuing a google script is very simple too. Would make for an easy option in settings.

[SergeyBiryukov]

Replying to helgatheviking:

If the font has to stay, can I move to at least properly enqueue it so that I (and others) can easily disable it?

Related: #28478

[SergeyBiryukov]

#28877 was marked as a duplicate.

[ocean90]

#29761 was marked as a duplicate.

[igmoweb]

If Open Sans is going to stay, shouldn't we add the possibility to change the font URL? Maybe a filter in wp-includes/script-loader.php

$open_sans_font_url = apply_filters( 'wp_open_sans_whatever', "//fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,300,400,600&subset=$subsets" );

At least it makes more sense that unregistering and registering a new one. We could add a comment for the filter that would indicate that setting the URL to an empty one would not break the admin.

[howardtw]

Dear all,

I beg your attention to the following as I re-opened the ticket.

I live in China, please don't hotlink to any Google servers.

Google is effectively blocked in China, so any link to Google server is either very slow, unstable or not accessible most of the time.

So, you are effectively just slowing down more than 800 millions internet users, I think this is a valid reason to re-consider the case?

[ocean90]

The ciscussion can continue while the ticket is closed as maybelater. Once there is a solid plan and patch for an alternative it can be re-opened.

[pavelevap]

I am not sure if this is a problem?

​http://chrislema.com/google-fonts-tos/

[ocean90]

#31552 was marked as a duplicate.

[Hinjiriyo]

As I have showed in my last ticket (#31552) embedding Google Fonts in the WP core raises privacy, security and severe performance problems.

The main reason for using Google Fonts, as mentioned here, is to cover internationalization with serving the right font for as many languages as possible. The new WP functionality to select the language at the beginning of the installation process makes it possible to drop the current solution and to install the right font once.

[ryanhellyer]

Perhaps it would be feasible to build an API into core, which allowed WordPress to download and install fonts directly from the Google Font library. This could be used by both theme authors and in the WordPress admin panel.

[Hinjiriyo]

I would recommend not to download anything from Google by default since there are the described problems. The fonts could be downloaded from wordpress.org or be delivered within the installation package.

[dorianmuthig]

• Is inappropriate change
• Has security implications

As per comment on GitHub: ​https://github.com/WordPress/WordPress/commit/81df9bffc5ffdda9cd7c16dadef21b574f9ee922#commitcomment-11859945 (most recent code change that is relevant to the issue described)
And suggestion from: https://core.trac.wordpress.org/ticket/32552?cnum_edit=9#comment:10

Please make a change and do not load libraries from external sources. This centralizes the failure point and enables the external provider to track all visitors, or worse, inject code in a targeted manner via referrer, domain, IP and public cookie matching. Please include these resources locally with the wordpress installation and make using the local copy the default. In case you'd like to provide users with the option to use a CDN, please do it in a manner which allows and encourages those managing multiple wordpress installations to 1. use their own, 2. verify the script loaded is the right one (lazy load it with JavaScript and verify a checksum) and 3. avoid leaking user's browser behavior to third parties.

[damonganto]

Webfonts are an enhancement, not a matter of reliance. If we loaded jQuery from an external source, *that* would be a reliance. If the webfonts don't load, the admin doesn't look nearly as nice but no functionality is lost. This mirrors Twenty Twelve's reliance on Google Fonts for Open Sans.

​https://github.com/WordPress/WordPress/blob/master/wp-includes/script-loader.php#L172

You all got it the wrong way around.

It should be the responsibility of whoever included Open Sans to begin with to make it not dependent on a third party service (one that has it's own TOS, which is never presented to a user, they just see, at best, the GPL), not "if you don't like it, make a plan and patch it" (hey @nacin).

Open Sans is an enhancement, not a requirement. It is unfortunate that hitting an API server is phoning home, but since that is what it is, it should be treated as such.

On another note, since Open Sans is also imported from a bunch of stylesheets you can't even kill it properly without hacking core.

​https://github.com/WordPress/WordPress/search?q=fonts.googleapis.com+language%3Acss&type=Code

[azaozz]

In 33497:

Press This: properly add Open Sans to the editor, using the mce_css filter.
See #26072. Fixes #33189.

[gmls20]

I have increased the severity of this as it causes page load issues and is also a data privacy issue (forcing users to be bound by an external privacy policy). Additionally, users in several countries cannot access google, and to them attempting to load google services in the background will significantly slow down page load speed.

This embedded font file essentially "phones home" to tell google about the pages a user has been on.

@matt why would you try to close this?

Before next year, Privacy by design is something that we need to incorporate for our users:
​https://en.wikipedia.org/wiki/General_Data_Protection_Regulation#Responsibility_and_accountability

Privacy might not matter to you, but here in europe we are expected to maintain higher standards of privacy for our users.

Embedding google fonts and forcing unsuspecting users to be bound by googles privacy policy is not privacy by design. Forcing users to be straddled in the googlesphere is not ethical.

Google has an extremely poor privacy policy, and has carried out extremely poor privacy practices in the past. Before, they targetted safari browsers to exploit a vulnerability to place tracking cookies on their computer, despite them opting out of accepting 3rd party cookies. They are also the company that "accidentally" collected (and saved) terabytes of wifi data while driving around in their street view cars.

Forcing our users to be bound by google isn't right, and come next year we are expected to ensure our web service incorporates privacy by design.

Forcing 3rd party services by default isn't the right way to go and it sacrifices the independence of wordpress.

My server has more than enough disk space to handle ~400kb max of additional files. Why not bundle it? Why not make wordpress independent?

[damonganto]

Please at least add a proper opt-out toggle via constant (suggestions: WP_PRIVACY, WP_NO_EXTERNAL_DEPENDENCIES, WP_PARANOIA). The current way of using a translator variable seems like a very dirty workaround.

That should also lead to a bunch of CDN-served scripts not being queued (script-loader.php). And possibly disable Gravatar (no idea where and how you'd disable that).

This is mainly useful for users behind firewalls or on Tor Hidden Services.

[superpoincare]

May I know what's happening to this?

[helen]

Closing in favor of #36753.

[dd32]

#42166 was marked as a duplicate.