Make WordPress Core

Opened 8 months ago

Last modified 7 months 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 (5)

#1 @SergeyBiryukov
8 months ago

  • Component changed from General to Script Loader

#2 @jtleathers
7 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
7 months ago

#50106 was marked as a duplicate.

#4 @Otto42
7 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
7 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.

Note: See TracTickets for help on using tickets.