Google Font Builder (code written)

[alicewondermiscreations]

Large number of themes use fonts.googleapis.com to generate a style sheet for webfonts. As in almost every one I have played with. Many of them make mistakes, such as forgetting to request the italic variant of a font which results in browser emulation when italics is needed, which often looks decent but not as good as it could. All of them hardcode fonts.googleapis.com into the theme meaning if (for privacy reasons) a blogmaster wants to switch to a mirror that doesn't track, they have to edit the theme source - which IMHO should be avoided as much as possible.

I wrote a class that takes care of all of this while allowing the blogmaster to optionally change the default hostname for the google fonts URI by setting a define in the wp-config.php.

​https://gist.github.com/AliceWonderMiscreations/b0071e48a27a536142ce38bf6868336b

I believe it belongs in core because it must be loaded before theme developers can make use of it, and WordPress does not have a native way to say "Requires plugin X and load plugin X first" so for theme devs to use it, they would have to include it in their theme source which potentially means many copies installed.

Thank you for your time and consideration. Class is MIT or GPL2 - really I don't care what license it is used with as long as it is OSI approved FLOSS license.

[abdullahramzan]

Hello @alicewondermiscreations,

A warm welcome to you in WordPress Core Trac.

Yeah, agree with you. It should be the part of the core. Let's wait for an authentic opinion.

Thank & Regards,

Abdullah

[alicewondermiscreations]

Note:

The current version of the class I am personally running to implement this is at
​https://github.com/AliceWonderMiscreations/AWonderPHP/blob/master/AWMFontBuilder/AWMFontBuilder.php

It adds a method to destruct an existing font family string, and also adds dns prefetch of fonts.gstatic.com when fonts.googleapis.com is used - which is important because browsers don't start fetching webfonts until they know they need them to render a page, and it's a small performance boost if the dns part is already done.

[ocean90]

Hello @alicewondermiscreations. thanks for your suggestion.

At the moment I don't see much benefit in having such a builder in core. What if my theme is using Typekit or another service instead of Google Fonts?

Many of them make mistakes, such as forgetting to request the italic variant of a font which results in browser emulation when italics is needed, which often looks decent but not as good as it could.

That's probably a good topic to discuss with the ​Theme Review team. Maybe they can create a best practice sheet for using web fonts.

To get more feedback on you builder I suggest to contact a few theme developers and ask them to include the builder in their theme. Until then I'm going to close this as maybelater.

PS: WordPress' minimum supported PHP version is 5.2.4.

[alicewondermiscreations]

A feature existing in core does not mean it has to be used. As far as other services, that's actually why I built it. I personally am not a fan of Google Fonts because of the humongous potential for tracking.

With this class, the blogmaster can change the font server to any font server that has a Google Fonts compatible API - or even run their own with commercial fonts. I actually have code for such a font server under a MIT license on Github and am using it myself.

It allows definition of an alternate to Google Fonts in the wp-config.php file so that any theme who uses this class (or something like it) doesn't need to do anything special for users to use alternate font servers, as long as they are Google API compatible.

And since it is a class, it would be easy to extend it to build font strings for font servers that use a different API.

With respect to minimum version of PHP, I am very sorry but I am what you would classify as financially poor. I simply can not afford the hardware needed to adequately test on a wide variety of versions of PHP. That's why I try to develop for the versions currently supported by upstream PHP - and 5.6 is end of life there with only security patches, I suspect they will stop supporting it when 7.3.0 is initially released.

But of course if this was to get into core, parts of the code (and the coding style - WordPress clearly has not adopted PSR-2) would have to be ported to whatever versions of PHP are intended to be supported by the version of PHP it makes it into.

The class is more of a proof of concept showing it isn't hard to do. Usually only the functions.php file of a theme needs to be modified for the theme to be 100% compatible.

[alicewondermiscreations]

It should be noted that if WordPress had a PSR-4 autoloader and a means of installing class files, this would not need to be in core. It took me under ten minutes to write an autoloader that works well (and also loads PEAR classes), but the feature request in Core is over two years old and looks overly complicated, and doesn't look like it will be in next version either.

I suppose trying to continue to support ancient versions of PHP is probably why.

With a class autoloader, then the class could be used when available and not used when not available, and as long as the autoloader was registered before plugins and themes, any plugin or theme would have access to the classes.

That's probably the right solution but it just seems that an autoloader is not going to happen anytime soon.