Your Cart
No products in the cart.

Sarah Gooding
In June 2022, WordPress.org’s Themes Team began strongly urging theme authors to switch to locally hosted webfonts, following a German court case, which fined a website owner for violating the GDPR by using Google-hosted webfonts. For years, theme authors have been enqueuing Google Fonts from the Google CDN for better performance, but this method exposes visitors’ IP addresses.
The Themes Team warned that guidelines regarding locally hosting fonts will be changing imminently and many theme authors moved to comply before it becomes a requirement.
A ticket for bundling Google fonts with WordPress’ legacy default themes had patches and was on track to be included in WordPress 6.1 in November. WordPress contributor Hendrik Luehrsen requested more eyes on the ticket, saying it “directly affects the core WordPress audience in Germany.” He reported that users in Germany were still getting emails threatening fines for using fonts loaded from Google.
WordPress core committer Tonya Mork suggested exploring releasing the updated version of each theme separately from WordPress 6.1.
“When each theme is ready, release it to wp.org’s theme repo,” Mork said. “Users can then update to get locally hosted fonts ahead of when WP 6.1 is released.”
This changed the direction of the ticket and with more scrutiny, contributors found the patches could use some more work.
“Creating new theme versions for this specific change could be good when they are ready,” Stephen Bernhardt said. “Using locally hosted fonts is already recommended, but we need to fix our own themes before we can make this a requirement for others.” He submitted a list of problems and potential improvements after reviewing the patches, and contributors are working on a better approach.
WordPress core committer David Baumwald changed the milestone to 6.2, as Beta 2 for 6.1 was released yesterday and the ticket still needs a final direction and patch.
“While I understand the issue, this is nonetheless sad to see,” Luehrsen said. “This is still a serious issue in Germany (and other GDPR territories), as users with active Google Fonts are currently getting targeted by people exploiting the law.”
Luehrsen took to Twitter to comment on his disappointment with the ticket missing the window for 6.1.
“This is the reason why WordPress will probably lose relevance,” he said. “Real users get hurt here, but they are in GDPR territories and this does not seem to be important.
“Could I have done more? Probably. But it is somewhat sad to see how quickly the momentum on that ticket fizzled out. If Squarespace, Wix and sorts start marketing privacy against WordPress, we’re screwed in GDPR countries.”
In the meantime, those who are using WordPress’ default themes can use a plugin like Local Google Fonts or OMGF | GDPR/DSVGO Compliant, Faster Google Fonts to host fonts locally.
Users can also switch to Bunny Fonts, an open-source, privacy-first web font platform with no tracking or logging that is fully GDPR compliant. Bunny Fonts is compatible with the Google Fonts CSS v1 API so it can function as a drop-in replacement. The Replace Google Fonts with Bunny Fonts plugin makes it easy for users to do that without editing any theme code.
Contributors are working on having fully GDPR-compliant WordPress default themes ready for WordPress 6.2, expected in early 2023.
Hello, are bunny fonts really GDPR compliant?
In fact they say:
“In most cases, the data held and collected by bunny.net does not contain any user-identifiable data. However, in some cases, depending on how you use bunny.net and how your website is structured, personal data may be collected from your users. Such information includes hosting user-uploaded content and personal data that might be transmitted in the URL, User-Agent, or Referer headers of the HTTP protocol.”
Source : https://bunny.net/gdpr/
Looking over the website, they offer more products and services than Fonts, and the impression I got was the GDPR page is in reference to all their products/services. The actual fonts product page https://bunny.net/fonts/ does explicitly say it’s GDPR compliant.
As this service is remote, it means my IP adres must be sent to them as we request the fonts, or they wont be able to send the fonts back to the requesting browser. IPadresses are considered personally identifiable information and under GDPR I must be asked permission to share such information with third parties (bunny in this case) by the website I am visiting. There is no such thing as a remote source that can be loaded without requesting permission; Bunny surely has server access logs that store all the requests (including my IP) to their Fonts.
There is no such thing as a remote source that can be loaded without requesting permission
This is not correct. IANAL but you can be legally compliant and load external services. It is a difficult decision though – Bunny being inside the EU and not being FAANG helps their image a lot.
So many plugins take your IP address. I,as a website owner, will know your IP address when you make a comment on a post (logged in or guest posting).
Most security plugins or any other plugin that blocks people based on IP address, will know the IP address.
Anti-spam Bee (plugin), has an option to allow comments on certain language, I wonder where the database is for anti-spam bee checks to see the language.
All WordPress sites will know your IP address when you make a comment. Obviously the owner/admin will know your IP address and e-mail address. I wonder if all this is GDPR compliant.
There is a big difference between : “I know your IP address as WP site’s owner” and “I use your IP address to collect datas I sell”. I suppose you don’t sell the datas you eventually collect through WP – and nobody will be interested.. Google sells all the data it collects.
Anti-spam Bee uses a service to handle the language mapping. The plugin informs the user about the privacy implications. Also the documentation talks about it.
It’s up to the website owner to set up every thing the right way if this feature is used. Out of the box the plugin is GDPR compliant.
Thank you for your reply.
I’m french and since before GDPR, I’ve been using OMGF to store my fonts locally for performance reasons, so I’ll continue that way.😉
I’ve considered trying out Bunny fonts but decided to keep them localized.
My last few themes that I have released are using local fonts right from the start. Whereas, my older themes are slowly getting a revamp to bring them in sync as well. Some of them are more tricky because they allow users to select any typeface from Google Fonts within a Customizer setting. Unfortunately, there is no easy way to replace that option at this time; I’m still working on it.
I think Anders Norén has already finished doing that with his themes, with the exception of Chaplin.
As for disappointment with the ticket missing the window for 6.1 release, better late to get it right.
Switching to Bunny Fonts is not an option, because it has the very same issue than just using Google Fonts directly – you’re using another service and expose the user’s IP address that visits your site to another service without their consent.
This discussion in yesterday’s core chat was quite disappointing. I really hope to push things forward and have the themes updated before 6.2 as individual theme updates.
I all for hosting things local. However…if we do fonts local then what is next, avatars? no more gravatars. Then what else will be hosted local……..not that I disagree with it per say. I removed Google Analytics long time ago. I never really used “log in with (facebook/twitter/disqus/etc”).
What else are we going to move from third-party product/service to local? Many of us have latest tweet/instagram/etc…on the sidebar.
So many plugins with freemius thing and other plugins asking for “data”.
How do I know they are not getting personally identifiable data?
Moving things locally can have bad “side effects”. Look at Gravatar…….one avatar loaded. Everything going local will mean you will have to upload an avatar for every site you go out there.
GDPR is a headache, not gonna lie. I recently made my site GDPR compliant by having zero requests to other domains and zero cookies set until the user provides consent through the cookie notice. I removed Jetpack, Google Analytics, Gravatar, etc, and put AdSense behind the cookie notice (loads only if user consents). My implementation was custom made because I didn’t want to pay for a third party service and make my site slower with their bloated plugin. Turns out AdSense didn’t like my implementation, thought it was shady, and closed my account. There was nothing shady going on – by default ads were non-personalized and also paused. If user consented, adsbygoogle.js would be loaded, personalization turned on, and ads would be unpaused.
Oh well. Never made much from AdSense anyway. But the thing is, even with all the changes, my site still may not be GDPR compliant because it uses Cloudflare. I simply cannot do without Cloudflare. So while loading the site doesn’t connect to any other domain, it still gets processed by Cloudflare and my web host (which isn’t in Europe).
On the plus side, my site is now extremely fast, if a little more drab than before. I also removed the cookie banner as there was no need for it after AdSense kicked me out.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.

WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable