WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 7 months ago

Last modified 7 months ago

#25618 closed defect (bug) (fixed)

Fix opening of Media Manager in Customizer

Reported by: westonruter Owned by: nacin
Milestone: 3.8 Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-patch
Focuses: Cc:

Description

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().

Attachments (3)

25618.patch (1.8 KB) - added by westonruter 9 months ago.
test-control.php (1.4 KB) - added by westonruter 9 months ago.
Customizer Control which demonstrates patched fix
25618.2.patch (1.9 KB) - added by SergeyBiryukov 8 months ago.

Download all attachments as: .zip

Change History (12)

westonruter9 months ago

westonruter9 months ago

Customizer Control which demonstrates patched fix

comment:1 westonruter9 months ago

  • Cc weston@… added
  • Keywords has-patch added

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.

comment:2 celloexpressions9 months ago

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

comment:3 lancewillett8 months ago

  • Cc lancewillett added
  • Milestone changed from Awaiting Review to 3.8

SergeyBiryukov8 months ago

comment:4 SergeyBiryukov8 months ago

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

comment:5 nacin7 months ago

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

comment:6 nacin7 months ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 26589:

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

props westonruter.
fixes #25618.

comment:7 follow-up: westonruter7 months ago

@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.

comment:8 in reply to: ↑ 7 ; follow-up: SergeyBiryukov7 months ago

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.

comment:9 in reply to: ↑ 8 westonruter7 months ago

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

Note: See TracTickets for help on using tickets.