[wp-trac] [WordPress Trac] #37110: Update to jQuery 3.*

[WordPress Trac]

#37110: Update to jQuery 3.*
-------------------------------------------------+-------------------------
 Reporter:  jorbin                               |       Owner:  (none)
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  5.5
Component:  External Libraries                   |     Version:
 Severity:  critical                             |  Resolution:
 Keywords:  early has-patch needs-testing        |     Focuses:  javascript
  needs-screenshots has-dev-note commit          |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:142 desrosj]:
 > So I've been thinking this over a bit...

 Same here :)

 > Right now, the only recommendation we could make is to add a really low
 priority `wp_enqueue_scripts` hook that enqueues `jquery-migrate`...
 >
 > `jquery-migrate` needs to be loaded after `jquery`...

 There's a way to do this, see the testing plugin:
 https://github.com/WordPress/wp-jquery-update-
 test/blob/trunk/class_wp_jquery_update_test.php#L140.

 > Of course, we would rather developers update their code to be compatible
 with newer versions of jQuery instead, but it's not unreasonable to expect
 that some may just need more time. This can only be a temporary fix for
 them anyway, because step 2 of the roadmap is to update `jquery-migrate`
 to the most recent version.

 Right. jQuery 3.x plus jQuery Migrate 3.x (WP 5.6) will not be backwards
 compatible with super old code. Then require step 5 of this list:
 https://jquery.com/upgrade-guide/3.0/#jquery-migrate-plugin (latest 1.x
 without migrate).

 Been thinking about what would be the best way to give more time to both
 plugin/theme authors and users. Perhaps making a simple "back-compat"
 plugin and releasing it with 5.5 would serve that purpose? As far as I see
 the plugin can be "fully automatic", detect what version of WP is used and
 enqueue/change scripts as needed.

 This runs the risk of letting some site owners to continue running old
 code and not updating. Thinking if somebody wants to not update, they will
 find a way in any case.

 On the other hand having a separate (core/canonical) plugin will allow WP
 to do some "intervention" (perhaps a metabox on the Dashboard for admins?)
 and ask the users to update their plugins/themes and turn the plugin off.
 It can also include some code to try to determine when it will be safe to
 do so.

 > Some other ballpark numbers with the plugin results:
 > - Plugins with 5k or more installs: 434
 > - Plugins with 1k or more installs: 672
 >
 > Though the entire list is 11k, I'd argue that all of these are
 reasonable cutoff points, and each of these points greatly reduces the
 number of potentially affected sites.
 >
 > Some other things to consider looking through that search:
 > - Only 14 of the first 100 plugins have more than one occurrence of
 `.live()`.
 > - For several of the plugins with 1 occurrence on the first page, the
 only occurrence of `.live()` is found within a bundled library (most
 commonly jQuery Colorbox, which has not been updated in over 4 years).
 >
 > Of course these are only small segments of things that may potentially
 cause compatibility issues that jQuery Migrate addresses, but I think this
 is important context to have for the data.

 In theory, if there is a back-compat plugin (see above), and there are
 many confirmed cases of breakage, WP can ship the plugin as part of core
 and enable it by default when one of the more common breakage cases is
 detected. Not sure it this will be needed, but... it's a possibility.

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