WordPress.org

Make WordPress Core

Opened 5 months ago

Last modified 5 months ago

#52012 new feature request

Bundle jQuery plugin temporarily to encourage adoption of auto-updates

Reported by: carike Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.5
Component: External Libraries Keywords:
Focuses: javascript Cc:

Description (last modified by carike)

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.

Change History (14)

This ticket was mentioned in Slack in #forums by carike. View the logs.


5 months ago

This ticket was mentioned in Slack in #forums by carike. View the logs.


5 months ago

#3 @carike
5 months ago

  • Description modified (diff)

#4 @carike
5 months ago

  • Description modified (diff)

Fixed some spacing for read-ability.

This ticket was mentioned in Slack in #forums by carike. View the logs.


5 months ago

#6 @apedog
5 months ago

  • Version set to 5.5

+1 for this.

I'll only add that I don't think Core should delete the plugin. Maybe a deactivation through site-health would be more reasonable. Number of admin log-ins seems like an arbitrary choice.

In addition, in the interest of upholding backward-compatibility philosophy as much as possible, I think we should consider polyfilling some jQuery functions indefinitely by core.

Case in point: https://api.jquery.com/andSelf/

Note: This API has been removed in jQuery 3.0; use .addBack() instead, which should work identically.

There are no security implications for adding a wrapper function. This is essentially syntax sugar.
This could mean WordPress would support non-standard jQuery so YMMV. I don't have a strong opinion on this myself - bc-compatibility vs. "correct" jQuery syntax - but this will mitigate a lot of bc-incompatible breakage.

I believe this plugin should have been bundled with WordPress as far back as 5.5, and if this feature is adopted, I believe the inclusion should be backported to 5.5.x

This ticket was mentioned in Slack in #core by apedog. View the logs.


5 months ago

This ticket was mentioned in Slack in #core-auto-updates by audrasjb. View the logs.


5 months ago

#9 follow-up: @audrasjb
5 months ago

  • Component changed from Upgrade/Install to External Libraries

Hello,
As per today’s Upgrade/Install component bugscrub, let's move this ticket to External libraries :)

#10 in reply to: ↑ 9 @pbiron
5 months ago

Replying to audrasjb:

As per today’s Upgrade/Install component bugscrub, let's move this ticket to External libraries :)

That decision was based on the fact that #37110 is in that component, and this is is related to that ticket.

#11 follow-up: @Clorith
5 months ago

I'm just going to jump in here, as I am not a fan of this idea. I don't think core should be bundling any plugins (Hello Dolly and Akismet are notable exceptions, the first is meant as an example of WordPress' flexibility through plugins, and Akismet is a whole other topic).

Core should only be shipping, as per its mantra, things that the majority of users need, and 80% of WP users do not need, as in the example here, a plugin to fix jQuery issues. If there are major breaking changes going forward (this wasn't truly a breaking change, this was plugin and them authors becoming blind to their own issues because they didn't truly understand that jQuery Migrate was running), sure it looks like WP broke them, but we can educate, which we are doing.

I also do not agree with the assessment that 5.5 and 5.6 have had an increase in broken sites, there's been a very normal amount of "broken" sites, with the most usual symptoms of incomplete updates, and local browser caches for both these releases, 5.5 had an oopsie with some localize script strings, but that wasn't a major widespread issue and was quickly addressed as well.

What may be worth discussing, is if there's a place for the tools.php page, which really has no real content per now, to have a curated list of plugins meant for troubleshooting, they would not be bundled, it would be much like the importer screen is today, a quick and easy way to install one of multiple plugins with a sole purpose. But I think we can safely move away from the "bundle plugins" topic here.

#12 in reply to: ↑ 11 @pbiron
5 months ago

Replying to Clorith:

What may be worth discussing, is if there's a place for the tools.php page, which really has no real content per now, to have a curated list of plugins meant for troubleshooting, they would not be bundled, it would be much like the importer screen is today, a quick and easy way to install one of multiple plugins with a sole purpose.

I think this is definitely worth considering!

#13 @audrasjb
5 months ago

+1 for exploring this option, @Clorith @pbiron

#14 @apedog
5 months ago

this wasn't truly a breaking change

WP did introduce a breaking change when it updated the jQuery version bundled with WP, and removed jquery-migrate. This is the very definition of a breaking change.

this was plugin and them authors becoming blind to their own issues because they didn't truly understand that jQuery Migrate was running

Developers/authors are not the issue here. The issue is how users are affected. Specifically users that are not tech-savvy and users that do not have developers on their payroll.

I also do not agree with the assessment that 5.5 and 5.6 have had an increase in broken sites

This is news to me. As I recall there was an uptick of 'broken' sites/tickets/support issues revolving around the jQuery upgrade upon 5.5 release. Alleviated by the introduction of the jQuery Migrate Helper plugin.

I am not a fan of this idea. I don't think core should be bundling any plugins

This might be a valid personal opinion/preference, but it should be weighed against WP's longstanding philosophy of backward-compatibility. The precedent of bundling plugins with WP exists. And in this case it can be bootstrapped to help with a problem that could affect 20% of users (I'm relying on @Clorith statistic of 80% not affected above).

Note: See TracTickets for help on using tickets.