Refactor $wp_scripts init checking code

[GaryJ]

The functions in ​functions.wp-scripts.php seem to contain a lot of duplicate code in terms of checking and initializing the global $wp_scripts in each function.

Attached is rough first pass at creating a function to do this. I expect aspects of it could be done better.

I've included the first argument, to avoid relying on a global so that the function might be unit tested (pass something in, see what gets returned).

[GaryJ]

First pass

[scribu]

+1 in general. Note that __FUNCTION__ would have to be passed along.

[scribu]

Second pass

[scribu]

20513.2.diff​:

• accept first parameter by reference, instead of returning
• replaced $fallback parameter with $function

Not really sure if the extra check in wp_localize_script() is worth it. Could just instantiate anyway.

[scribu]

wp_scripts()

[scribu]

20513.3.diff​ replaces wp_scripts_maybe_initialize() with wp_scripts(), so you can do:

wp_scripts()->do_items( $handle );

etc.

[scribu]

I don't think this init code is relevant for unit testing. If you want to unit test WP_Scripts, just create an instance manually.

[GaryJ]

That looks good to me.

Might be another ticket, but I suspect something similar can be done with $wp_styles too.

[azaozz]

Think I attempted to do something similar for 3.2 (or was it 3.3). The argument against it is that this breaks the backtrace so if a plugin author calls any of these functions too early _doing_it_wrong() would show the wrong reference.

[scribu]

If the function reference is so important, we could pass it along:

wp_scripts( __FUNCTION__ )->do_items( $handle );

[SergeyBiryukov]

Related: [18561]

[GaryJ]

Related discussion: #11526.

How expensive is debug_backtrace( false )?

How many themes and plugins are still firing these functions before init action has occurred? (Nacin's relatively recent post might have reminded some of the authors to be using the wp_enqueue_scripts hook.)

Could wp_debug_backtrace_summary() be used to pinpoint the original function called?

While scribu's suggestion may well work, it seems dirty to be including an argument purely for debugging purposes.

[SergeyBiryukov]

Replying to GaryJ:

How many themes and plugins are still firing these functions before init action has occurred?

Plugins: ​http://pastebin.com/szGUhsp0 (may have some false positives due to a lack of whitespace).
Themes: ​http://pastebin.com/bbM47tG8 (tried to filter out false positives).

[wonderboymusic]

[20513.4.diff] makes 2 funcs, could work

[wonderboymusic]

Related: #25666

[wonderboymusic]

In 31192:

functions.wp-scripts.php contains a lot of duplicated code. Make 2 new functions: wp_scripts() and wp_scripts_maybe_doing_it_wrong( $function ), to encapsulate the repeated logic.

Props GaryJ, scribu, wonderboymusic.
Fixes #20513.

[wonderboymusic]

In 31194:

After [31192], create a function, wp_styles(), to reduce duplicated code in functions.wp-styles.php. The style functions can reuse wp_scripts_maybe_doing_it_wrong( $function ) internally.

See #20513.

[wonderboymusic]

In 31196:

Make _wp_scripts_maybe_doing_it_wrong( $function ) "private".

Props obenland for the thought leadership.
See #20513.

[wonderboymusic]

In 31202:

Add @ignore to _wp_scripts_maybe_doing_it_wrong().

Props DrewAPicture for the thought leadership.
See #20513.

[DrewAPicture]

This will ride over to beta, see [31192] [31194] [31196] [31202]. Anything left here?

[DrewAPicture]

This seems fixed. Please create new tickets for any resulting issues.