[wp-trac] [WordPress Trac] #52012: Bundle jQuery plugin temporarily to encourage adoption of auto-updates

[WordPress Trac]

#52012: Bundle jQuery plugin temporarily to encourage adoption of auto-updates
-----------------------------+------------------------------
 Reporter:  carike           |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Upgrade/Install  |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  javascript
-----------------------------+------------------------------
Description changed by carike:

Old description:

> **The Problem:
> **
> There were a large number of questions on the Forums during 5.5. and 5.6.
> where sites experienced fatal errors or other unexpected behaviour
> because they use plugins that have not yet updated to the appropriate
> jQuery libraries.
>
> When sites break, non-technical users tend to want to roll back.
> This breaks trust in auto-updates and is highly likely to lead to users
> staying on older Core versions for longer and not trying to update again
> for years.
>
> **The Proposed Solution:**
>
> Bundle the jQuery Helper into Core (like Hello Dolly).
>
> Strongly consider running a chron job to disable (and possibly delete)
> the plugin after a certain number of admin logins (say 20).
> Have a prominent message (possibly redirect to a "landing page") to show
> the admin user how many logins they have left before the plugin is
> automatically disabled / deleted.
> Consider allowing the admin to extend the number of admin logins (perhaps
> to 200), or to enable the plugin until disabled (for sites that use
> plugins reliant on the outdated jQuery libraries).
>
> If possible, consider making use of Site Health to give an indication to
> the admin user as to whether or not the plugin is needed on their current
> setup or not.
>
> The goal here is not to let people use insecure libraries indefinitely -
> the goal is to get them **off** those libraries as soon as possible by
> facilitating communication and by not leaving them with a broken site
> (potentially during the middle of the night without them even being aware
> that the auto-update is happening) and scaring them off updating at all.

New description:

 **Some background:
 **

 I wanted to include some comments here that I see as representative of the
 user experiences I have read about across the interwebs when they upgraded
 to to WordPress 5.6:


 {{{
 Hello Wordfence team,
 Thank you for this very interesting post. Every update of WP makes me
 worried, especially lately because of all the plugin and themes update
 needed after... and the risk of big bug...
 For the security, Wordfence is installed in all my websites for many years
 now and it really help me to sleep well ;)
 Merry christmas time for all
 Cécile
 }}}

 {{{
 Thank you for this useful rundown of the newest WordPress update. While it
 does sound exciting, I'm going to hold off for the time being and make
 sure all my plugins have caught up.
 }}}

 {{{
 Do you think I should postpone the WordPress update to the latest? And I
 have to test the latest WordPress first on my local site?
 And is there no problem if I delay updating WordPress to the latest
 version? Are there no security holes or other bugs if I delay updating
 WordPress to the latest version?
 }}}


 {{{
 i had upgraded my website to latest version of wordpress from 5.5 to 5.6.
 after few hours from upgrade my site started showing blank popup on screen
 which was not removeable even this have a cancel icon at top.
 my whole structure of [readacted] was disturbed.
 so I've downgraded back to 5.5 now it's working fine.
 so if you want to upgrade your version. do it at your own risk.
 }}}

 The above comments are from the WordFence blog:
 https://www.wordfence.com/blog/2020/12/wordpress-5-6-introduces-a-new-
 risk-to-your-site-what-to-do/

 **The Problem:
 **

 There were a large number of questions on the Forums during 5.5. and 5.6.
 where sites experienced fatal errors or other unexpected behaviour.
 While plugins that have not updated to the latest version of jQuery
 libraries are certainly not the only reason for fatal errors or unexpected
 behaviour - and while the number of active installations of the jQuery
 Helper plugin are probably inflated at this point - the number of
 downloads for the plugin and trends regarding questions on the Forums and
 other WordPress-related Help sites, in combination with other indicators
 like the number of plugins in the repository that make reference to
 outdated jQuery libraries suggest that the problem is not trivial.

 When sites break, non-technical users tend to want to roll back.
 This breaks trust in auto-updates and is highly likely to lead to users
 staying on older Core versions for longer and not trying to update again
 for years.

 **The Proposed Solution:**

 Please note that this solution on its own won't magically solve all update
 problems. However, it is one part that seems like it can be mitigated to
 reduce the "noise" (not suggesting that the concerns are not valid -
 suggesting that word of mouth is highly effective) / friction in the
 ecosystem.

 Bundle the jQuery Helper into Core (like Hello Dolly).

 Strongly consider running a cron job to disable (and possibly delete) the
 plugin after a certain number of admin logins (say 20).
 Have a prominent message (possibly redirect to a "landing page") to show
 the admin user how many logins they have left before the plugin is
 automatically disabled / deleted.
 Consider allowing the admin to extend the number of admin logins (perhaps
 to 200), or to enable the plugin until disabled (for sites that use
 plugins reliant on the outdated jQuery libraries).

 If possible, consider making use of Site Health to give an indication to
 the admin user as to whether or not the plugin is needed on their current
 setup or not.

 A bundled plugin approach could potentially be used for other breaking
 changes in the future - as one of the main constraints .org has always had
 to contend with was that there hasn't really been a good way to
 communicate these to a large number of site owners / admins.

 The goal here is **not** to let people use insecure libraries indefinitely
 - the goal is to get them **off** those libraries as soon as possible by
 facilitating communication and by not leaving them with a broken site
 (potentially during the middle of the night without them even being aware
 that the auto-update is happening) and scaring them off updating at all.

--

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