The "admin_footer" action isn't called on customize.php

[feedmeastraycat]

I have a plugin called ​WP Editor Widget which adds a rich content widget using the ​wp_editor() function. It does this on the wp-admin/widgets.php page by using the "widgets_admin_page" action to output a hidden div containing the wp_editor() code. The widget itself has a button that opens and closes the editor overlay and copies the editor content to a hidden input inside the widget.

This works well on widgets.php but I have a weird issue when trying to make it work on customize.php.

It seems that customize.php doesn't include admin-footer.php but instead only calls the admin_print_footer_scripts action and admin_footer-widgets.php in WP_Customize_Widgets->print_footer_scripts(). Which is added to the "customize_controls_print_footer_scripts" action in customize.php.

This means for the _WP_Editor class that _WP_Editor::editor_js() is called. But never _WP_Editor::enqueue_scripts() (which both are added in _WP_Editor:: editor_settings()) making my wp editor only function half way. I can't switch to plain text mode for example.

I've solved this, I think, for now, by just adding a customize_controls_print_footer_scripts action on low prio (so it runs before the one in WP_Customize_Widgets because it needs to be called before _WP_Editor::editor_js(), but after a wp_editor() function is called) and calling _WP_Editors::enqueue_scripts() manually there.

I've created a patch that solves it by adding do_action( 'admin_footer' ) to WP_Customize_Widgets->print_footer_scripts();
But maybe there is a reason for it not to be there?
My bug is a bit low risk. But maybe other bugs can appear because the admin_footer action isn't called?
But maybe new bugs can appear if it is called? :)

[feedmeastraycat]

Patch

[nacin]

Moving to 3.9.1 for investigation.

[nacin]

I really have no idea why wp_editor() uses admin_footer and wp_footer rather than admin_print_footer_scripts and wp_print_footer_scripts.

Calling admin_footer here would probably have side effects as developers may be printing information on those hooks (while using a _scripts hook would not be such a good idea for that). But fixing wp_editor() should be easier anyway.

Does changing the hook make everything work for you?

[feedmeastraycat]

My patch fixes my issues. And I assume a patch on wp_editor that changes the actions to this:

if ( empty(self::$first_init) ) {
        if ( is_admin() ) {
                add_action( 'admin_print_footer_scripts', array( __CLASS__, 'enqueue_scripts'), 1 );
                add_action( 'admin_print_footer_scripts', array( __CLASS__, 'editor_js'), 50 );
        } else {
                add_action( 'wp_print_footer_scripts', array( __CLASS__, 'enqueue_scripts'), 1 );
                add_action( 'wp_print_footer_scripts', array( __CLASS__, 'editor_js'), 50 );
        }
}

Would fix it as well. The important part is that _WP_Editor::enqueue_scripts() is never called on customize.php. Both my submitted patch and the example above should fix that.

I can create a patch like that and test it. And if it seems to fix the issue I'll submit it.

But the big thing here (I guess) is that I don't know if any of these patches will have bad side effects elsewhere. :)

But maybe there is a third, easier and better way?

[nacin]

Looks good, feedmeastraycat.

[feedmeastraycat]

Patch 2 (wp-editor suggestion)

[feedmeastraycat]

I've tested and uploaded a second patch now. It also fixes the issue.

But I guess someone with a bit more knowledge about wp-editor or the customizer function should have a look at this so it doesn't causes issues elsewhere.

(Note, if I haven't been clear enough, both patches isn't required. Two solutions to the same issue).

[azaozz]

Changing _WP_Editors::enqueue_scripts() to run later still outputs all editor related scripts in the same order at the same place.

One possible regression is if a plugin was enqueueing a script on 'admin_footer' or 'wp_footer' in order to output it after the editor related scripts (word-count, editor, wplink, etc.), now it will be outputted before them.

In that terms the change should probably be added to trunk but maybe not to 3.9.1.

[azaozz]

In 28187:

Run WP_Editors::enqueue_scripts() on admin_print_footer_scripts priority 1 (later), instead of admin_footer. Fixes incompatibility with the customizer. Props feedmeastraycat, see #27853, for trunk.

[feedmeastraycat]

@azaozz: Does this mean it will end up in 3.9.1? (If it does, I will fix my plugin to only include my fix on 3.9 or lower version of WP)

[nacin]

Yes, it will end up in 3.9.1.

[nacin]

In 28203:

Run WP_Editors::enqueue_scripts() on admin_print_footer_scripts, instead of admin_footer.

Fixes incompatibility with the customizer.

Merges [28187] to the 3.9 branch.

props feedmeastraycat.
fixes #27853.