WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 3 months ago

#13078 new defect (bug)

Make wp_register_style and wp_enqueue_style consistent

Reported by: koopersmith Owned by:
Milestone: Future Release Priority: normal
Severity: minor 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 4 years ago.

Download all attachments as: .zip

Change History (8)

koopersmith4 years ago

comment:1 F J Kaiser4 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

comment:2 follow-up: hakre4 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.

comment:3 nacin4 years ago

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

comment:4 nacin3 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:5 in reply to: ↑ 2 kitchin13 months 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.

comment:6 kitchin13 months ago

  • Cc kitchin added

comment:7 nacin3 months ago

  • Component changed from General to Script Loader
Note: See TracTickets for help on using tickets.