Silverstripe-framework: Update jQuery and jQuery UI to 1.13

[tractorcow]

Acceptance Criteria

• jQuery and jQuery UI are running recent stable versions
• jQuery and jQuery UI versions are compatible with our supported browsers for 4.0 (IE11+, see https://github.com/silverstripe/silverstripe-framework/issues/6321)

Notes

• This assumes the library upgrade does not require large changes to entwine or jstree libraries. Please investigate this early (run the entwine specs)
• We'll need to find another solution for jQuery.browser in entwine (see https://github.com/hafriedlander/jquery.entwine/issues/32)
• Entwine was updated to support jQuery 1.11 and 2.1 already a while ago
• Currently running jQuery 1.7.2, jQuery UI 1.9.2,
• jstree is compatible up to jQuery 3.x
• jQuery UI 1.12 has a new theme and dropped IE10 support
• jQuery 1.12 supports IE6+, jQuery 1.13 and newer support IE9+
• jQuery will eventually be phased out, so this is a low value activity
• We're discouraging using the framework bundled jQuery as project dependency (moved paths of jquery.js), and have removed support for using CMS JavaScript in projects (e.g. DateField.js)
• We're proposing removing jQuery UI

Background

No longer relying on:

• Buttons
• Datepicker
• Most dialogs

Still relying on:

• Tabs in non-react sections
• ToggleCompositeField
• Login dialog (on session expiry) - should be removed via https://github.com/silverstripe/silverstripe-framework/issues/3384
• Some ui-widget CSS styling
• JSTree (jQuery)

[tractorcow]

Note that https://github.com/silverstripe/silverstripe-framework/commit/98907fb35f5a01874df87575610782dd793e6a28 will need changes made to support this update.

[dhensby]

Much of this discussion has been had on loomio

[simonwelsh]

The Loomio conclusion was that the core team's against the change with everyone else for it. As it pretty much only matters to core, I don't see this happening any time soon. Removing milestone.

[dhensby]

I guess this highlights the real problem with Loomio, it doesn't matter what the community wants/thinks, core devs do the work so their opinions are the only ones that really matter. (cc @camfindlay)

Not that I disagree with that, I think that SS does need strong ownership and leadership; it's just a point worth noting

[tractorcow]

Fair enough @simonwelsh . It's not something that's necessary at this stage, but is certainly something we will be sure to do in the future. It's worth planning for in advance.

[BonnieSoftware]

Would it not be better to be given a choice?

[simonwelsh]

@MatthewBonner end users aren't affected by the framework jQuery version as they can include their own version.

[BonnieSoftware]

I was referring to developers being given the choice, I've had instances where I would like to use 2 and instances where I've had to use 1.

[tractorcow]

It looks like we are going to upgrade to jquery 3.x now... probably 3.1.

https://blog.jquery.com/2016/07/07/jquery-3-1-0-released-no-more-silent-errors/

[dhensby]

Is the 1 line no longer supported? Assuming it is, what are the pros/cons of moving away from it?

As I see it, cons are:

1. Use on front-end will now be limited because this version may not have the browser compatibility devs need
2. Upgrades required to entwine
3. We're moving away from jQuery in the CMS - so time invested in this may be better spent on something else

---

I've previously tried just upgrading the version of jQuery to the latest v1 and it's not easy, probably need the jQuery migrate plugin to really ease the pain.

[sminnee]

I'm bumping this out of alpha2 for our open-sourcerers team's work; this seems like it'll be a distraction.

[tractorcow]

As a note, I've found that any potential upgrade to jquery ui is capped at 1.11, as 1.12 no longer supports ie10.

http://blog.jqueryui.com/2016/09/jquery-ui-1-12-1/

This doesn't block upgrade of jquery itself.

[dhensby]

1.12 doesn't officially support ie10 but has the ie10 compat code in it. 1.13 is when it gets removed.

[sminnee]

Note that the outcome of #6321 is that we can drop IE10 support and upgrade to 1.13

[chillu]

• Entwine works just fine with current jQuery
• We're not trying to fix any immedate bugs or browser incompatibilities with this upgrade
• This is independant of versions used in bespoke projects
• jQuery UI only really impacts tabs in Entwine UIs

Conclusion: Not essential for 4.0, since we're moving away from jQuery in new UIs anyway. At least, it's not worth 8 points.

[dhensby]

Agreed - the only argument I can think of to upgrade these components is that they will stick around for the life of the 4 release and so we implicitly have to support them anyway - upgrading to get away from having to support ancient versions is perhaps in our long-term benefit.

[chillu]

I don't think any frontend library used in the CMS are part of a strict API - the frontend world moves way too quickly for this. Along the same lines, I doubt we'll be on React v16 in 2021

[dhensby]

If we break modules on minor releases because we're changing JS libraries all the time, then that's not good - I think it does form part of a developer's API tbh

[tractorcow]

Instead of upgrading we'll likely continually remove dependencies on entwine / jquery until we can remove this library altogether. :)

[chillu]

jQuery 1.x is now EOL, but gets security fixes on a best effort basis: https://github.com/jquery/jquery.com/issues/162. I'd say that's good enough for us, given the usage patterns in the CMS. It's more impactful if newer browsers break old jQuery code.

[chillu]

After a bit of confusion, we've established that a) we're running jQuery 3.x in our CMS webpack builds, and b) we're also running jQuery 1.x on the global window object, because it's required by jQuery-ui.

We're also still shipping jQuery 1.x as part of the client/*/thirdparty/* and client/*/vendor/* folders, which is publicly accessible because they're copied into resources/. Most of these aren't actually included on the CMS (none of them?), so they're never executed. But any file-based security scanners will pick them up anyway

So we'll need to a) update or remove jQuery UI (https://github.com/silverstripe/silverstripe-framework/issues/3384) and b) remove old unused jQuery scripts from the vendor folders.

[chillu]

I've separated out the task of upgrading jQuery 3.x to the latest release, since our current one has a vulnerability: https://github.com/silverstripe/silverstripe-admin/issues/875

[chillu]

Changing to impact/high since this gets repeatedly flagged by audits, and gives SilverStripe sites an unnecessarily bad look - even if the real world exploit potential is small.

[sminnee]

I'm not sure that embargoing this until SS 5.x is feasible; strictly speaking people's code might rely on these, but are they part of our Public API? It feels like "delete the code" is the more likely approach than "upgrade the code". We'd probably want to have a mechanism for people to add these back. Probably just "install it in your project yourself", but at least outlining this in the docs would be good.

[lekoala]

@sminnee what would be the issue in including the old and updated version. the change could but opt in, so nothing would break for people using the old version. It would be great to have a config flag to load an updated version of jquery instead in the cms.
Ideally, the framework itself should provide a public api for including these kind of requirements, something like Jquery::requirements() that would include all things based on chosen config. This way, module providers could rely on this and everyone would use this api instead of including files based on their path. just a thought.

[chillu]

something like Jquery::requirements()

Hell no, if anything we're trying to decouple our CMS backend and frontend, not bake in more coupling like this. jQuery is an implementation detail of the CMS UI. For your own websites, we kindly provide a Requirements API which prevents you from writing <script> tags in your templates, but that's about it :)

[madmatt]

Sorry, inadvertently closed this issue :-)

[Leapfrognz]

@chillu We keep being pinged on this one by qualys/security scans for CWP clients as an outdated dependency. So for our clients, this carries quite a high priority. Can we get an explicit summary of when/if this will be worked on for core?
Also note we got caiught on an old version of TinyMCE as well - TinyMCE 4.6.5

[chillu]

@Leapfrognz Yep this comes up often. We've previously said something along these lines on vendor responses:

JavaScript that interacts with the DOM poses a risk for end users as it enables attackers to deliver malicious
scripts over the web and run them on the user’s computers. For the vulnerable packages to be exploited, it requires the application to use the affected function, often in a particular way.

The SilverStripe CMS utilises an older version of jQuery. jQuery is used in large portions of the content management system, and has been ruled out for an upgrade in SilverStripe as it has been deemed too much effort for very limited gain. It should be noted that there are no known paths to exploit a vulnerability with this version of jQuery in this particular context. If such a vulnerability was found, it would be treated separately and patched by SilverStripe following our standard security release process.

The affected code file should only be referenced in the CMS, which is protected by authentication and should only be used by trusted staff. The jQuery version used in the CMS should not be used for the front-end website.

If your customer is still concerned about this, we can work with them (through you) on how they can fund an upgrade, but it won't be cheap.