Fields converted to arrays during import are not processed as arrays by subsequent plugins

The "explode" plugin (and possibly others) will convert the imported field data from a string into an array. You may need to use other plugins to further process the data in this field. In my case I want to explode a simple list of values and then trim each individual value to strip off leading or trailing white space. For this to work, the "trim" plugin needs to be aware that the data to be trimmed is an array and not just a string. The feeds tamper module keeps track of the array-ness of field data so that it can appropriately process the field for each plugin.

With the latest update, Feeds Tamper checks to see if a field is an array or not when the line of data is initially parsed, but does not re-check the data after a plugin executes. In other words, if the field value is a string initially, but is changed to an array via one of the plugins -- such as "explode" -- then subsequent plugins will still think the field is a string. This leads to errors like:

Warning: trim() expects parameter 1 to be string, array given in feeds_tamper_trim_callback() (line 38 ...

Assuming you already have a Feeds import setup, here are steps to reproduce the error:

1. In the source file for one of your fields, add some simple comma-separated data (e.g. "a, b, c").
2. In Feeds Tamper, add the "explode" plugin and set the separator to "," (comma).
3. After the "explode" plugin, add the "trim" plugin to the same field. The default options for "trim" are fine.
4. Save your Feeds Tamper changes and run the import.
5. The imported field will be blank and the Watchdog logs should show errors like the one listed above.

I believe the root problem is that line 49

$is_array = is_array($result->items[$item_key][$element_key]);

needs to be moved into the loop below it (line 51)

      foreach ($instances as $instance) {

This would allow the field data to be re-evaluated after each plugin has finished processing the data.

Patch to follow soon.