Add a small cookie handling functions to drupal.js

patch applied cleanly and works for me, passed simpletests.

Is adding cookie functions to the Drupal object preferable to using a jQuery cookie plugin?

Drupal isn't doing a lot of cookie-ing, just the has_js and when anonymous users comment with contact info.

To test:

1. Clean install, apply patch
2. login to your site. at this point you can verify that has_js = 1 when javascript is enabled in your browser by inspecting cookies via your browser manually (preferences / privacy / show cookies in firefox)
3. go to admin/user/permissions and allow anonymous users to comment w/o approval
4. create a node of any type, 'page' is good
5. go to admin/build/node-type/page, under comment settings and anonymous commenting, select Anonymous posters may leave their contact information
6. logout
7. go to your created node and click 'add new comment'
8. verify your contact information in the submitted comment
9. now comment or reply again, and the name, mail, homepage fields should be filled out with your previous info (they should also be available through your browser, see step 2)

Code looks useful and clean. Love the clean new API ... Session tests all pass. RTBC.

In Drupal.behaviors.comment both jQuery and $ are used to call jQuery. This is inconsistent. We should use $ in both places.

Patch no longer applies cleanly, can re-roll if there is still interest.

yes please

Patch re-rolled against HEAD

It is saving the cookies, but not does not retrieve them as indicated in step 9. Any ideas?

What if we were to bring in the jQuery Cookie plugin instead? Open source is all about working together on stuff, and the plugin is both GPL and MIT, so I don't see why not..... Unsubscribing.

If path, domain and secure options where sent from the server in Drupal.settings, then Drupal.cookie could use those options to provide defaults. And that would cover the client-side aspect of another issue I opened yesterday: #445098: Provide a consistent method to generate cookies.

Using path and domain passed by Drupal.settings would generte cookies under the same scope Drupal session cookies are generated. Also, callers of Drupal.cookie would not have to think about the secure option.

I believe basePath does not necessarily need to match cookie path setting. For example, basePath could be '/mysite/', but cookie path be set to '/'.

Instead, drupal_add_js() could populate cookiePath, cookieDomain and cookieSecure to provide defaults in Drupal.cookie consistent with session cookies.

+      $cookie_params = session_get_cookie_params();
       $javascript = array(
         'settings' => array(
           'data' => array(
             array('basePath' => base_path()),
+            array('cookiePath' => $cookie_params['path']),
+            array('cookieDomain' => $cookie_params['domain']),
+            array('cookieSecure' => $cookie_params['secure']),
           ),
           'type' => 'setting',
           'scope' => 'header',
           'weight' => JS_LIBRARY,
         ),

Well, then there could be a server-side function that adds cookie stuff to client-side. Something like drupal_add_js_cookies(), and there's where these options are populated to Drupal.settings, and the javascript methods added to the Drupal object.

hmm... but we need "has_js" on every page, so my previous idea does not worth.

Anyway, we already send basePath minimum on every page that has javascript. The cookie stuff is not so much data, it's just a path, a domain and a boolean. :-/

PS: Sorry for double posting.

basePath doesn't necessary need to match cookie path. Also, still not passing session_get_cookie_params() to Drupal.settings.

If we get rid of "has_js" cookie, then I think we could provide drupal_add_js_cookies() API that would expose the javascript API for cookies, and cookie settings in Drupal.settings. Also, creation of "has_js" would have to be moved to batch API.

"Also, creation of "has_js" would have to be moved to batch API.".
Batch API relies on the fact that has_js has been set by some (non batch-related) drupal_add_js() in one of the previous pages in the browsing session.
If batch API becomes the only setter of has_js, then you lose the feature, and all/most batch processing pages will be served using the non-JS refresh

My comment was just a response to #16. In the same line: If Batch API needs someone else to set the "has_js" cookie, then Batch API could provide an API to do so.

On the other hand, if "has_js" is part of the Drupal framework by itself, then it doesn't make sense to remove it. :) ...but then, I would say it needs to be created under the same scope as session cookies, and this would require to append cookie options to Drupal.settings for all pages that output javascript. This would provide a consistent method to define cookies that can be shared between subdomains on the same installation.

Worths the cost of sending a path, a domain and a boolean in Drupal.settings for this? IMHO, yes. :)

Why are we loading the cookie js on every page? Wouldn't it be more appropriate to keep it as an eternal library and call it when it's needed? Or, am I missing something?

I definitely didn't follow the ins and outs of the issue here. Just to bring more light on has_js / batch API :
The Batch API JS behavior is one that cannot degrade within the same HTML. If JS is disabled, you need to serve different HTML, so you need to get the 'JS enabled' info from a previous page request.
The intent of using the existing has_js cookie was to make the use of batch API more accessible, and avoid requiring specific code on the page that potentially triggers the batch processing. has_js solution is not perfect, but limits the chances of false positive (which would be critical - the only case where this breaks is if you intentionally disable JS just before triggering the batch)

Other suggestions for this are definitely welcome, but not having to 'prepare' for batch processing from a previous page is fairly precious IMO.

Probably a crosspost ?

"(As a side note, if you disable JS but have the cookie already set, batch API will fail)"
Yes - from my #21: "the only case where this breaks is if you intentionally disable JS just before triggering the batch". We left this (really edge) case out on purpose, for lack of a better proposal. Again, the current is not perfect, but the pros outweight the cons.

"Is there a reason why we can't use ?"
Missing bit ? ;-)

Why are we deviating off of http://plugins.jquery.com/files/jquery.cookie.js.txt ?

The function `$.cookie()` is based on and API compatible with............

.... Ah, to use Drupal.settings.basePath?

@robloach - that was asked in the first followup and answered in the second. ?

#507072: Add jquery cookie library introduced the vanilla jQuery Cookie library into core. Let's refocus that issue on using it ;)

There are still some improvements from the most recent patch here that should get into d7. anyone willing to reroll using our new cookie library?

Actually they were all fixed independently.