#ajax is not extensible (and partially buggy)

oh my... sorry, it's late here. :P

ok, I should really learn to copy + paste. :P

Also speeds up AJAX commands test.

ok, seems like the test didn't like that optimization for whatever reason. Reverted those changes.

Interesting. This seems to reveal a bug elsewhere.

This patch changes

    drupal_add_js(array('ajax' => array($element['#id'] => $ajax_binding)), 'setting');

into

    $element['#attached']['js'][] = array(
      'type' => 'setting',
      'data' => array('ajax' => array($element['#id'] => $settings)),
    );

But Drupal.settings.ajax contains only the first element that is processed on a page.

meh, silly me. This actually works like it should and is a major improvement on its own: The second AJAX settings were for a "Remove" button of a multiple value field widget in the form, which does not have a value yet, hence, the the settings were needlessly added before.

Clusterfuck. Better title.

When returning an AJAX command array, drupal_render() is not invoked, so #attached is not processed when submitting a form via AJAX. See http://api.drupal.org/api/function/ajax_deliver/7

At least, that's my current assumption. Not verified.

I'm a bit stuck in here. Not sure whether it's only the AJAX commands test that needs to be updated. If this patch works, then we only need to test manually whether AJAX still works with this patch ;)

This will make the remaining pass.

I mentioned manual testing above, because I'm not sure whether there is a full test of AJAX multiple value field operations: Add an item, add another item, remove an item, all on the same field. Afterwards, ideally try to add an item in a second field.

The question is whether - after adding an item - the attaching behaviors environment will contain the AJAX settings for the remove button. And after removing, whether it will still contain the settings for the add button 8)

Not even sure whether this can be tested in an automated way, because this requires a JavaScript environment.

And of course, it doesn't work. Let's leave that to a separate issue, because I fear it will require quite some API changes.

Instead, I've stuffed a @todo in there that explains the situation.

Anyone up for RTBC'ing this patch?

Created #656782: ajax_process_form() results in settings being returned for elements that aren't re-rendered as part of the AJAX request do deal with that #attached/caching problem.

@Damien: That's a separate issue, see you in #656782: ajax_process_form() results in settings being returned for elements that aren't re-rendered as part of the AJAX request

err, guys, these are completely separate issues. Please define scope-creep.

This patch fixes one bug. The other issue will need to fix the other bug.

Really, #656782: ajax_process_form() results in settings being returned for elements that aren't re-rendered as part of the AJAX request contains a very clear and concise description of the second bug. Did you actually read it?

It would be insane to intermix both issues. While this one is a regular and quite simple bug fix, the other issue should probably bumped to critical, since it questions our entire element processing, caching, and rendering, and may require larger changes to the AJAX framework and/or form processing and/or element rendering.

sorry, if that didn't come through - yes, this bug exists in HEAD already. It was revealed by this patch. That's why this patch does not convert all drupal_add_js() lines into ['#attached']['js'] properties, because the settings cannot be converted currently. Figuring out why that is and how to solve it, is the focus of the other issue.

I will post a patch containing that particular change (== outlined in #8 above) to the other issue. And this one-liner will break, because something goes wrong in our form or element processing/caching/rendering.