WordPress 7.1 Upgrades jQuery UI to 1.14.2: What Changes

Every few years, a dependency that has been quietly sitting under the WordPress admin for a decade gets a version bump, and every plugin author who has not opened their JavaScript folder since 2018 gets a small surprise. This week that dependency is jQuery UI, and the version is 1.14.2.

Twenty years in, I still watch this pattern closely. Not because jQuery UI is glamorous — it is not — but because the way WordPress ships a library upgrade tells you more about the project’s engineering culture than any keynote. The version bump lands with a legacy-compat flag flipped on, an old browser explicitly dropped, and a short list of removed helpers you were probably not using anyway. That is the whole change. If you built well, you upgrade for free. If you built against private APIs, you find out this week.

Here is what actually shipped, what to check on your own sites, and what not to do about it.

What is actually new

WordPress 7.1 upgrades the bundled jQuery UI from 1.13.3 to 1.14.2. Aaron Jorbin’s dev note “jQuery UI updated to 1.14.2 in WordPress 7.1” on Make/Core (July 29, 2026) documents the change, reviewed by Joe Dolson and Adam Silverstein, tracked as core Trac ticket #62757 and landed as changeset [62747]. The upgrade rides in WordPress 7.1 Beta 4, released July 29 with 114+ updates since Beta 3, and ships with 7.1 GA on August 19, 2026.

Two things about the upgrade matter more than the version number. First, jQuery.uiBackCompat is set to true in core, which keeps the 1.11-era API available alongside the new one. Per the jQuery UI 1.14 upgrade guide, back-compat is disabled by default upstream in 1.14 — WordPress core deliberately flips it back on so plugins written against the older signatures keep running. This is the same governance move you have seen a hundred times: dependency moves forward, the compat layer stays lit, nothing breaks on Tuesday.

Second, four helpers are gone for good. $.fn._form, $.ui.ie, $.ui.safeActiveElement and $.ui.safeBlur are removed in 1.14. Core does not use any of them, and per the upgrade guide the replacements are one-liners: $( elem ).prop( "form" ), native document.activeElement, and $( elem ).trigger( "blur" ). These were internal workarounds for Internet Explorer quirks, which brings us to the third piece.

Internet Explorer and Edge Legacy are no longer supported by jQuery UI itself. WordPress 7.1 aligns with that — the dev note calls out that this matches the current WordPress browser support policy. If you had admin-side JavaScript still branching on IE, this release is where you delete the branch.

Everything else in 1.14.2 is quiet: tab IDs with unicode characters render correctly, tabs work on pages with URL credentials, and the ancient Mousewheel plugin dependency is gone. The library still tests clean against jQuery 1.12.4 through 4.0.0.

Why it matters for WordPress and WooCommerce people

jQuery UI is one of those libraries whose absence you would notice within an hour. Datepickers on custom fields, sortable draggables in admin screens, autocomplete in taxonomy pickers, resizable dashboard widgets, ancient tabbed settings pages — a large chunk of the older plugin ecosystem still leans on $.datepicker, $.sortable, $.autocomplete, $.dialog. Every one of those APIs is still there in 1.14.2, and with jQuery.uiBackCompat switched on in core, the 1.11-era call signatures still work too.

The risk surface is small and specific. It is any plugin or theme that reached past the public API into $.ui.ie, $.ui.safeActiveElement, $.ui.safeBlur, or $.fn._form — usually because someone copy-pasted defensive IE code from Stack Overflow in 2014. Those calls throw silently in the admin console after upgrade. Nothing crashes the site; a widget just stops opening, or a form submission handler misfires.

For WooCommerce agencies, the interesting question is the long tail of extensions. Any Woo plugin that has not seen an update since 2020 could plausibly have a $.ui.ie check in a date-range filter or a report screen. The fact that the fatal-error surface is zero — core-side, at least — is exactly why WordPress can ship a jQuery UI major bump in the middle of a beta cycle without half the ecosystem calling for hotfixes. That governance layer is what you are paying for when you pick WordPress over a hosted platform.

There is also a smaller signal in the choice of 1.14.2 over waiting for a hypothetical 1.15. The jQuery UI release cadence is what it is; core is picking up the current stable, keeping compat on, and moving on. Not shopping for a rewrite, not lobbying for a replacement — just the boring version bump that has been overdue since 1.13.3 in the 6.x line.

What I would do (or not do) about it

Three-pass audit on staging with WordPress 7.1 Beta 4 or a Playground blueprint. First, grep every plugin, theme, and mu-plugin folder for the four removed symbols: $.fn._form, $.ui.ie, $.ui.safeActiveElement, $.ui.safeBlur. On a typical agency codebase this finds zero hits or one hit — the one hit is where you spend your time. Replace with the documented equivalents, ship a small point release, done.

Second, open every admin screen your team touches weekly with the browser console open. Datepickers on custom post types, sortable admin lists, tabbed settings pages, dashboard widgets that resize, autocomplete taxonomy inputs. Look for jQuery UI deprecation warnings or thrown errors. Fifteen minutes of clicking will tell you more than an hour of code review.

Third, if you maintain a distributed plugin or theme, drop the IE-specific defensive branches now. They were technical debt in 2020; in 2026 they are actively confusing. Delete, ship, breathe.

What not to do. Do not turn jQuery.uiBackCompat off in a mu-plugin to “clean things up” — that flag is the reason the ecosystem stays intact, and flipping it is a decision for the WordPress project as a whole, not one site. Do not install any plugin that promises to “modernise jQuery UI usage” across your admin; the surface being modernised is one hundred lines of JavaScript spread across your own codebase, and a plugin cannot see inside your code any better than grep can. Do not stack this test cycle on top of the WooCommerce 11.0 window — WC 11.0 now lands August 4 after last week’s RC1 fatal, and putting two moving targets in the same triage queue is how you spend a weekend narrowing which one broke.

One broader signal. Every release cycle has one of these upgrades — a library bumps, a compat flag flips on, four helpers get retired, browsers that stopped shipping updates in 2020 get dropped. Unglamorous, quiet, no fanfare. That is precisely why a WordPress site from 2015 still upgrades cleanly in 2026, and why I am still recommending it to enterprise clients who have watched three hosted CMS platforms deprecate their integrations in the same window.