Make WordPress Core

Opened 6 years ago

Last modified 5 years ago

#45106 new defect (bug)

Concerns related to moving mce_external_plugins filter to WP_Scripts::__construct

Reported by: davidbinda's profile david.binda Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.0
Component: Script Loader Keywords:
Focuses: javascript Cc:


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:

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.

Change History (2)

#1 @SergeyBiryukov
6 years ago

  • Focuses javascript added

#2 @pento
5 years ago

  • Version changed from trunk to 5.0
Note: See TracTickets for help on using tickets.