Exception while attempting to export (need to refactor sf_webform_preprocess_webform() a bit)

I think this issue belongs in SF Webform's queue.

Hi I have the same problem. But I'm not using the webform module but this one:
http://drupal.org/sandbox/evandonovan/1198324

EvenDonovan commented that you should use the issue queue here for that project. So reopening. The full error is:

•Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 409 of /srv/www/htdocs/testserver/includes/unicode.inc).
•Warning: mb_strlen() expects parameter 1 to be string, array given in drupal_strlen() (line 409 of /srv/www/htdocs/testserver/includes/unicode.inc).
Exception while attempting to export webform submission. Exception was: Unexpected element {http://www.w3.org/2001/XMLSchema}string during simple type deserialization.

Just saw that the sandbox project has it's own issue list, so moving there.

I'm having this same issue. Did anyone find any resolution?

Found no solution, in the end I went with the 6.3 dev version of Salesforce Webform Data Integration.

It appears to me that in the function sf_webform_preprocess_webform, the variable $raw_data is expected to be an array, not a value, and if it is not an array it is converted into an array on line 998.

Afterwards, there is a check for the Webform field type in which some special processing occurs for types 'select', 'file' and 'date'. In each of these special cases the value is extracted from $raw_data[0].

However, in the default case (for all other field types), it attempts to call a sf_webform_preprocess_component function, and then it extracts the value of the field directly from $raw_value (note the absense of the array key [0]). This results in an array being passed through the rest of the Salesforce export, breaking things as it goes.

I believe the fix for this is to change line 1044:

$drupal_data->$form_key = $raw_data;

To:

$drupal_data->$form_key = $raw_data[0];

In my testing this causes the exceptions to stop being generated, stops the drupal_strlen() and also a similar error in the email validation function, resulting in a successful sync to Salesforce. However, not being familar with this module (I only downloaded it yesterday), I'm not sure if this is going to break intended functionality elsewhere.

Additionally, there are other places in this function where exceptions may be generated due to improper use of arrays, for example lines 1008 and 1011:

if (count($raw_data == 1) && (strtolower($raw_data[0]) === "true" || strtolower($raw_data) === "true")) {

elseif (count($raw_data == 1) && (strtolower($raw_data[0]) === "false" || strtolower($raw_data) === "false")) {

In both these checks, the 2nd and 3rd comparison are grouped, but really the 1st and 2nd comparison should be grouped:

if ((count($raw_data == 1) && strtolower($raw_data[0]) === "true") || strtolower($raw_data) === "true") {

elseif ((count($raw_data == 1) && strtolower($raw_data[0]) === "false") || strtolower($raw_data) === "false") {

This effectively says, "if raw data is an array, check the first value of the array. If not, check the value directly."

Hummm, I'm not sure if this is still relevant to anyone, but from what I can see #6 and #7 are mostly correct.

The default case in the type switch in sf_webform_preprocess_webform() is indeed not handling the $raw_data variable correctly. The reason that I have personally not noticed this issue is that I have an implementation of hook_sf_webform_preprocess_component (invoked just above the line you referenced) that has been bypassing this issue.

The only analysis that I think is not correct is the point about the conditional groupings in line 1008 and 1011. The count($raw_data == 1) is meant to see if only 1 value is passed as part of the select (an added verification that this is a boolean checkbox), it's not actually meant to check if the variable is an array. Regardless, those lines could probably be shortened to something like:

if (count($raw_data == 1) && strtolower($raw_data[0]) === "true") {
  $drupal_data->$form_key = 1;
}
elseif (count($raw_data == 1) && strtolower($raw_data[0]) === "false") {
  $drupal_data->$form_key = 0;
}

as we are already sure $raw_data is an array.

Anyway... is anyone still using this? Any chance anyone has tested these adjustments already? The version of this module that I'm currently using is already ahead of what's in this sandbox. I'd like to sync my changes here (and get this fix included) if there are actually people out there who... well... use this.

Also, sorry that there was no response to this earlier. I'm the one probably most familiar with the details of sf_webform_preprocess_webform() in the 6.x-1.x branch, but I'm only seeing this now.

It seems that the issues from this project don't show up in the aggregate list of "My Projects" even though I was helping with this code as a co-maintainer (probably due to the d.o. issue #101341: 'My projects' should also display projects that are being co-maintained). So I had no idea people were using this and having a problem with it.

I need to remind myself that sf_webform_preprocess_webform() needs some review... I think it's quite dirty after being tweaked in ad-hoc ways by multiple people over a long time. I'd like to make it a bit cleaner, even if just to make it easier to read while I'm active on a project that uses sf_webform.

Ok, I've re-worked some of the logic in sf_webform_preprocess_webform() to better handle the fact that the source data may be coming in different formats (from live form submission from from db storage, etc...). It should be easier to follow/read the logic now as well.

Patch is attached. I'm testing this out on an active site and will give it some time in the wild there before committing. Anyway, maybe this is of value to someone somewhere?

This is all part of a push for me to try to get a whole batch of updates that I've made to this module (for a client site) into version control. It's just better for me to have all this in git... even if I'm the only one who's actually using this. The other recent changes that have been captured include:

#1783118: Make sure we don't sync to SF when saving a draft
#1783138: Numerical zero (0) not getting into the export object
#1783152: Numerous errors with salesforce api 6.x-2.0-beta2
#1786310: Erratic fieldmap changes due to strange handling of salesforce_webform table

If you had a need to use this module in the past, and were having trouble, now's a good time to try again. Things have been running well for me now in a very complex integration scenario that relies heavily on webforms.

OK, this has been working well in production. I'm not anticipating any other reviews so I committed this.

Thanks for rolling this in rjacobs! I'm back on the project that uses this module and I've just updated to your most recent release on the 6.x-1.x branch. Fixed a few problems I was having so nice work!

Confirmed that this is working for me on staging.

Hi aethr. Great to hear you are able to use this again! I hope the most recent iteration proves to be stable for you as well.