Flag that makes it possible to have non numeric $entry[] keys

Hi Carl, you and I traded a few emails last week about forum access and API integrations. As I mentioned in one of those emails, my company does a lot of API integration work. We've just wrapped up a nice set of lead and contact forms that integrate with BatchBook for one customer, and we plan to do more custom integrations with Gravity Forms as the forms platform.

On to my Feature Request - it would be great if you could add a flag that allows us to have Gravity Forms use non-numeric keys for fields in the $entry[] object/array. I looked through the code and noticed that you're stripping 'input_' off of the field names before inserting them into $entry[].

We post all form fields out to various services, and I'd prefer to just be able to use http_build_query($entry), but I'm having trouble with the complex field keys. http_build_query() has an option that adds a string prefix to numeric keys (since PHP doesn't like numeric keys inside $_POST[]), but it doesn't catch the complex field key names like '5.1', '5.2', etc.

This means we need to loop through $entry[] and sanitize the complex field keys before building our query and sending it off into the aether. Would be nice if we could just set a flag that says "don't strip 'input_' off of the front of the $_POST[] key".

Hope that makes sense :-)

HI Alex,

That's a good question. I'm not sure exactly where the hook would need to go, but I'll describe what I'm doing and maybe that'll be enough to help you figure it out.

Right now we're adding an action on gform_post_submission. Currently we have to sanitize the keys in $entry[] - we're just replacing '.' with '_' in all keys so that a key like '5.1' is turned into '5_1', which makes PHP treat the key as a string instead of a decimal number.

$cleaned_entry = array();
	foreach ($entry as $k => $v) {
		$cleaned_entry[str_replace('.', '_', $k)] = $v;
	}
	$post_vars = http_build_query($cleaned_entry, 'f');

The 'f' in that http_build_query call adds an 'f' in front of any key that is an int.

So, consider an $entry[] with the following key value pairs:
1=email@example.com
2.1=John
2.2=Doe

http_build_query($entry[]) with no preprocessing and no 'f' parameter gives us the following querystring:
1=email@example.com&2.1=John&2.2=Doe

PHP doesn't like $_POST[] items with numeric keys, so we use the prefix trick, http_build_query($entry[], 'f'), which results in the following querystring:
f1=email@example.com&2.1=John&2.2=Doe

Our first key (1) is 'fixed' but PHP doesn't add the 'f' in front of the 2.1 and 2.2 keys, unfortunately. So we need sanitize the entry with the code I showed above, first. Then http_build_query($cleaned_entry[], 'f') returns the following querystring, with all numeric keys replaced by string keys:
f1=email@example.com&2_1=John&2_2=Doe

We then drop that string into a cURL post to an external service (also PHP). The external service is happy with the string keys, but doesn't like the numeric keys (neither ints or decimals).

It's not huge, but it's an extra step that has to be performed by anyone who wants to package up $entry[] and send it off to some external PHP service for additional processing. Would be great if there was a flag that I could set that just says 'don't strip "input_" off of the front of key names in $entry[]', in which case http_build_query($entry[]) would return the following querystring:
input_1=email@example.com&input_2.1=John&input_2.2=Doe

Make sense?

Adam Cancado: Even better, we have always wanted to develop an add-on that will post to third party services, allowing you to specify the name for each form field.

Yes. I think this would be a better solution, anyway. Want some help writing it? I'm digging into the code to do just that at the moment. I was thinking of having it try to use the adminLabel, if it exists, the normal label, otherwise. I'd sanitize whichever one we used. Probably use the built-in sanitize_title_with_dashes() WordPress function. I'm pretty confident that would generate valid keys.

I'm sure you're aware of this, and hindsight's 20/20, but using floats and ints cast as strings for array keys can cause problems in some situations (such as in our use).