[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           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Old description:

> 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.

New description:

 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’=>’’)
   )
 )
 }}}

 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’));
 }}}

 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:
 wp_register_script(‘Resource-1’,’Scipt-1-URL’……)
 wp_register_style(‘Resource-1’,’Style-1-URL’……)
 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.

--

Comment (by scribu):

 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' ),
 ) );
 }}}

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