Dequeueing Open Sans from WP core

hi joshuiaz;
wp core as such only loads google fonts on the admin-pages, where AO isn’t active anyhow. but the theme(s) that ship with wp core indeed also introduce google fonts.

now I’m not sure what theme you’re using, but I’m on twentytwelve and in my child theme’s functions.php I use this to dequeue;

function twtwFFWD_queuing() {
        wp_dequeue_style( 'twentytwelve-fonts' );
}
add_action('wp_enqueue_scripts', 'twtwFFWD_queuing', 11 );

hope this helps,
frank

Hi Frank,

It’s a custom theme using Bones so Open Sans is not being loaded by the theme.

I’ve tried similar functions dequeueing ‘open-sans’ as well as the following plugins:

remove-open-sans-font-from-wp-core
Disable Google Fonts
etc.

None of them work and I still see the WP call to Google Fonts. I know it is from WP because it calls the 300 and 600 font weights.

I’m wondering if something might have changed in WP 4.1.+ or 4.2.2.

Anyway great plugin!

None of them work

You may try this one. Works great for me on Twenty Fifteen, but you surely can adapt it to your theme.

Hmmm, but that’s because you’re logged in, to render the admin-bar, no?

I indeed see this call on my site when logged in;
https://fonts.googleapis.com/css?family=Open+Sans%3A300italic%2C400italic%2C600italic%2C300%2C400%2C600&subset=latin%2Clatin-ext&ver=4.2.2

As this is external CSS, Autoptimize does not touch this.

When not logged in, there’s no such request (me happy).

frank

Unfortunately no. Not logged in, on local install (using MAMP Pro), viewing the front end:

Mixed Content: The page at ‘https://crushtraders.secure:8890/’ was loaded over HTTPS, but requested an insecure stylesheet ‘https://fonts.googleapis.com/css?family=Open+Sans:400,300,600’. This request has been blocked; the content must be served over HTTPS.

@ecdltf tried that as well – no joy.

This has nothing to do with Autoptimize but it’s driving me mad ??

Found the culprit:

Mobile.Nav WordPress plugin from Code Canyon. They have an additional call to Open Sans.

Sorry to bother!!!

no problem. bad practice from mobile.nav not checking is_ssl() and prefixing URL accordingly (or having a scheme-less URL, even easier). there’s a number of ‘force https’-plugins that might help in such situations.

frank

Yep already using WordPress HTTPS but in this case I was able to just comment out the call in the plugin file.

What’s interesting is that since Open Sans is being loaded by WP core you do not need to call it again for the front end at all – it works without explicitly calling it in your theme. I wouldn’t have thought that to be the case.

Thus any plugin would not need to call it at all unless they needed specific weights/styles not included by WP.

yeah, but wp core only injects the call for logged in users, so for anonymous users (the default use case) the request for google font’s open sans would still have to be done?

You are right – Open Sans was displaying for me because I had it installed as a desktop font locally. So yes, you do need it on the front end. Glad you mentioned that and that I checked on another machine ??