How to Replace Open Sans in WordPress 3.8
The Background
There was a great discussion between Matt Thomas and the WordPress Core crowd in November having to do with the use of Google Webfonts vs bundling font files in the new admin section for the use of Open Sans. The theory went that there were some huge advantages to using Google Webfonts, especially when it comes to ensuring compatibility in all circumstances. This all stemmed from the desire to use Open Sans in WordPress for the new dashboard theme.
The WordPress Solution
The WordPress team ended up including Open Sans in the admin section and on all public pages when a user is logged in (for the admin bar). This causes an issue when you want to use another configuration of Open Sans for your site.
Your Options
There are two options as we see it:
- Kill the WordPress version and register your own, OR
- Use a secret language setting to turn off Open Sans
Let’s go over the former, kill the WordPress version and register your own.
Option One
Place the following in the functions file for your theme.
function replace_open_sans() {
wp_deregister_style('open-sans');
wp_register_style('open-sans', 'http://fonts.googleapis.com/css?family=Open+Sans:300');
wp_enqueue_style('open-sans');
}
add_action( 'wp_enqueue_styles', 'replace_open_sans' );
View this Gist on Github
This removes the registration of the style WordPress is including for Open Sans. In this case it’s no more than a stylesheet. Afterwards it registers a different version of the style under the same name. In this case I’ve added a version with just one weight and style. From there it enqueues the style for both the admin and public sides of the site.
You can do a lot here to change how this all works. This is just one example. Learn more about wp_deregister_style() and wp_register_style().
Option Two
The other option was surprising at first, but as I started thinking about how people could go about using this feature it made more sense. If you have some time look at /wp-includes/script-loader.php lines 561–582. To give a quick synopsis, take a look at the code below:
/* translators: If there are characters in your language that are not supported
* by Open Sans, translate this to 'off'. Do not translate into your own language.
*/
if ( 'off' !== _x( 'on', 'Open Sans font: on or off' ) ) {
...
}
WordPress is using the translate function, _x(), to check whether the language is supported by Open Sans. That means if you create your own POT file you can turn off the Open Sans embed just by changing the translation file. This might be overkill in this case, but I think it’s a really smart way of ensuring that the typeface will be replaced if your language isn’t supported.
This is a little bit unorthodox of a workaround, but it definitely allows for some flexibility when it comes to whether or not to use Open Sans. If it were up to us I think we’d have leveraged the language being set to determine whether or not to use Open Sans. That being said, I’m sure there was a reason for going about it in this way.
Hopefully WordPress will figure out whether they want to embed Open Sans or bundle the font files in 3.9 (due out in April). I can still imagine this will be helpful once that happens as it seems like Open Sans is here to stay one way or another with the new admin theme. Hopefully this helps.
Learn about our WordPress Development process and why you should be using WordPress for your next project. Have a project in mind?