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.

Maintain IDs across environments

  1. Like many people, I develop locally on my desktop/laptop, then deploy to a staging server for testing, then deploy to the production server. My issue is to do with the IDs assigned to Gravity Forms, and the corresponding hooks using those IDs.

    Obviously on the first roll-out there is no issue. However, when new forms are subsequently added, since we only very rarely synch the data between environments, things can go awry. If the client has created miscellaneous forms on the staging or production servers, if I develop a new form locally, then export it to import into these environments, it may have a different ID from the local installation, and suddenly none of the hooked custom code works.

    I enquired about being able to import a form INTO an existing form, overwriting its field definitions. This would have helped me maintain IDs in my current situation - the form is new so losing entry data wasn't an issue. I was told this feature isn't present because of the issue of losing entry data, which has proved hard to address. This makes no sense because you can delete a form and lose data - and a simple confirmation is obviously sufficient to address this.

    Still, while an "overwrite form" function would be both simple to implement and useful in some circumstances, there would be other circumstances where this wouldn't help.

    The best workaround I can think of is to use the title as a kind of ID, although obviously you just need a client to decide a form needs a slightly different title and the form hooks break.

    Is there any other way you could maintain consistent IDs across different environments?

    Posted 11 years ago on Monday May 28, 2012 | Permalink
  2. David Peralty

    Again, I understand what you are trying to do, but Gravity Forms doesn't currently have any feature that supports this.

    As for maintaining consistent IDs across environments, as you noticed, it isn't Gravity Forms necessarily that is creating the mis-match, but the differences between your development and live environment. If you do something on the live environment (like create a new form), then of course the IDs aren't going to sync up any longer.

    This is beyond Gravity Forms currently to control this, though I'm sure someone with some experience could create an add-on to meet your needs.

    Posted 11 years ago on Monday May 28, 2012 | Permalink
  3. Gravity Forms doesn't currently have any feature that supports this

    This is beyond Gravity Forms currently to control this

    Er... hence the "feature request"! ;-)

    I understand perfectly that the reason for this issue is auto-increment primary key IDs. Only, these are working as they should, and apps and plugins (e.g. GF) should adapt around this.

    Currently I'm hacking it using "cssClass" as the unique cross-environment "ID". I think a simple solution would be to create an "ID" field for fields that is only editable by administrators. You might be able to come up with a better approach...

    Posted 11 years ago on Monday May 28, 2012 | Permalink
  4. David Peralty

    Sorry about that, I didn't notice it was in feature requests, I was on a support run today. :$ Can you give me a better idea on how you would like to see it implemented? On import of a Forms XML, would you be presented with the option to override another form? Would all the previously collected data be cleared if fields didn't match?

    Posted 11 years ago on Monday May 28, 2012 | Permalink
  5. If the issue was addressed by being able to override an existing form with an imported form, I guess you would have to wipe collected data. I don't know if there would be a way to see if the new form matches apart from some new fields, in which case perhaps the data could be kept. If this kind of check isn't possible, obviously you would need a confirmation before proceeding - and perhaps a bonus feature would be to include an export of the data for download before it's wiped?

    Posted 11 years ago on Monday May 28, 2012 | Permalink
  6. David Peralty

    Sounds about right. If you have any other thoughts or ideas on how you would like to see this implemented, that would be great. I'll pass this on to the developers.

    Posted 11 years ago on Monday May 28, 2012 | Permalink