Make WordPress Core

Opened 19 months ago

Last modified 7 days ago

#49742 new defect (bug)

No longer able to enqueue multiple Google Fonts with wp_enqueue_style

Reported by: tannerm Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Script Loader Keywords:
Focuses: Cc:


I'm using wp_enqueue_style to enqueue this Google Font file. Here is my code:

wp_enqueue_style( 'google-fonts', 'https://fonts.googleapis.com/css2?family=Montserrat:ital,wght@0,300;0,400;0,700;1,400&family=Neuton:ital,wght@0,300;0,400;0,700;1,400&display=swap', [] );

This is in my functions.php file.

However, when I view source on my loaded page, the URL for that font file is cut down to: https://fonts.googleapis.com/css2?family=Neuton%3Aital%2Cwght%400%2C300%3B0%2C400%3B0%2C700%3B1%2C400&display=swap&ver=5.3.2

As you can see, the first family param has been removed after being outputted through wp_enqueue_style. Is there a way to fix this without doing anything hacky? I think there may be an outdated way to build the URL to both to come through, but I'd rather be able to use what Google now provides. My original URL inside wp_enqueue_style is the URL generated by Google Fonts for me to embed.

SO post here: https://stackoverflow.com/questions/60953810/why-cant-i-enqueue-multiple-google-fonts-in-wordpress-functions-php/60954323#60954323

Change History (8)

#1 @SergeyBiryukov
19 months ago

  • Component changed from General to Script Loader

#2 @jtleathers
18 months ago

Here was the solution offered to me on the forums

Basically you have to include null as the value for the version parameter. So the following code should work:

wp_enqueue_style( 'google-fonts', 'https://fonts.googleapis.com/css2?family=Montserrat:ital,wght@0,300;0,400;0,700;1,400&family=Neuton:ital,wght@0,300;0,400;0,700;1,400&display=swap', array(), null ); 

#3 @SergeyBiryukov
18 months ago

#50106 was marked as a duplicate.

#4 @Otto42
18 months ago

Copied from #50106 as it is relevant information:

Replying to ocean90:

Noting that wp_parse_str() is currently a simple wrapper for PHP's own parse_str() function. The behaviour we are seeing here is also documented in a user note.

Since we already have this wrapper we could include a possible fix there.

While this behavior does ultimately come from PHP's implementation of parse_str, it seems like something that we should probably handle in the wrapper.

#5 @Otto42
18 months ago

Dangit, posted too early.

There is, however, a concern about the method listed in the documentation (the proper_parse_str() example). Because we're using this to add and remove arguments, then the query string is converted to a PHP array, and then back into a string. This means that if we use a "proper" parse string, then converting it back will lose the multiple-usage information here.

In other words, the naive way would do this:



array( 'key' => array('value1', 'value2') )



Which would be a problem.

So, the information about how that multiple-key use exists needs to be stored somehow, so it can be reproduced properly.

This is just something to keep in mind when making a patch, the proper_parse_str example in the PHP docs won't work for this use case.

#6 follow-up: @leecollings
7 days ago

I have to say I'm absolutely shocked that I've only discovered this issue, and that someone reported it (with a solution) over a year ago. And it still hasn't been fixed in WordPress yet.

This is quite unacceptable. Shouldn't this be a much higher priority than 'new features'?

The information on Google Fonts is therefore misleading (because Wordpress isn't handling it correctly).

I doubt this is featured in your developer docs anywhere for wp_enqueue_style either (unless I'm mistaken).

Very disappointed in the lack of urgency for this.

#7 in reply to: ↑ 6 @Otto42
7 days ago

Replying to leecollings:

I have to say I'm absolutely shocked that I've only discovered this issue, and that someone reported it (with a solution) over a year ago. And it still hasn't been fixed in WordPress yet.

There is no easy way to "fix" this in WordPress. Google decided on a path that is fundamentally incompatible with how the rest of the world uses query variables and thus PHP itself, which WordPress is built atop of, doesn't much like it. They didn't used to do this. No idea why Google changed how their Fonts work in this way.

The workaround is to use "null" for the version parameter when using wp_enqueue_style on Google Fonts, and this is an acceptable workaround since you shouldn't be versioning external style libraries anyway.

In other words, there is no "urgency" here. There is a rather simple workaround, and the problem itself is not in WordPress's code.

#8 @leecollings
7 days ago

Understood, I'm going to watch this ticket anyway. I have a feeling this might be worth following.

Thanks for the resolution anyway.

Note: See TracTickets for help on using tickets.