Add jQuery v3.x and make it the default for new installations (with a fallback to v1.x for existing sites)

[klonos]

This was brought up during our latest dev meeting...

This relates to #2493, which is focused on keeping 1.x in core up to date, as well as #214, which is about dropping IE8 support (perhaps IE9 too?). Lets discuss pros/cons and blockers of upgrading to 2.x here, as well as considering upgrading to 3.x at some point (separate issue/task, also perhaps a Backdrop 2.x thing).

When opening a new ticket for jQuery in https://github.com/jquery/jquery/issues/new, there's this note:

Note that we only can fix bugs in the latest version of jQuery.

...which basically verifies the fact that 1.x and 2.x are EOL.

Key points:

• 2.x dropped IE6–8 support for the sake of performance improvements and reduction in file size.

• 3.x Promises/A+ support for Deferreds, $.ajax and $.when, .data() HTML5-compatible

jQuery maintains a list of the functions they have deprecated in various versions: https://api.jquery.com/category/deprecated

And a list of functions they have removed entirely: https://api.jquery.com/category/removed/

I found mentions around the net of suggestions of conditionally loading 1.x/2.x based on browser detection, here for example: Using both jQuery 2.x and jQuery 1.x versions at same time

Some resources that might be of help:

http://api.jquery.com/category/version/1.12-2.2
https://github.com/jquery/jquery-migrate
https://jquery.com/upgrade-guide/3.0

Sources I scraped in order to compile this summary:

https://en.wikipedia.org/wiki/JQuery#Release_history
https://stackoverflow.com/questions/41605120/what-is-the-difference-with-jquery-version-1-version-2-and-version-3-versions-r

[greggles]

FWIW, I agree that moving off of jQuery 1.x to 3.x is a great decision. Backporting security fixes is laborious and risky. It's just all around way safer and likely more stable to be off of jQuery 1.x and onto something supported.

[klonos]

It seems that the jQuery team have decided to NOT release jQuery Compat: jsfiddle/jsfiddle-users#655 ...removing that from the issue summary.

[klonos]

I have set this to the 1.x milestone so that it stays within our radar. jQuery is not backporting security fixes to 2.x and 1.x, so we need to work our way towards 3.x I believe.

Adding the milestone candidate tag, and proposing that we do this (at least move to 2.x) for 1.14.

[hosef]

I have created a Pull Request that updates jQuery from 1.12.4 to 3.4.1. I manually tested my local site by using the following interfaces, and I only found 1 problem in the color module which I fixed.

• Creating and editing layouts
• Creating and editing nodes
• Creating and editing fields
• Creating, editing, and rearranging menu items
• Creating and editing views
• Creating and editing text formats
• Creating and editing taxonomy terms
• Navigating the site with the admin bar
• Search and autocomplete fields
• Changing colors in the theme settings

[laryn]

I did some clicking around in the sandbox and it looks good so far. I was not able to generate any errors. I'm not sure if there are any other functionality that is not in your list that we need to do more thorough testing on.

Also, how do we handle contrib with a change like this? Just give enough of a heads-up that maintainers can do testing before it is released?

[hosef]

I am not really sure about how to keep backwards compatibility for contrib. In theory, if they were keeping up with jQuery recommendations, then it should just work with the new version like core did.

Maybe it would be better to port the jQuery upgrade module instead, except not even that supports the latest version of jQuery.

[klonos]

Thank you for working on this @hosef 👍 ...I've changed the milestone candidate to the next minor release, as I am reluctant to get a possibly breaking change in a bug release.

[klonos]

...perhaps we need to get this into 1.x (not 1.15.x) ASAP. That would give us enough time to spot any regressions in the PR sandboxes, as people test other aspects of the UI.

[ghost]

I think this should be brought up at a weekly meeting for discussion. I don't see how this change could get into Backdrop 1.x (though I hope I'm wrong and it does) because of the possibility for people relying on the version on jQuery bundled with core for their own custom code. To me this seems like a big possibility for a breaking change...

[ghost]

Also marking as 'needs work' due to a conflict.

[herbdool]

I've updated the PR with some tweaks to the UI as per @klonos. I didn't change the menu item because it's not a "development setting" but a production/runtime setting. If anything we could change menu item to "JavaScript settings" if we wanted it a bit more generic.

We'll still need to update this PR with fixes for removed functions.

[herbdool]

I added an unpublished page in the docs https://docs.backdropcms.org/documentation/introducing-jquery which is linked from this PR. And a parent page for javascript in general. Would be good to fill this out more but the minimum is good enough for this PR I think.

[herbdool]

I've changed .size() to .length.

Looking at https://api.jquery.com/category/removed/, I'm wondering about .load() https://api.jquery.com/load-shorthand/ (the non-ajax version) which I think is present in color.js so I'm updating that to:

    // Wait for the iframe to be loaded before attempting to apply the preview
    // settings for the first time.
    $('#preview').on('load', function () {
      updatePreview();
    });

[klonos]

Thanks @herbdool ...I've reviewed and tested the PR and left comments. There's one thing that broke (with the preview of the theme colors).

I didn't change the menu item because it's not a "development setting" but a production/runtime setting.

Yeah, I see your point 🤔 ...still don't like the fact that we are introducing individual menu items for each thing under development, as it has the potential to grow large. Besides, this is only a single setting with 2 radios. I don't have any better suggestion at the moment though 🤷🏼 ...perhaps I'm overthinking things too, so I won't insist if others don't see a problem with this 👍🏼

[herbdool]

I've fixed the flickering. I believe it was caught in a loop reloading the iframe. At some point @hosef had it just wait for the load event and previously it was just:

updatePreview();

The commit mentions something about issues with some browsers but I didn't see an issue in Chrome-based browser. But at any rate, I changed it to check for the load event of the main window.

[quicksketch]

I left a few minor comments on the PR: backdrop/backdrop#4387

No issues with the actual code that I could find. Other than the small documentation requests, this looks ready to me!

[quicksketch]

Feedback from myself and @klonos has been addressed. I think this is ready to go. We discussed getting this in earlier in the release cycle is more beneficial than getting it perfect immediately, so unless there are sticking points, I'm for merging this into 1.x.

[klonos]

Yes, lets please get this merged into 1.x as soon as possible.

But can we please keep this issue here open? I'd like us to work on the form a bit with a follow-up PR, just for the UI bit (minor tweaks really, which are not worth blocking the main bits from being merged).

[quicksketch]

Thanks everyone for their hard work on this issue! I have merged backdrop/backdrop#4387 into 1.x for 1.26.0.

5721f4d by @herbdool, @klonos, @hosef, @laryn, @BWPanda, @indigoxela, @jenlampton, @quicksketch, @kiamlaluno, and @zchandler.

[quicksketch]

@klonos Leaving this open for your adjustments, though if it is a bigger set of changes let's open a separate issue.

[quicksketch]

@klonos Let's open a new issue for any UI adjustments so we can close this issue for the release.