wp_register_resource — at Initial Version
|Reported by:||gruvii||Owned by:|
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:
‘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 _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_enqueue_script(‘Resource-2’, ‘Script-1-URL’, array(‘Resource-1’,’Script-1-A’,’Script-1-B’))
wp_enqueue_style(‘Resource-2’, ‘’, array(‘Resource-1’))
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.