Enqueue wp_enqueue_media instead of calling it directly

[eliot-akira]

• It should be called from the admin_enqueue_scripts action hook or later
  • See https://developer.wordpress.org/reference/functions/wp_enqueue_media/#user-contributed-notes
• ResolvesUnable to update the featured image in Classic Editor screen loops-and-logic#3 (actually in Tangible Blocks)

---

It needs to handle:

• When fields are registered late, after admin_enqueue_scripts action has run already
• When fields are used on the frontend where admin_enqueue_scripts is never called

[eliot-akira]

@nicolas-jaussaud I'm still working on this one, it needs a function to call wp_enqueue_media in all situations.

• When fields are called too early
  • Enqueue in admin_enqueue_scripts action or later
• When fields are used on the frontend
  • Enqueue in wp_enqueue_scripts action
• When fields are registered late, during/after wp_enqueue_scripts or admin_enqueue_scripts action in the header
  • Enqueue in wp_footer or admin_footer

[eliot-akira]

OK, it has comprehensive coverage now.

The new function $fields->enqueue_wp_media_uploader() properly enqueues it in the following situations.

• Admin
  • Before document head: action admin_enqueue_scripts
  • During and after: action admin_footer
• Frontend
  • Before document head: action wp_enqueue_scripts
  • During and after: action wp_footer

This is currently used by the file and gallery control types.

Also added tests, and utility methods to mock is_admin, did/doing_action, and check if an action hook has a given callback registered.

[nicolas-jaussaud]

Thanks a lot for looking into it and for implementing the tests!

I added a small change and set the priority of the action that call wp_enqueue_media to 9, so that it's before the fields script (that are enqueued in footer hooks as well, here)

I ran the tests again to be sure my change did break something, and did some manual testing in both the fields examples and in blocks. I didn't notice any issue so it should be ok!

[eliot-akira]

priority to 9

Good catch! That makes sense, because at 10 the Fields' script is enqueued which may need the media uploader. Where that happens, I saw:

add_action( 'login_footer', $fields->maybe_enqueue_scripts );

The media uploader isn't enqueued in the login page footer, so technically the file and gallery field types won't work in that situation.

Is that an important use case to cover, using fields in the login page?

If so, I can make a change to the new enqueue function:

if (is_admin()) {
// Admin
+} elseif (is_login()) {++ // Login page+ $action = 'login_footer';+
} else {
// Site frontend
}

[nicolas-jaussaud]

Oops thank you, I forgot we need to support that context!

I added support for it in this commit: 495d445

It discovered there is a login_enqueue_scripts action, so I included it in the conditions to be consistent with the other contexts:

 } elseif (is_login()) {
// Login// Before document head$action = 'login_enqueue_scripts';
if (doing_action($action) || did_action($action)) {
$action = 'login_footer'; // During and after
}
} else {

[eliot-akira]

Oh I've never used that one before, login_enqueue_scripts action. I like the symmetry of logic with the other contexts.

Relatedly I was wondering about Tangible Blocks and L&L, which have dynamic frontend features that require JS & CSS, like a gallery or slider. I have a feeling some are only enqueued on the site frontend but not on admin side. And definitely not in the login page.

For blocks and templates to support all contexts, it will be good to create a "universal enqueue" function for all those dynamic features to use. I suppose that belongs in the Framework module. OK, created an issue as reminder:

• Universal enqueue function to load JS/CSS assets in site frontend/admin/login pages framework#13