[wp-trac] [WordPress Trac] #21107: wp_register_resource

[WordPress Trac]

#21107: wp_register_resource
-----------------------------+-----------------------------
 Reporter:  gruvii           |      Owner:
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  General          |    Version:
 Severity:  normal           |   Keywords:
-----------------------------+-----------------------------
 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:


 wp_register_resource(‘Resource-1’,
   array(
     ‘script’=>array(
       ‘handle’=>‘Script-1’,
       ‘src’=>‘Script-1-URL’,
       ‘deps’=>array(’Script-1-A’,’Script-1-B’),
       ‘ver’=>’’)
     ‘style=>array(
       ‘handle’=>‘Style-1’,
       ‘src’=>‘ Style-1-URL’,
       ‘deps’=> array(Style-1-A’, Style -1-B’),
       ‘ver’=>’’,
       ‘media’=>’’)
   )
 )
 [[BR]]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.

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

 2a
 //wp_register_resource($handle, $resources=array(),$deps=array())

 wp_register_resource(‘Resource-2’,
   array(
     ‘script’=>array(
       ‘handle’=>‘Script-2’,
       ‘src’=>‘Script-2-URL’,
       ‘deps’=>array(’Script-2-deps’)
       ‘ver’=>’’)
     ‘style=>array(
       ‘handle’=>‘Style-1’,
       ‘src’=>’’,
       ‘deps’=>array(’’)’,
       ‘ver’=>’’,
       ‘media’=>’’)
   ),
   array(‘Resource-1’)
 );


 wp_enqueue_resource(‘Resource-2’) would:
 [[BR]]wp_register_script(‘Resource-1’,’Scipt-1-URL’……)
 [[BR]]wp_register_style(‘Resource-1’,’Style-1-URL’……)
 [[BR]]wp_enqueue_script(‘Resource-2’, ‘Script-1-URL’,
 array(‘Resource-1’,’Script-1-A’,’Script-1-B’))
 [[BR]]wp_enqueue_style(‘Resource-2’, ‘’, array(‘Resource-1’))

 [[BR]][[BR]]wp_deenqueue_resource(‘Resource-2’)
 [[BR]]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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21107>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software