ERROR: Warning: implode() [function.implode]: Invalid arguments passed in theme_apachesolr_search_snippets() (line 1708 of...)

same here. I am using 3.6.2 version of Apache SOLR

I've seen this happen also.

Replace
$result .= implode(' ... ', $snippet);

With

      if (is_array($snippet)) {
          $result .= implode(' ... ', $snippet);
        }
      }
      $result .= implode(' ... ', $snippets);

thanks will give it a quick try and let you know the results.

Thanks that seemed to work perfectly. I had to remove one of the closing brackets but no errors thus far.

foreach ($snippets as $snippet) {
/* this is new code added for drupal issue #1946132*/
if (is_array($snippet)) {
$result .= implode(' ... ', $snippet);
}
}
/*END this is new code added for drupal issue #1946132*/
$result .= implode(' ... ', $snippets);
/*} **removed closing bracket*/
}
}
return $result . ' ...';
}

thanks again. Any chance you are writing a tutorial integrating TIKA with SOLR? Your tutorials have been really helpful.

I created a patch to solve that issue.

But I didn't like the code and choose a different approach now. I flatten the complete snippet array and avoid the warnings, allow configuration of max snippets and avoid duplicate snippets.

I don't like that change. If someone wants to change it so drastically they can, it is a theme function afterall.
Can it not be done simpler?

This patch solved three issues:

1. Watchdog entries because of the warning
2. In some cases empty snippets: where users only see "...." because of the warning
3. Duplicate snippets: if the teaser and the content contain the same text fragment

In our production environment we've often seen case 2 and 3. (BTW both are not multilingual related.)
Since we applied the patch, the results look way better.

In addition I added a new feature to limit the over all number of snippets by configuration.

What exactly don't you like?
From my point of view the code does basically the same: walking through the snippet arrays and concatenate the snippets using " ... ". But it's done in a generic way instead of an erroneous manual way.
What makes the code look a bit scary maybe is the safety stuff to prevent endless loops, but that's a normal pattern.

The patch worked for me: 1946132.patch

Thanks Nick_vh & mkalkbrenner

Got the same issue, and this patched worked for me as well (1946132.patch).
Thanks guys. I am guessing this will make it to next 7.x-1.3 version?

+1 for this to be committed, the dblog was filling up with useless warnings relating to this, the patch attached resolved said warnings.

+1 RTBC, after module upgrade my watchdog was filled with these warnings, patch fixed all warnings.

+1 for this to be committed. #10 & #11 are not wrong about the flood in watchdog.

Seems a little heavy to be doing in the theme function in any case - can we shift to a preprocess?

There are some odd problems with how these snippets are being displayed, but for now this patch should fix the issue with this specific error message.

That doesn't look right either, since I think each element of $snippets can still sometimes be an array itself, rather than a string?

Seems like it makes sense to improve this logic and move it to a preprocess function like @pwolanin suggested. That would also allow it to be reused in other modules (for example, #1980750: Array to String error when certain file attachments appear in the search results in the Apache Solr Attachments module which is a similar bug).

The attached patch tries to do this.

So, I'd suggest maybe the last line of the preprocess still belongs in the theme function?

+  $vars['snippet'] = implode(' ... ', $vars['flattened_snippets']) . ' ...';

Agree with #16

So patch #15 fails to address to root problem here that patch #5 did. After getting 7.x-1.x-dev and applying patch #15:

Notice: Undefined index: snippet in theme_apachesolr_search_snippets() (line 1715 of /var/www/mts/sites/all/modules/contrib/apachesolr/apachesolr_search.module).

Backtrace is here:

@wiifm, did you clear caches after applying the patch?

So, I'd suggest maybe the last line of the preprocess still belongs in the theme function?

That could definitely work, but the reason I didn't do it that way originally was:

1. It would mean all theme implementations would be using a somewhat-unfortunately-named variable, $vars['flattened_snippets']. (The better name for that variable is of course $vars['snippets'], but that's already taken and would require breaking existing implementations in order to use here.)
2. I figure it's pretty rare that someone would actually want to replace the "...", so why not just provide it for everyone? Example: The patch in #1980750: Array to String error when certain file attachments appear in the search results can use this directly. It helps promote consistency between different theme implementations.

Unlike my patch in #5 the patch in #15 doesn't remove duplicates.
Duplicates happen very often when the teaser contains the first n characters of the body (or content).

Agree with #16 as well. Also tagging for backport.

@David_Rothstein - hey, thanks, after clearing the cache, the errors went away.

+1 for #15 to be committed.

Seems like most people prefer #15 instead #5 ;-)

So here's an adjusted version of patch #15 that
- ensures that the snippets contain no duplicates
- respects Peter's suggestion in #16 regarding the theme function
- keeps the unmodified $vars['snippets'] for backwards compatibility in existing themes

#24 is solid. Please commit!

Agree, +1 on #24. It makes sense to keep any markup generated in theme functions.

Thanks for adding the array_unique(), @mkalkbrenner. Sorry I missed that.

I've posted an updated patch at #1980750-7: Array to String error when certain file attachments appear in the search results to work with the new patch in #24 here.

Here is a shot at a D6 backport. To avoid adding a template file, I had to merge the preprocess and theme functions back together per this issue: #400292: Allow preprocess functions for theme hooks implemented as functions. Patch attached.

#24 is the RTBC patch.

For 6.x, perhaps we should keep the separate " preprocess" function, but just call it directly from the theme function, or before the theme function?

For 7.x, this is in essence an API change because it's a different variable name? I guess that's ok.

Committed to 7.x. Here's a revised backport.

I like the motivation behind the patch in #31 for keeping the functions separate. I was however, receiving the following error with the patch applied:

array_merge(): Argument #2 is not an array in apachesolr_search.module on line 1805.

I made the following changes to fix this error and make the code a little more readable:

• Removed the $vars parent array as it is not necessary with this pseudo preprocess function
• Converted the first array_merge() call in the foreach loop to direct assignment, as we created the $flattened_snippets array and can be assured that these values do not already exist

If the goal is to keep the code as close to D7 as possible, we could undo my changes and simply replace the first array_merge() call found within the foreach loop with similar syntax found in the second array_merge() call used within the function:

$vars['flattened_snippets'] = array_merge($vars['flattened_snippets'], is_array($snippet) ? $snippet : array($snippet));

Thanks for the fixes.

I was trying to keep it as close to 7.x as possible to make it easier to backport any further patches. Can you roll it that way?

OK, new patch attached only changed the first array_merge to ensure we are merging arrays!

Fixed typo in variable name in patch from #34.

#35: 1946132-D6-35.patch queued for re-testing.

Hi, sorry for ignorance, but is this patch available for 7.x-1.3? I'm seeing this error in abundance.

Many thanks,
Dan.

@dbolser: #24 should already be included in 7.x-1.3. Do you still see the error?

Dang... Just updated, and I'm guessing this was a caching issue! Seems fine now!

Many thanks,
Dan.

committed

I still see the error with latest 7.26 Drupal, Apache Solr 7.x-1.6 and Apachesolr Views 7.x-1.0-beta2.

Warning: array_merge(): Argument #2 is not an array in apachesolr_search_preprocess_apachesolr_search_snippets() (line 1709 of ...

I don't quite understand WHY the 1716 is like this:

$vars['flattened_snippets'] = array_merge($vars['flattened_snippets'], is_array($snippet) ? $snippet : array($snippet));

and line 1709 is like:

$vars['flattened_snippets'] = array_merge($vars['flattened_snippets'], $snippets[$key]);

In my case I get snippets array not multidimensional but like $snippets['content'] = 'snippet'. The change condition of array merge fixed everything:

$vars['flattened_snippets'] = array_merge($vars['flattened_snippets'], is_array($snippets[$key]) ? $snippets[$key] : array($snippets[$key]));