Is it possible to update a current user’s profile (using the “Update User” User Registration Feed) without creating an additional entry? Also, I would love to understand the logic behind creating a new entry (as I‘m sure I’m missing something). Please advise.
I had a use case where I needed to update custom post types and users information, but would not need the GF entry data after those entities were updated. I am using an add-on from Gravity Wiz to do this.
The add-on deletes the GF entry after all the feeds have been processed.
Yep, I use Gravity Wiz as well and that’s not a bad idea. I will investigate that option as well, however, I think some other things I’m doing require that there be at least one entry. But I will test this option to be sure.
@chrishajer was kind enough to provide a clear explanation on this issue and once I understood it, it makes perfect sense. I thought to share it here in case anyone else ever has this question.
Hi Preston. When using the User Registration Add-On, and a logged-in user visits a form you have tied to an Update User feed, you are not editing an existing entry. Submission will create a new entry in a new form, and the feed tied to the Update User action updates the logged-in user’s meta. At no time does Gravity Forms allow you to edit existing entries with any built-in functionality. So you’re never really editing entries. Logged-in users can update their WordPress user profile using our form and User Registration Add-On with an Update User feed.
As to why a new form must be used to update the user and an entry always created, I reached out to the original developer of the add-on, and I might not hear back today, but when I do, I will reply here and on your forum topic. Thank you.
Another very detailed breakdown, also with comments from the developer. Sharing it here in case anyone has the same questions. Thanks again, Chris!
Hi Preston, I heard back from the developer involved with the initial User Registration Add-On. The answer to the simpler question “Why is an entry created for the form tied to the Update User action?”. It’s only because that was the ‘least presumptive’ rule to follow. All form submissions create entries, and a form tied to an Update User feed is no different. So the entry is created by default, just like any other form submission. One positive benefit discussed was to be able to track changes to the users’ profiles, but not everyone needs or wants that.
If you wanted to prevent the entry from being created for the Update User form, you could use one of these methods (they all delete the entry after all the feed processing is complete, rather than prevent insertion into the database in the first place):
For the other question “why separate forms for Create and Update?” It was a simple decision that could have gone either way. At the time, the developers were concerned there would be confusion in the UI around which feed to use (create or update) for a single form. Conditional logic can’t be used for that because conditional logic is based on field values and they’re not known when the form is initially rendered.
That said, they could have pushed through any possible UI confusion and used the same form for Update and Create, but, the decision was made to go in this direction and that’s where we are today.
I’ve not used it so I can’t vouch for it, but they wanted a way to use two feeds with one form and apparently have come up with a way.
I hope that helps explain the historical reasons for where we are today and offers some workarounds for the issues.
If you think changing these things in the User Registration Add-On makes sense, I recommend adding a note for our product team here. Click the blue plus in the lower left on this page to add a note for our product team: