Opened 5 years ago
Last modified 3 years 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: |
Description
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.
Change History (9)
#4
@
5 years 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 ownparse_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
@
5 years 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:
key=value1&key=value2
becomes
array( 'key' => array('value1', 'value2') )
becomes
key[]=value1&key[]=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-ups:
↓ 7
↓ 9
@
3 years 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
@
3 years 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
@
3 years ago
Understood, I'm going to watch this ticket anyway. I have a feeling this might be worth following.
Thanks for the resolution anyway.
#9
in reply to:
↑ 6
@
3 years ago
Replying to leecollings:
I doubt this is featured in your developer docs anywhere for wp_enqueue_style either (unless I'm mistaken).
Added as a user note to wp_enqueue_style()
and wp_register_style()
docs.
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: