When I writing JavaScript code for my module, I could use jQuery.data() or the setting object passed to the Drupal behavior my module add.

Should a module always use the settings object, or could I use jQuery.data() in my module?
Is there any case where using jQuery.data() is problematic when used in AJAX code?

2 Answers 2


Personally, I used Drupal.settings as a read-only object for communicating settings and configuration information from PHP to JS. Runtime state isn't appropriate here.

jQuery.data() should only really be used to pull out data attributes that you have set via PHP, and for setting data that is specific to that element-only.

Runtime logic and state should be stored in its own closure. I use a variant of the Javascript Module Pattern, which I have adapted for Drupal. Boilerplate looks like:

var FOO = (function(me, $, Drupal, undefined) {
    me.name = "FOO";

    // local properties

    var foo = null;
    var bar = null;

    // local functions

    function somethingAwesome () {
        console.log(me.name + '.' + arguments.callee.name + '()');

    // global properties

    me.baz = null;

    // global functions

    me.somethingAwesomer () = function somethingAwesomer {
        console.log(me.name + '.' + arguments.callee.name + '()');

    // Drupal

    function init (context, settings) {
        if (settings.foo) {
            console.log(me.name + '.' + arguments.callee.name + '()', $.fn.jquery);

            // do stuff

        Drupal.behaviors[me.name] = undefined;

    Drupal.behaviors[me.name] = {
        attach: init

    return me;
}(FOO || {}, jQuery, Drupal));

I don't do a lot of true behaviors, though, hence making my initialization function a oneshot.


They're not used for the same thing...

jQuery.data() is used for storing data specific to a DOM element.

Store arbitrary data associated with the specified element and/or return the value that was set.

The Drupal.settings object is for storing global settings specific to the enclosing page build. It's essentially used to pass data from PHP to JavaScript, not to pass/store data within a a client-side page view.

...Drupal's global storage of JavaScript settings. Per-page settings are required by some modules to function properly.

If you want to store data related to a particular DOM element, against that DOM element, then use the jQuery.data() method.

If you want to pass global page settings from PHP to Javascript, use drupal_add_js() with the 'setting' type (which results in the data being added to Drupal.settings in the front end).

You may well find yourself in the position where you're looping through items in Drupal.settings in order to save the same data against the appropriate DOM element - that's perfectly normal (in my experience anyway, a more worldly JS ninja might be able to correct me there though).

  • I could output <div data-role="page" data-last-value="43">[...]</div> from a theme function defined in my module, and those "data-" attributes would be returned from jQuery.data() to JavaScript code. What probably confuses me is the fact that the setting object is passed as parameter for a Drupal behavior; that took me to understand that the setting object could change basing on the element to which the behavior is applied.
    – apaderno
    Apr 15, 2013 at 16:04
  • I take a little issue with the last paragraph. Drupal.settings should really just be settings. If your elements needs data, render it out with data attribute.
    – mpdonadio
    Apr 15, 2013 at 16:05
  • @MPD It's standard practice - store a bunch of selectors and settings inside Drupal.settings, then apply those to the relevant elements using jQuery.data() in Drupal.behaviors. A lot of modules use that method, and probably some elements of core as well
    – Clive
    Apr 15, 2013 at 16:16
  • 2
    @Clive I think that is a leftover from D6. Since D7 ships with JQuery 1.4.4, data attributes are automagically available via .data().
    – mpdonadio
    Apr 15, 2013 at 16:27
  • 1
    @MPD True of course, but it does depend somewhat. I know everyone should be using an HTML5 DOCTYPE these days, but there are still many legacy XHTML sites which can't take advantage of those attributes while still passing validation. For a generic Drupal module it's best to cater for both, hence the strangled route to backwards-compatibility. I do take your point though
    – Clive
    Apr 15, 2013 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.