Make WordPress Core

Opened 12 years ago

Closed 9 years ago

Last modified 5 years ago

#21107 closed feature request (maybelater)


Reported by: gruvii's profile gruvii Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Script Loader Keywords:
Focuses: Cc:

Description (last modified by scribu)

Building on the concept of wp_register_script and wp_register_style I would love to see something more general for requiring resources with dependencies. Many times certain scripts require certain styles to be included and vice versa. This could also extend to other resource types as well.

Let's use a basic example of some certain script creatively called Script-1. That Script-1 may have certain scripts and styles or other item on which it is dependent, let’s call them Script-1-A,Script-1-B and Style-1-A, Style-1-B. When you register the script you can of course specify other dependent scripts, but not the dependent styles, or other resource. Of course you can register the styles separately. It may seem trivial that you can then just register Script-1-A, Script-1-B and register Style-1-A, Style-1-B and then wp_enqueue_script (Script-1,array(Script-1-A, Script-1-B)) and wp_enqueue_style(Style-1-A), wp_enqueue_style(Style-1-A) separately. Now let's say you have Script-2 that depends on Script-1. When you call wp_enqueue_script(Script-2) you also have to remember to call wp_enqueue_style(Style-1-A) and wp_enqueue_style(Style-1-B). As the levels of dependency increase or if something changes it gets a lot more difficult to maintain.

My example above only focused on styles and scripts but could apply to other resources such as fonts and/or images that you would like to manage using the flexibility of the WordPress queueing and actions/hooks systems. Sure you could have scripts call the styles themselves but then those styles would not be processed through wordpress and therefore might not take advantage of combining, compressing, caching systems you might have in place in addition to the ability to deregister and change certain items in child themes/skins as easily.

I have a system setup to run hundreds of sites with a core theme that provides common structure, style, scripts and a host of other functionality. Then I have an array of child themes geared towards certain types of sites. Those child themes each can have an unlimited number of skins. The skins can all introduce new functionality and build on the functionalities, styles, scripts, etc of the child theme which builds upon the core theme. This is one of the many cases where being able to just call the single wp_enqueue_resource would greatly help, especially when things change.

Implementation: To implement for just scripts and styles to get started you could make a new “Resources” queue in which each resource could have a list of resources and type. When you enqueue a resource it could call wp_enqueue_script and wp_enqueue_style. Now we would have to add the ability to add a placeholder or null type of item in wp_register_script and wp_register_queue. Because looking at the example I laid out above you would do something like this:

Class Resource might either contain and array of generic resources or could have separate styles/scripts. There are obviously flexibility and performance implications of both methods.

Here is some very rough pseudocode:

      ‘src’=>‘ Style-1-URL’,
      ‘deps’=> array(Style-1-A’, Style -1-B’),

do not call wp_register_style/ wp_register_script upon registering of the resource and wait until this resources or resource requiring this resource is enqueued. This way the style and script are not enqueued separate from the resource and therefore each other since they are dependent on each other. It would however register the resource in the resource queue.

wp_enqueue_resource(‘Resource-1’) would:
wp_enqueue _script(‘Resource-1’, ‘Script-1-URL’, array(’Script-1-A’,’Script-1-B’));
wp_enqueue _style(‘Resource-1’, ‘Style-1-URL’, array(Style-1-A’, Style-1-B’));

wp_register_resource($handle, $resources=array(),$deps=array())

wp_enqueue_resource(‘Resource-2’) would:
wp_enqueue_script(‘Resource-2’, ‘Script-1-URL’, array(‘Resource-1’,’Script-1-A’,’Script-1-B’))
wp_enqueue_style(‘Resource-2’, ‘’, array(‘Resource-1’))

wp_deenqueue_resource(‘Resource-2’) would take dequeue it’s scripts and dependent scripts/styles (assuming those dependent scripts and styles were not enqueued elsewhere)

There are the issues to work out on whether a resource could specify multiple scripts/styles or whether it should just be zero/one of each that listed others as dependencies. Either way can work, just depends on what community thinks.

Change History (6)

#1 @gruvii
12 years ago

Another example I just saw with this is that I had certain skins using a font that was implemented using Cufon. So my core has lots of fonts registered with a script like


and the skins just do something like
wp_enqueue_script('font-A') if that font is needed.

If I decide to implement the font now using a style so it can use font embedding or other I have to change all the calls to wp_enqueue_script('font-A') to wp_enqueue_style('font-A').

If I had used wp_register_resource/wp_enueue_resource I would only have to modify the wp_register_resource declaration and none of the ways that it is enqueued.

Last edited 12 years ago by gruvii (previous) (diff)

#2 @johnbillion
12 years ago

  • Cc johnbillion added

#3 @scribu
12 years ago

  • Description modified (diff)

We have an example of this in Core:

wp_enqueue_style( 'thickbox' );
wp_enqueue_script( 'thickbox' );

could be replaced with wp_enqueue_resource( 'thickbox' ).

I'm not sure about the proposed API. Maybe have wp_register_resource() only reference script/style handles:

wp_register_resource( 'thickbox', array(
  'scripts' => array( 'thickbox' ),
  'styles'  => array( 'thickbox' ),
) );
Last edited 12 years ago by scribu (previous) (diff)

#4 @nacin
10 years ago

  • Component changed from General to Script Loader

Definitely worth considering. Might be safe to close this as maybelater, someone will dig it up later.

#5 @wonderboymusic
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

maybelater suggested 20 months ago

Note: See TracTickets for help on using tickets.