Opened 6 years ago
Last modified 6 years ago
#45106 new defect (bug)
Concerns related to moving mce_external_plugins filter to WP_Scripts::__construct
Reported by: | david.binda | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 5.0 |
Component: | Script Loader | Keywords: | |
Focuses: | javascript | Cc: |
Description
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 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.