[wp-trac] [WordPress Trac] #20971: Delaying wp_default_scripts() prevents enqueing

[WordPress Trac]

#20971: Delaying wp_default_scripts() prevents enqueing
------------------------------+-----------------------
 Reporter:  nacin             |       Owner:  nacin
     Type:  defect (bug)      |      Status:  assigned
 Priority:  normal            |   Milestone:  3.4.1
Component:  General           |     Version:  3.4
 Severity:  major             |  Resolution:
 Keywords:  has-patch commit  |
------------------------------+-----------------------
Changes (by nacin):

 * keywords:   => has-patch commit


Comment:

 [attachment:20971.2.diff] does the following:
  * On WP_Scripts construction, it has wp_default_scripts() fire
 immediately and again on init, rather than only firing immediately (3.3)
 or only firing on init (3.4). By firing it immediately, this allows a
 default-registered handle to be enqueued prior to init. By firing it again
 on init, it makes sure that all localizations are properly translated.
  * Any localize() calls in script-loader.php are delayed until
 `did_action('init')`. This is necessary because calling localize()
 multiple times does result in duplicative JavaScript. This allows us to
 add scripts immediately but delay their localization until init.
  * `did_action('init')` is true the moment `init` fires (even before it
 completes), and the add_action( 'init' ) to re-fire wp_default_scripts()
 only works before the moment that `init` fires. So normally, WP_Scripts
 would only be instantiated once.
  * It provides coverage in load-scripts.php for did_action()'s use in
 script-loader.

 This works in all of the following issues:
  * When a default handle is registered prior to init. For example, this in
 a plugin:
 {{{
 wp_enqueue_script( 'jquery-ui-droppable' );
 }}}
  * When a default handle that has a localize() component is registered
 prior to init. For example, this in a plugin:
 {{{
 wp_enqueue_script( 'password-strength-meter' );
 }}}
 * When a handle and source is registered prior to init. For example, this
 in a plugin:
 {{{
 wp_enqueue_script( 'some-random-script',
     'http://s.gravatar.com/js/gprofiles.js' );
 }}}
 * When a handle and source that has a localize component is registered
 prior to init. Note that localize() won't re-run on init; so any
 translations *won't work*. We still need localize() to run as they may be
 passing other kinds of data to the script. For example, this in a plugin:
 {{{
 wp_enqueue_script( 'some-random-script',
     'http://s.gravatar.com/js/gprofiles.js' );
 wp_localize_script( 'some-random-script', 'someRandomL10n',
     array( 'test' => __( 'Post' ) );
 }}}

 Wrapping all of these in `add_action( 'admin_enqueue_scripts', function()
 {` and `} );` should similarly get you the same results. The only
 exception would be that someRandomL10n's 'Post' string would properly be
 translated when fired on admin_enqueue_scripts.

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