Drupal is a registered trademark of Dries Buytaert

jq_ui

15 sites Security covered
View on drupal.org

This module is a drop-in replacement for the jquery_ui module thanks to the composer replaces directive.

Steps to replace jquery_ui:

Step 1) composer require drupal/jq_ui

Step 2) drush en jq_ui -y;

Step 3) drush cr;

Step 4) Sip from a marguerita

How is this possible you might ask? composer replace and a repaired copy of the jquery_ui in the jquery_ui folder inside of jq_ui!

Why was jQ UI created?

Nearly 3 years went by waiting for a solution to a date picker refactor regression. It's a bit complicated to explain the history but to make it short, the easy solution is jQ UI which easily replaces jquery_ui. I decided there was not another day to waste without a proper solution.

What version of jquery_ui drupal module did jQ UI start from?

We started from version 1.7. jQ UI includes an important localization fix. spun from #3339013: implement datepicker localisation in jquery_ui 2.x, compare with jquery_ui_datepicker 1.x that has localisation as well as a newer version of the jQuery UI library #3543903: update to jQuery UI 1.14.1 and remove duplicate js/css files

What this module provides:

A wrapper module around the jQuery UI effects library that lets module developers add swooshy, swishy effects to their code.

See http://jqueryui.com/demos for some examples of what jQuery UI can do.

See http://jqueryui.com/docs for documentation on how to use it.

See http://jqueryui.com/support if you need help getting jQuery UI to work, once it's being added to your pages.

This is a utility module that won't do anything on its own. See README.txt for how your module can use it to add jQuery UI effects to your pages.

Drupal 11

This contrib project now has an 8.x branch to provide the asset libraries which are no longer provided as an API by Drupal core .

The individual jQuery UI asset libraries are provided in separate modules.

Executive summary

For organizations with official-language obligations (e.g., Canada-wide federal ministries, agencies, crown corporations, and many provincial/NGO organizations as well as some Canadian provinces), the native HTML5 <input type="date"> is not acceptable because its locale follows the browser/OS rather than the page language and CMS configuration. That produces mixed-language interfaces and fails bilingual audits. jQ UI is CMS-driven, page-language aware, consistently localized, and testable across browsers—so we standardize on it.

Problem statement

  • The label and regional Language of the widget must follow the language of the current page, not the device.
  • Compliance & auditability: An example is Canadian Federal bodies (146+ ministries, agencies, and tribunals) and many provincial/NGO sites are checked for bilingual UI parity. A date picker that locks language based on OS or browser client language is a hard fail.
  • Operational reality: Native pickers remain inconsistent by browser and ignore CMS language in many cases, causing recurring production bugs and audit findings.

Why native HTML5 date inputs fail here

  • User-agent controlled locale: Browser/OS decides the widget language. The page lang attribute cannot uniformly override this.
  • Cross-browser variability: Different engines ship different calendars (or none), yielding discrepancies in labels, formats, and week starts.
  • Limited CMS control: Centralized settings (format, first-day-of-week, aria labels) cannot be reliably enforced across the support matrix.
  • A11y unpredictability: Screen reader strings and keyboard behaviors vary between native implementations, complicating testing and documentation.

How jQ UI solves it

  • Locale follows page/CMS: We initialize locale from the CMS route language; month/day names, aria strings and messages match the page language.
  • Uniform cross-browser UX: One widget everywhere eliminates native discrepancies.
  • Policy conformance: Deterministic multilingual rendering aligns with official-language expectations and Treasury Board–aligned web standards.
  • Robust formatting & validation: Separate user-friendly display format and canonical submit format (ISO 8601) prevent parsing errors.
  • Accessible by design: Single component with documented keyboard support, roles, and labels that we can regression-test.

What this project adds over the legacy jquery_ui module

  • Localization fixes: Ensures the widget language (ex: datepicker) is tied to the page/CMS rather than the browser, closing long-standing gaps in multilingual deployments.
  • Modernized asset delivery: Lean libraries and optional lazy-loading of locales minimize bundle impact.
  • Drupal-first integration: A thin wrapper exposes a stable API for init options (regional settings, dateFormat, messages) and test hooks.
  • Upgrade posture: Tracks upstream jQuery UI releases (e.g., 1.14.1+) while keeping a swap-friendly abstraction should the platform offer a compliant native picker in future.
Context: Teams repeatedly encountered non-localized calendars until a localization patch was applied. jQ UI bakes in those fixes so implementers don’t miss them.

Compliance context (Canada & similar jurisdictions)

  • Applicable to federal departments, agencies, tribunals, and crown corporations, all subject to official-language obligations.
  • Often adopted by provincial governments and federally funded NGOs.
  • Comparable expectations likely in multilingual jurisdictions (e.g., EU institutions, Belgium, Switzerland).

Activity

Total releases
4
First release
Aug 2025
Latest release
5 months ago
Release cadence
4 days
Stability
75% stable

Release Timeline

Releases

Version Type Release date
8.x-1.8 Stable Sep 10, 2025
8.x-1.7 Stable Aug 29, 2025
8.x-1.6 Stable Aug 29, 2025
8.x-1.x-dev Dev Aug 29, 2025