PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Make gform_post_submission() $entry keyed array

  1. Why, oh why is the $entry data a numbered array when hooking gform_post_submission and others?

    Ok, not that bad - but this makes it a real pain for developers trying to hook into form submissions - it's almost as bad as having to hardcode form IDs / Post IDs so you are tied to the current database. I think it would be good to use the Admin Label (or some other name) to identify the field.

    I am not sure where the numbers are set (either order top-to-bottom or order added to the form) but it just doesn't seem very developer friendly.

    Just a suggestion :)

    Joe Hoyle

    Posted 13 years ago on Friday June 17, 2011 | Permalink
  2. The fields are dynamically generated when you add a field to a form. Gravity Forms is a form builder so everything is data driven and based on id's.

    The Admin Label's aren't always "code friendly" because they are user generated and optional, they aren't required. So using the Admin Label isn't necessarily a good way to handle it either.

    The Field ID's are generated when a field is added to a form and never change. It's no different than working with post id's, etc. when dealing with WordPress post data. We'd like to make this more developer friendly in the future.

    Posted 13 years ago on Friday June 17, 2011 | Permalink
  3. Hi Carl,

    Thanks for the response, I understand what you are saying about the IDs, but I was saying post IDs are inherently bad to deal with, as the user has no way of changing the post id (or field id in this case). If a user does not add the fields in the exact order, then the data is no longer in the correct order. It's a lot easier to update an Admin Label (or Name field?) rather than telling a user they have to delete the form and start again.

    Of course, instead you could just expose the name field for the input, and auto populate it with the number, and have it editable under the advanced tab. People could the. Set it to whatever they wish

    Posted 13 years ago on Friday June 17, 2011 | Permalink
  4. I understand what you are saying, using the field id's makes it difficult to make reusable code that can be dropped into other sites because the field id's won't be the same.

    By the same token, using human readable id's of some sort would require the forms be setup using these same human readable id's, so it would still take some setup. So either way, if it's setting up a form to use specific field names or customizing the code to use specific field id's it still requires some sort of customization.

    But we could probably do something to enable targeting via the Field Label. It's something we do what to make more developer friendly in the future. Thanks for the suggestions!

    Posted 13 years ago on Friday June 17, 2011 | Permalink
  5. I'd like to second this request, please!

    (Thanks. The more I play with the product, the more I like it. But there a few times....)


    Posted 12 years ago on Sunday September 4, 2011 | Permalink
  6. I'm adding a vote here.
    If you work in a shop like mine -- and it seems the OP is facing the same problem -- we do everything in a Development environment, then run it through QA, and finally push to Production. The keys for the fields/forms need to stay the same or be given a human (read developer) friendly name.

    Posted 12 years ago on Monday September 19, 2011 | Permalink
  7. Glad to see a little love for this idea...

    Posted 12 years ago on Tuesday October 25, 2011 | Permalink
  8. Here's another vote for this!

    Posted 12 years ago on Friday December 23, 2011 | Permalink