Make WordPress Core

Opened 16 months ago

Last modified 15 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
16 months ago

  • Component changed from General to Script Loader

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

#50106 was marked as a duplicate.

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