[wp-trac] [WordPress Trac] #60862: wp_localize_script() on login_enqueue_scripts hook change in behavior

[WordPress Trac]

#60862: wp_localize_script() on login_enqueue_scripts hook change in behavior
------------------------------------+---------------------
 Reporter:  salcode                 |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  6.5
Component:  Login and Registration  |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:
------------------------------------+---------------------

Comment (by swissspidy):

 So it's definitely because of a change with the block registration.
 Previously, many blocks had `editorScript` and `viewScript` entries. That
 caused scripts to be registered very early on init, leading to
 `$wp_scripts` being defined early. In [57377] those were all reworked to
 use the Interactivity API instead, so by default no early script
 registration happens.

 The result is simple: when `login_enqueue_scripts` fires, no scripts have
 been registered yet. That only happens implicitly with this
 `wp_enqueue_script( 'user-profile' );` call here which happens right
 _after_ the `login_header()` call that fires `login_enqueue_scripts`:
 https://github.com/WordPress/wordpress-
 develop/blob/f1c098e77f67ae2469e519757c7c3829288da5d6/src/wp-
 login.php#L1494

 In other words, the code used to work mostly by pure coincidence. On any
 other page it's actually very similar, `$wp_scripts` isn't really
 initialized in a deterministic way. For example on the homepage it usually
 happens in `_wp_admin_bar_init()`.

 That's also why I wasn't able to reproduce this issue at first. If some
 other plugin happens to register a script on the login page early on, then
 you won't notice any issues.

 That also means this issue might not be too widespread.

 It's just that by default `wp_scripts()` is now not called early on the
 login page anymore.

 Long story short:

 This bug actually existed since forever, it just so happens that early
 block registration was hiding this bug.

 A change similar to the one in the PR would fix the issue. IMHO that can
 be done in 6.5.1 or even 6.6 though.


 Longer term, initializing `$wp_scripts` in a more deterministic way would
 probably be better. On the other hand, `wp_scripts()` seems to be designed
 to be used like this, so yeah maybe that's not needed.

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