https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments Gravity Support Forums Topic: Maintain IDs across environments en-US Thu, 16 Apr 2026 08:33:53 +0000 http://bbpress.org/?v=1.0.1 q https://legacy.forums.gravityhelp.com/search.php https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments#post-60526 Mon, 28 May 2012 09:39:33 +0000 David Peralty 60526@https://legacy.forums.gravityhelp.com/ <p>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. </p> https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments#post-60525 Mon, 28 May 2012 09:36:56 +0000 Steve.Taylor 60525@https://legacy.forums.gravityhelp.com/ <p>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? </p> https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments#post-60523 Mon, 28 May 2012 08:56:32 +0000 David Peralty 60523@https://legacy.forums.gravityhelp.com/ <p>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? </p> https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments#post-60522 Mon, 28 May 2012 08:53:40 +0000 Steve.Taylor 60522@https://legacy.forums.gravityhelp.com/ <blockquote><p>Gravity Forms doesn't currently have any feature that supports this</p></blockquote> <blockquote><p>This is beyond Gravity Forms currently to control this</p></blockquote> <p>Er... hence the "feature request"! ;-)</p> <p>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.</p> <p>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... </p> https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments#post-60520 Mon, 28 May 2012 08:44:36 +0000 David Peralty 60520@https://legacy.forums.gravityhelp.com/ <p>Again, I understand what you are trying to do, but Gravity Forms doesn't currently have any feature that supports this. </p> <p>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. </p> <p>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. </p> https://legacy.forums.gravityhelp.com/topic/maintain-ids-across-environments#post-60503 Mon, 28 May 2012 07:06:40 +0000 Steve.Taylor 60503@https://legacy.forums.gravityhelp.com/ <p>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.</p> <p>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.</p> <p>I <a href="http://www.gravityhelp.com/forums/topic/import-into-existing-form" rel="nofollow">enquired</a> 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.</p> <p>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.</p> <p>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.</p> <p>Is there any other way you could maintain consistent IDs across different environments? </p>