[wp-trac] [WordPress Trac] #45106: Concerns related to moving mce_external_plugins filter to WP_Scripts::__construct

[WordPress Trac]

#45106: Concerns related to moving mce_external_plugins filter to
WP_Scripts::__construct
---------------------------+-----------------------------
 Reporter:  david.binda    |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Script Loader  |    Version:  trunk
 Severity:  normal         |   Keywords:
  Focuses:                 |
---------------------------+-----------------------------
 In r43723 the `mce_external_plugins` filter was moved to a function called
 via `wp_default_scripts` which, in turn, is called from
 `WP_Scripts::__construct` (via `WP_Scripts::init`).

 While the `wp_default_packages_inline_scripts` function calling the
 `apply_filters( 'mce_external_plugins'` is only triggered in case the
 `did_action( 'init' )` returns true, there might be cases when the
 `WP_Scripts` object is being reinitialised after the `init` and thus code
 hooked to `mce_external_plugins` trying to enqueue or register a script
 causes an infinite loop, since the constructor of the `WP_Scripts` class
 is calling the filter, which calls the constructor again.

 This does not feel like something what would matter in 99% of time, but,
 for instance, this breaks core unit tests which are reinitialising the
 WP_Scripts object, eg.:
 `Test_WP_Customize_Selective_Refresh::test_register_scripts`. in case such
 a piece of code is being used.

 An example of a code used in a mu-plugin and breaking the mentioned test:

 {{{#!php
 <?php
 add_filter( 'mce_external_plugins', function( $plugins ) {
         wp_enqueue_script( 'somescript', plugins_url(
 'someplugin/somescript.js' ), array(), false, true );
         return $plugins;
 }
 }}}

 I think it should be easy to change the plugin in question, but this used
 to work perfectly fine up to recent changes to the script loading in
 r43723 and thus it might be considered being a regression.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45106>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform