Fix opening of Media Manager in Customizer

[westonruter]

If a customizer control does wp_enqueue_media() in order to make use of the Media Manager, the control also has to do some workarounds to ensure that it can be opened properly. Specifically, wp_enqueue_media() only adds the wp_print_media_templates function to the wp_footer and admin_footer actions, leaving out the Customizer which has the closest equivalent in customize_controls_print_footer_scripts. So a workaround is needed, such as:

<?php
add_action('customize_controls_init', function () {
    add_action( 'wp_enqueue_media', function () {
        add_action(
            'customize_controls_print_footer_scripts', 
            'wp_print_media_templates' 
        );
    } );
} );

Furthermore, even though now the Media Manager can be opened, it will appear behind the Customizer: the Customizer has a z-index of 500000 whereas the .media-modal has z-index:160000 and similarly the .media-modal-backdrop has z-index: 159900. So if the Media Manager is to be used in the Customizer, the following CSS overrides aksi have to be included:

.media-modal {
        z-index: 660000;
}
.media-modal-backdrop {
        z-index: 559900;
}

These workarounds are not ideal. Preferable, all that a customizer control should have to do is call wp_enqueue_media().

[westonruter]

Customizer Control which demonstrates patched fix

[westonruter]

In addition to adding wp_print_media_templates to the customize_controls_print_footer_scripts action and increasing the z-index as required, I also switched some instances ofrequire to require_once.

[celloexpressions]

This blocks (among other things) #21483, so a quick fix would be nice. Patch looks good to me.

[SergeyBiryukov]

Refreshed the patch using .wp-customizer class introduced in [26085] (for #25867).

[nacin]

I don't understand the switch to require_once(). Otherwise, looks good.

[nacin]

In 26589:

Allow wp_enqueue_media() to "just work" in a customizer control.

props westonruter.
fixes #25618.

[westonruter]

@nacin: The require_once addresses an issue when you try to subclass WP_Customize_Control before the Customizer is initialized (e.g. the attached test-control.php plugin). To do this subclass, you have to require class-wp-customize-control.php up front, but then when WP_Customize_Manager is instantiated later, its constructor also does a require for that same file, resulting in a fatal class redeclaration error. It seems require_once should be the default method for importing libraries, whereas require the default for templates/partials.

[SergeyBiryukov]

Replying to westonruter:

To do this subclass, you have to require class-wp-customize-control.php up front, but then when WP_Customize_Manager is instantiated later, its constructor also does a require for that same file, resulting in a fatal class redeclaration error.

That can be worked around by moving the WP_Media_Manager_Control class declaration to a separate file and requiring it inside the function attached to customize_register.

[westonruter]

Replying to SergeyBiryukov:

That can be worked around by moving the WP_Media_Manager_Control class declaration to a separate file and requiring it inside the function attached to customize_register.

Yes, it can be worked around, but it seems a workaround shouldn't be necessary. It would be nice if everything could be self-contained in one file if desired. The other workaround approach is to declare the subclass inside of the customize_register function callback, as I did in a demo plugin ​https://gist.github.com/westonruter/7729203 for #26061