WordPress 5 only supports jQuery 1 while the rest of web development world have moved to jQuery 3 long time ago. One most trivial use case is spicing up your front-end with Bootstrap 4. This may be made to work but it can break with any random plugin or WordPress update.
Given that Classic Press is already a break away from WordPress legacy, it must be feasible to have it run with jQuery 3 for users who are happy to use a limited subset of compatible plugins.
@Mte90 that issue is mostly about documentation for our browser support policy. In terms of IE, we officially support IE 11 and higher.
@mkrivoshein I’d like to keep ClassicPress more up to date that WordPress regarding dependencies like jQuery. I think the problem with this upgrade is that it will break a lot of plugins and themes.
Maybe a good way to start is to make a plugin that replaces the version of jQuery, and make that available for use and testing so that we can figure out what will break.
I think there are some plugins that replace version of jQuery. However this needs to be done at WordPress level, not just at plugin level. My thinking is more about allowing an administrator to select which version of jQuery the instance should be using. Very much like you can select which version of PHP your site should run on within your hosting account settings.
I’ve seen this also. It’s a really bad practice and a brazen, self-serving thing to do. Changing the jQuery version will almost always break something. Then, the guilty plugin works just fine, so, the user is sent off on a wild goose-chase trying to solve the problem in places where it doesn’t exist.
You’ll have to ask the WordPress folks about WordPress.
I don’t see a problem with that – it gives the end user complete control. On the other hand, I wouldn’t add the functionality to core. Probably 99% of users will be fine with the version that ClassicPress bundles, making this more suitable as a plugin.
These are just my opinions on it. You are always free to raise a petition.
What about the idea of making different versions of jQuery available as different function name(space)s…? That way you could keep current backwards compatible version of jquery as jQuery so as not to break anything, but add a new version of jQuery with a different base function name such as jQuery3 (ie. just find/replace the function name in the code to pseudo-“namespace” it.)
So then, a plugin wanting to implement something that requires a different version (eg. as in the OP example of Bootstrap 4) would be responsible for using the namespaced function jQuery3 instead of jQuery in it’s own code, as well as enqueueing the new jQuery3 script handle on pages that use it of course (by simply adding jquery3 as a script dependency handle for their own script enqueues.)
I think jQuery 3 should be 100% compatible with ClassicPress, unless there is a need to support old versions of Internet Explorer. I haven’t had time to test this yet but, if it turns out to be true, the question will then become whether we need to support those old versions of IE.
So I don’t think we need to consider more complex solutions until we can get some testing done.
I tried to use jQuery 3 due to the current version bundled in WP/CP is known to have security issues. It broke a bunch of plugins, so, I had to revert back. Just mentioning this to clarify that some plugins rely on the current version, it’s not just IE.
Any time you say “this should work” when referring to code, especially moving large chunks of code around, you’re likely in for a series of unpleasant surprises.
With a medium to large amount of effort, we could make core fully compatible with jQuery 3, but plugins and themes would need to keep up also. This means we’d need to do this change in a new major version of ClassicPress with an upgrade process that checks each plugin or theme for compatibility (known good, known broken, or unknown).
Until there is some kind of dependency declaration engine, updates like this are going to break things, and it is way too much of a time burden in conflict testing, which is why I suggested a backwards-compatible solution in the meantime.
This is going to be a recurring theme for updating a few things. Creating a system where plugins / themes can at least register a list of tested compatible script and other resource versions would probably need to come first. All that registration would need to do to begin with is provide a way to have this information readily accessible to outside the plugin / theme itself, a kind of Resource API if you will.
A simple file format (YML?) that could be included with plugins / themes so that authors can indicate the versions of resources used in each particular version would allow for searching for a compatible version if needs be (and make the information available even if the plugin / theme in inactive.)
