search module: array_merge() Argument #2 is not an array

Amusing comment. I take it you're getting a bit touchy? :)

I actually meant that I thought it might have been caused by changes in the search.module meant to comply with the new form API, not any problem with the form API itself. Seemed reasonable at the time, since it was part of a new style Form API form definition.

After some additional sluething through the various versions, while it is in a form section, it was added right after the form API changes in 1.137, for http://drupal.org/node/28159, Advanced Search Features.

See also http://cvs.drupal.org/viewcvs/drupal/drupal/modules/search.module?r1=1.1...

I'll try to avoid offending anyone by guessing and try to never use "may be" in the future.

I'll see if I can figure out a patch that fixes this bug, now that you've pointed me in the right direction. I'm an experienced programmer, but my PHP experience is extremely light (read, virtually non-existant) and I only heard about Drupal a couple of weeks ago, so I'm just trying to help test the latest versions of Drupal as I learn and report new bugs as I run across them.

Thanks for the work on the Form API, BTW.

Patch attached.

After a little module grep'ing found the same "potential" issue in a few other places. I'll attach similar patches for filter.module, node.module and an updated one for search.module in a bit.

Attaching patches for checking to see if the results of module_invoke is an array or not before attempting to use it in an array_merge for filter.module, node.module and search.module.

Tested the patches as much as I am able, please review.

First Patch attached

Second patch, for filter.module.

Third patch of three, this one updated for search.module.

Patch consolidated and revised to check only module_invoke and not module_invoke_all.

If the hook being called using module_invoke has no values to return in a particular case, what should it return instead?

Currently, when there is no valid result data to return, it appears to return a Null, leading to this error. Presumably (haven't dug through every possible call), an invoked module function can perform it's expected task and sometimes return data and sometimes have no data to return.

In that case, returning a Null would not be an error, but will cause an error if it isn't handled by the function using module_invoke.

So that's the case for error handling it by the calling function, because only the calling function presumably knows if it requires data from the module_invoke call, rather than simply wanting to add information to an array from the module_invoke if there is additional information present. That's my current assumption from my admittedly slim overall knowledge of the system.

If those assumptions are not correct, then I can see where either:

1. Module_invoke() itself needs to add an else argument and return something not Null if the result of the invoked function is Null, in which case functions using module_invoke should presumably be updated to handle whatever that alternate return value would be.
or
2. All invokable hooks need to be reviewed to ensure there is no case where they will not return valid data of some sort.

I'd personally lean towards neither 1 nor 2, because of the complications in changing expected return values for functions using module_invoke from what they currently expect as always being valid data or a Null, to always returning valid data.

Existing functions (pre this patch) already use the method in the patch to check for a Null and only merge the value returned if it's not null. See http://drupaldocs.org/api/head/function/search_form for an existing example.