Fixing FileField, part 5.

As pointed out in 3F issue #3, AHAH behaviors are not attached to newly inserted form elements if they haven't been there at initial form creation time, because the Drupal.settings object (as populated in a script tag in the HTML head) only contains id and behaviors for existing form widgets. Makes sense, so far.

However, if any CCK widget uses AHAH behaviors then those won't work with elements that are newly inserted by using the "add more" button (only in the JavaScript version, of course). Following the above explanation, that's because even though the form element is inserted, the Drupal.settings object is not updated, so AHAH doesn't know that it should attach behaviors to those form elements.

For CCK widgets that are not using AHAH, this is no problem. However, for widgets that do use AHAH behaviors, like (you guessed it), filefield, this poses a problem.

I'm using the same piece of code in filefield to overcome the same issue for quite similar problem, and it works just as well in CCK. It's self-contained and I would think that it can be applied right away - please review and commit. Thanks!

CommentFileSizeAuthor
cck-attach-ahah-to-new-widgets.diff1.3 KBjpetso

Comments

yched’s picture

yched commented

Makes perfect sense. It seems a simple call to drupal_get_js('setting') would do the same, though ?

jpetso’s picture

jpetso commented

No, it would not.

The parameter that you specify for drupal_get_js() is $scope, which declares if the JavaScript is supposed to be included in the header or in the footer of the HTML page. It is not the $type parameter that we would need in order to retrieve the 'setting' property of the JavaScript, and looking at the code there seems to be no way to retrieve a specific javascript $type.

Looking at the code again, we could however pass the $javascript array instead of the scope, and if we previously retrieve it with drupal_add_js() but first filter out all properties except 'setting' then we should get the same result without constructing the string by ourselves.

jpetso’s picture

jpetso commented

The above would, however, cause core to check if the JS preprocessor should be employed or not. From looking at it (one last time), I haven't been able to figure out if those files are appended or not, but it seems very likely that some condition could cause those to be included. I'd rather play safe and not rely on specific configurations or code paths that might change anytime, and therefore vote for keeping the patch the way I posted it.

yched’s picture

yched commented
Status: Needs review » Fixed

Right, my bad about $scope / $type.

Calling drupal_get_js() with a $javascript array containing only a 'setting' key would have no effect on preprocessed files, because the $files array would stay empty and the said code branch wouldn't be executed.
Not so sure about the locale_update_js_files() call, though, so I went with you original code.

Thanks !

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.