Make WordPress Core

Opened 15 years ago

Last modified 6 years ago

#13078 new defect (bug)

Make wp_register_style and wp_enqueue_style consistent

Reported by: koopersmith's profile koopersmith Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Script Loader Keywords: has-patch needs-refresh
Focuses: Cc:

Description

When fixing #13056, I noticed that wp_register_style and wp_enqueue_style had a few odd differences.

  1. Enqueue truncates the $handle variable after the first '?' while register (and all other wp_style functions) accept any string.
  1. Register set the default for $media to 'all', while enqueue set it to false. (fixed in the #13056 patch).

Moreover, since the two functions are practically the same, I've grouped them together in a private _wp_register_style function with an additional $enqueue boolean. Both enqueue and register call _wp_register_style.

I've omitted the truncate behavior mentioned above. If there's any reason for it in one, and not the other, or in both, feel free to correct me.

We could also just remove the truncate behavior from enqueue. It's a minor patch, and comes down to coding style.

Attachments (1)

13078.1.patch (3.4 KB) - added by koopersmith 15 years ago.

Download all attachments as: .zip

Change History (9)

#1 @F J Kaiser
15 years ago

  • Cc 24-7@… added

Wondered about this for a longer time. I use wp_enqueue_style for all themes (not only plugins). Therefore: +1

#2 follow-up: @hakre
14 years ago

  • Keywords needs-patch added; has-patch removed

Yeah both functions should be propagated for theme and plugin authors. A user does not expect a difference in handling the URLs here, so this should be streamlined.

Patch is stale.

#3 @nacin
14 years ago

  • Keywords has-patch needs-refresh added; needs-patch removed

#4 @nacin
14 years ago

  • Milestone changed from Awaiting Review to Future Release

#5 in reply to: ↑ 2 @kitchin
12 years ago

Replying to hakre:

Yeah both functions should be propagated for theme and plugin authors. A user does not expect a difference in handling the URLs here, so this should be streamlined.

The URL parameter is treated the same. The '?' parameter at issue is in the handle, not the URL. The intended use (documented anywhere?) seems to be:

wp_register_style( 'mystyle', plugins_url( 'style.css', __FILE__) );
wp_enqueue_style( 'mystyle?foo=bar');

or

wp_enqueue_style( 'mystyle?foo=bar', plugins_url( 'style.css', __FILE__) );

Either way produces:

<link rel='stylesheet' id='mystyle'
 href='http://domain.tld/wp-content/plugins/my/style.css?ver=3.5.1&#038;foo=bar'
 type='text/css' media='all' />

However this does not work at all:

wp_register_style( 'mystyle?foo=bar', plugins_url( 'style.css', __FILE__) );
wp_enqueue_style( 'mystyle?foo=bar');

Changing this behavior would break any themes or styles using it.

Also when reading the code, be sure to note the difference between "$handle" and "$_handle". Function wp_enqueue_style() only strips the '?' argument so it can register the plain handle. Then it enqueues the handle with the argument. That's why the first two snippets above are equivalent.

Finally, if anyone rewrites the code, it would be great to comment the two different uses of $args in class.wp-dependencies.php. The one we're talking about is part of the WP_Dependencies class. But the $args in the _WP_Dependency class is unrelated and serves as a placeholder for the fifth parameter in the functions used by authors, wp_register_*() and wp_enqueue_*(). So it's $media in functions.wp-styles.php and $in_footer in functions.wp-scripts.php.

I'll add a note to Codex about the first two snippets above.

#6 @kitchin
12 years ago

  • Cc kitchin added

#7 @nacin
11 years ago

  • Component changed from General to Script Loader

#8 @chriscct7
9 years ago

  • Severity changed from minor to normal
Note: See TracTickets for help on using tickets.