[wp-trac] [WordPress Trac] #54529: Allow for `wp_register_script()` to be called after `wp_enqueue_script()`.

Fri Dec 3 19:47:27 UTC 2021

#54529: Allow for `wp_register_script()` to be called after `wp_enqueue_script()`.
---------------------------------------------+---------------------
 Reporter:  dd32                             |       Owner:  (none)
     Type:  defect (bug)                     |      Status:  new
 Priority:  normal                           |   Milestone:  5.9
Component:  Script Loader                    |     Version:  trunk
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:7 dd32]:
 > When a plugin registers styles/scripts on wp_enqueue_scripts (as we
 encourage plugins to do),

 This is actually wrong. Scripts should be registered on `init`, and
 enqueued on `wp_enqueue_scripts`.

 > As do I, it's not perfect, but it's not horrible.

 Right. This is a "double" edge case :) When doing script registering and
 enqueueing separately scripts should be registered on `init`, and enqueued
 on `wp_enqueue_scripts`.

 The case we're trying to accommodate is registering on
 `wp_enqueue_scripts` (that's late, this action runs after `init`), and
 then enqueueing on the `wp_content` filter by using it as an action (that
 can be late too, this filter usually runs in the middle of the HTML
 `<body>` but may run much earlier).

 So generally there are two "doing it wrong" here, the first worse than the
 second. Wondering if there should be notices for them.

 Also note that scripts can be registered and enqueued at the same time by
 using the `wp_enqueue_script()` function, see
 https://developer.wordpress.org/reference/functions/wp_enqueue_script/.
 Then it is the proper/expected way to use the `wp_enqueue_scripts` action.
 This will also help to mitigate the problem we're trying to solve here.

 > This is an example of what wouldn't work though:

 Yeah, probably better to add that doing-it-wrong when registering a script
 from the `wp_enqueue_scripts` action.

 > One thing I'm unsure of - The PR causes the enqueue to happen before the
 script register "in footer" call is made, but I'm not sure if that's
 '''actually''' a problem

 Seems this should work fine. This patch "holds" the actual enqueueing
 until the script is registered. Then the registering and enqueueing
 happens in the proper order.

 The possible problems (as mentioned above) are from the fact that
 `wp_enqueue_script()` was called with a script handle only but the script
 is not yet registered until the registering happens. That means there
 cannot be any extras like localization, before/after, etc. However these
 extras are usually added after registering a script, not after enqueueing
 it. Frankly I'm not sure this rare edge case can be fixed easily.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54529#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform