hook_elements override instead of merge

Just thoroughly tested patch and it works. Been talking with chx on IRC for almost 2 hours, if this patch was in there I don't think I would have had any issues and chx would not have had a headache ;-)

However, one problem does exist. If the same value is to be overriden twice, there is a race condition. For example, if one module has hook_elements() defined and defines #suffix = foo for all textareas, and another defines #suffix = bar for all textareas, whichever module's hook is called last (alphabetically) will take precedence. This happens for *all* form values, #prefix, #process, etc...

New patch works great.

One caveat, if you use hook_elements() and set #process to a callback, if this callback overrides say #suffix or #prefix for a textarea that has been defined elsewhere, you will have to do something of this nature: if (isset($element['#prefix'])) if (is_array($element['#prefix'])) ... else $elemen...=array($ele... $mystring)

An example of how to test this (see TinyMCE.module for full code) if you have defined a #process callback:

    // Because we are calling this function from #process we need to make sure we don't override any other values
    if (isset($element['#suffix'])) {
      if (is_array($element['#suffix'])) {
        element['#suffix'])[] = $wysiwyg_link;
      }
      else {
        $element['#suffix'] = array($element['#suffix'], $wysiwyg_link);
      }
    }
    else {
      $element['#suffix'] = $wysiwyg_link;
    }

Wouldn't it be nicer if modules would not have to worry about overwriting other module's values?

Dries this patch fixes the *biggest* override problem that I encountered when defining hook_elements() that was simply not even the slightest intuitive and chx can attest to this :-)

While I agree about my last comment and #process, I'm not aware of a better practice for this isolate case. This patch doesn't introduce this problem (at least to my knowledge it is already there) but at least fixes the other more major override problem. Perhaps someone with a better understanding of forms.inc can create a patch to fix this caveat in that special circumstance (only override left after this patch).

Patch fully tested and working 100%. Tested various #suffix defined in different places, including hook_elements() and in #process callback functions. Nothing was overwritten so long as ['#suffix'] .= 'foobar' was use, e.g., appending the string to the #suffix or #prefix string.

I think this solution is very elegant and *much* nicer than the above proposed array patch. Modules can make use of this extremely easily, all they have to do is append the string and it works, no long, overdrawn array tests and what not. Please commit!

Modules still work with this patch, however after recent commits, the patch is off by 19 lines, but still applies cleanly.

- I don't understand where you explain that people need to append the string. Please elaborate.

- In general, I don't like code which allow both scalar and array values to be used. Simpler is better.

Right Dries, simple example:

hook_elements() {
  $type['textarea'] = array('#process' => 'foobar');
  return $type;
}

foobar($element) {
  $element['prefix'] .= 'append this text to prefix of textareas';
}

Simple enough! We'll make sure the Forms API docs make this clear since it can be confusing, but in reality, this is much of Drupal works, just append strings :-)

Committed to HEAD. Thanks.

I guess an equivalent patch which isn't attached to this issue got committed?

I see the $cache = array_merge_recursive changes in CVS, but the changes around line 268 are different from any of the patches here.