Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem
- The jquery.cookie library was temporarily absorbed by jQuery UI, but has been removed from the latest jQuery UI now.
Details
-
In reviewing/fixing our library declarations for #1996238: Replace hook_library_info() by *.libraries.yml file, I noticed that jquery.cookie was/is supplied as part of jQuery UI 1.10.2.
So I hopped on to #jquery in IRC to get some info, insights, and opinions...
- https://github.com/jquery/jquery-ui/tree/master/external does not contain it anymore.
- This commit removed it via #7162 → META: #7144
- jQuery UI's
$.cookie()
plugin had a different API than the original jQuery.cookie() library. - It might be safer to bet on the original jquery.cookie library. But then again, the code of the jQuery UI plugin is much shorter and simplified.
- OTOH, looking at what the jQuery UI plugin does, the native
document.cookie
API might be sufficient to begin with?
Proposed solution A
- Restore the jquery.cookie plugin from jQuery UI's history and include it as a fork in Drupal. (No API changes)
Proposed solution B
- Restore the original jquery.cookie library and revert all code to the original API. (future-proof?)
Proposed solution C
- Drop
$.cookie()
altogether and require all code to use the nativedocument.cookie
API instead.
Comment | File | Size | Author |
---|---|---|---|
#19 | jquery.cookie.17.patch | 7.9 KB | Bès |
#8 | core-js-remove-cookie-2161217-8.patch | 7.84 KB | nod_ |
Comments
Comment #1
scott.gonzalez CreditAttribution: scott.gonzalez commentedA few clarifications:
The cookie plugin was never part of jQuery UI. It was included as an external purely for the purpose of creating a demo to show how to use the cookie plugin with the jQuery UI tabs plugin.
The cookie plugin was copied into the external directory as is. jQuery UI never modifies external code, so it's impossible for the API to have been different.
Any file size difference (and API difference for that matter) is due to the fact that you're comparing the current version of the plugin to a version from 2010.
Comment #2
nod_I'd go with:
Proposed solution D
$.cookie()
altogether and stop using cookies to store anon username and mail for comments and contact form. localStorage does that.The only change would be that the information is saved regardless of the form being successfully submitted or not (we only save the info on form submit but if there is a validation error, the infos would still be saved).
Comment #3
sunThanks a ton for the helpful clarifications, Scott! :)
Looks like someone of us misinterpreted the mere existence of the file in the jQuery UI package as something that can be relied on ;-)
Thanks to that pointer, I checked past releases and the exact version in HEAD appears to be v1.0.
Comment #4
catchThere's no functional bug here so re-classifying. This will need a library rename (or completely killing it) so agreed on critical though.
Comment #5
maartendeblock CreditAttribution: maartendeblock commented+1 for solution D.
Comment #6
nod_Or even proposition E: remove the whole user info thing and let browsers handle it. They all remember usernames in forms now. Unless you disabled the functionality which means saving the infos in a cookie probably isn't what you'd want.
Comment #7
nod_patch for solution E
Comment #8
nod_Missed a few spots
Comment #9
sunWhile the goal of removing ballast is appreciated, to be honest, I think we need to provide an option for developers not-so-versed in JS to manage data stored on the client-side.
That doesn't necessarily have to be cookie-based, but as a web developer, I expect a web application framework to provide an API/facility that allows me to interface with client-side storage in a simple and easy way.
Also, the form autocomplete facility of browsers is very different to prepopulated form fields, because you typically have to use a built-in autocomplete facility in case varying values were submitted on similar forms (across the net, not restricted to a particular site).
Comment #12
nicksanta CreditAttribution: nicksanta commentedI think it is worth acknowledging that modern browsers all support window.localStorage, and that is a simple enough interface to store data on the client side.
Drupal 8 supports IE9+, and local storage was introduced in IE8.
I think a compromise between nod_ and sun's solutions is to replace all references to $.cookie() with localStorage, rather than remove the functionality all together.
Comment #13
sunAdding to the new parent/meta issue.
Comment #14
Bès CreditAttribution: Bès commentedComment #15
sunNote that one essential difference between localStorage and cookies is that cookie information is also available on the server-side (in PHP).
It is true that - aside from user authentication/sessions - we've replaced most usage of cookies with localStorage or alternative solutions.
But nevertheless, I wanted to point out that there can still be legit use-cases for using cookies when the identical data needs to be shared between the client-side and server-side (and avoiding an additional + async HTTP request to exchange the client-side data with the server-side).
Personally, I'd prefer to simply add the latest release of the jquery.cookie library for D8, so as to resolve this issue and get it off the table.
For D9, we can consider to re-open this discussion (in case library usage data proves that no one needs jquery.cookie anymore).
Comment #16
nod_In theory I agree, we can ship the lib or something but what we use them for really doesn't need to be cookies.
Comment #17
sunComment #18
Bès CreditAttribution: Bès commented**** Cross post message ****
I find an issue with the jquery-joyride library while creating a patch that replace cookie by localStorage for the auto fill.
We use the 2.0.3 version of jquery-joyride that rely on jquery.cookie.
Seems that the last version (2.1) can use localStorage as see here : https://github.com/zurb/joyride
This issue already talk about the joyride version : https://drupal.org/node/2027623
If joyride 2.1 works I propose to update to this version to allow the full removal of jquery.cookie.
BTW, i see that jquery.form.js also have jquery.cookie as a dependency in the core.libraries.yml but i can't find any reference of that on jquery.form's website or code.
****
Since we keep jquery.cookie, there is no issue with jquery-joyride and I hope I can soon propose a patch for the localStorage autofill feature.
Comment #19
Bès CreditAttribution: Bès commentedComment #20
sunI'd recommend to strictly limit this issue to updating the library. Anything else should be handled in separate issues.
Comment #21
Bès CreditAttribution: Bès commentedComment #22
ianthomas_ukMoving revisit before beta tag from #1203526: jquery.cookie version update
Comment #23
sunWe do not have automated JS tests, so the only remaining task here is to manually test whether e.g. the persistence of comment author information in the comment form still works.
Comment #24
penyaskitoThe cookie:
But...
form.js was not included in the form, so there is no completion. jquery.cookie.js was neither in the page.
We need to create bug reports for that if there aren't yet.
But as we only want to upgrade the library in this issue, I guess I can RTBC it.
Comment #25
catchCommitted/pushed to 8.x, thanks!
Comment #27
penyaskitoAwesome! Created #2241447: [Regression] Autocompletion for anonymous data in forms for #24.
Comment #28
ianthomas_ukNow this is fixed we don't need to pay any more special attention to this library before beta.