search

woocommerce / storefront

Official theme for WooCommerce
https://wordpress.org/themes/storefront/
973 stars 471 forks source link

Improve Font Awesome integration #1089

Open uok opened 5 years ago

uok commented 5 years ago

Thanks for the great Storefront theme!

When trying to use the latest Font Awesome via CDN, I noticed that currently it is only possible to use wp_dequeue_style( 'storefront-icons' ); - but this removes font files AND icon definitions.

My suggestion is to split the styles into icons.css (storefront-icons) and fontawesome.css (font-awesome) Then you can use e.g.

wp_dequeue_style( 'font-awesome' );
wp_enqueue_style( 'font-awesome-cdn', '//use.fontawesome.com/releases/v5.8.1/css/all.css' );

Thanks!

ben72 commented 5 years ago

+1 on this one

uok commented 5 years ago

It would be really great if this is implemented, since Font Awesome now constantly releases new icons every couple of weeks. Since version 5.8.1 which is included with Storefront several 100 icons have been added/updated.

uok commented 4 years ago

It would be so great if this change made it into the next release. Font Awesome v5.8.1 is from 2019-03-21, current version is 5.12.1 Thanks!

glagonikas commented 3 years ago

Came across this issue whilst looking for ways to load FA from our own CDN instead of the server.

I agree it would be better if enqueuing FA a different way, or detached to the styles would make things more flexible, so people can enqueue whichever version they like.

As there's currently no other solution we can think of, we resulted in dequeuing icons.css from Storefront, copying to our child theme and modifying the URLs.

As we load our CSS and JS from the CDN, changing the URLs from relative ../../../assets/fonts to absolute /wp-content/themes/storefront/assets/fonts seem to load the font from the CDN instead of our server.

Unfortunately, this is not a great solution because it won't work for sites nested in folders and we'll have to remember to update our version of icons.css every time Storefront is updated, but at least it seems to resolve our issue for now.

p.s our approach might help with #524