warning: preg_match() expects parameter 2 to be string, array given in /<SiteRoot>/includes/bootstrap.inc on line

Great! - So I'm not correct ... Yet the problem remains resolved with the manual change implemented on 3 sites.

The fact remains that it is still throwing the error ... any insights there? It's being thrown specifically because of the trace I've provided.

Instead of closing - perhaps you might ask for more diagnostic information? something that might have led me to the fact that this, indeed, is the start of the fault? what else might you need?

What is $type supposed to contain following the call to module_invoke?

Line 207: $type = module_invoke($name, 'search', 'name', TRUE);

I modified the module to dump the variables to watchdog. On one of my configurations exhibiting the problem, it is being called 5 times with the first 4 results showing
$type result:

"a:1:{i:0;a:1:{s:5:""$type"";s:7:""Content"";}}"
"a:1:{i:0;a:1:{s:5:""$type"";s:5:""Users"";}}"
"a:1:{i:0;a:1:{s:5:""$type"";s:4:""Help"";}}"
"a:1:{i:0;a:1:{s:5:""$type"";s:7:""Gallery"";}}"

As you see here - the values of $type are, indeed, string values.

However - the final call results in $type containing an array value of about 14K characters starting with

"a:1:{i:0;a:1:{s:5:""$type"";a:9:{s:6:""sinput"";a:4:{s:6:""#title"";s:6:""Search"";s:5:""#type"";s:9:""textfield"

(Note the array:9 result returned from module_invoke)

that 14K segment ends with

s:14:""Search Results"";}s:7:""#prefix"";s:40:""<div id=""results"" class=""search_hidden"">"";s:7:""#suffix"";s:6:""</div>"";}}}}"

I can provide the whole array but I'm not familiar enough with your code to do much more diagnosis beyond this. If the problem is, indeed with the module_invoke functionality - I'll have to dig more but I'm not sure what that call is intended to return.

Moreover, I don't do much drupal coding. It would be helpful and appreciated to get some debugging hints from those of you who DO ...

This is the formatted parameter list from backtrace:

page_manager_search_build_subtask(
	a:2:{i:0;
		a:15:{
				s:9:"task type";
				s:4:"page";
				s:5:"title";
				s:6:"Search";
				s:8:"subtasks";
				b:1;
				s:16:"subtask callback";
				s:27:"page_manager_search_subtask";
				s:17:"subtasks callback";
				s:28:"page_manager_search_subtasks";
				s:15:"hook menu alter";
				s:30:"page_manager_search_menu_alter";
				s:12:"handler type";
				s:7:"context";
				s:13:"get arguments";
				s:33:"page_manager_search_get_arguments";
				s:24:"get context placeholders";
				s:32:"page_manager_search_get_contexts";
				s:6:"module";
				s:12:"page_manager";
				s:4:"name";
				s:6:"search";
				s:4:"path";
				s:51:"sites/all/modules/ctools/page_manager/plugins/tasks";
				s:4:"file";
				s:10:"search.inc";
				s:13:"plugin module";
				s:12:"page_manager";
				s:11:"plugin type";
				s:5:"tasks";
			}
			i:1;s:14:"plugin_manager";
		}
		)[search.inc:190]

Therefore - it appears that plugin_manager is the culprit. The plugin_manager search function appears to be on

Line 572: function plugin_manager_search()

Following your clue, and combining it with the other functions which seem to present "Search," this is what grep shows for advanced help and plugin_manager from the modules directory:

grep -r "function.*_search\("

../advanced_help/advanced_help.module:function advanced_help_search($op = 'search', $keys = null) {
../plugin_manager/plugin_manager.admin.inc:function plugin_manager_search(){

Therefore it appears that the issue is with the plugin_manager's implementation of search. I will re-queue this to the plugin_manager as a bug...

Thank you for the hints...