I have a project where there are already about 200+ users. These users were registered using WordPress’s native user registration process.
I have since, enabled the Gravity Forms User Registration Add-On as well as the GravityWiz’ Better User Activation perk. And it was good!
Now I have a need to display user profiles on the front-end as well as allow users to upgrade their own profiles. My solution to this was to use GravityView but here is where things ground to a halt: GravityView cannot see users that do NOT have entries in the user registration form.
What I need: I need a way to import my existing WP users as User Registration Entries while also NOT duplicating them in the system (or changing their passwords, if possible).
And then use Gravity View import entries plugin to import the CSV data. The gravity view import entries plugin allows you to use an existing form and you can trigger your update user feed for that form.
Since the users are already registered and Gravity Forms registers user to Wordpress, you should be able to update the users you already have without duplicating any of them.
Once the users have been updated, gravity view should be able to populate your merge tags in a view.
The only issue is perhaps the CSV file that is exported may need to be modified before importing. You should reach out to Gravity View directly to inquire about this.
Last night it dawned on me that I already had WP All Import Pro, so the one difference to your solution was that I used All Export Pro to handle the export.
Did that as well, imported directly into the Registration Form as entries, but I did not try to trigger the Update User" feed. Theoretically, that’s a dang good idea, and certainly worth a shot .
On it now. Will report back.
I did. They hit me with The Nuclear Option (and then recommended I not use it ).
You can use export your existing WordPress Users into a CSV file, delete them all from your WordPress and use our Import Entries plugin to import a CSV containing all your users’ information into a form that has a create user feed from the User Registration add-on, but that will re-add your WordPress Users from scratch and they will lose any references to existing content on your website if they already created anything (posts or pages). Also, their passwords will be reset. I honestly don’t recommend this approach unless really necessary.
I appreciated the warning, and no, we won’t be doing that.
Update: Queried GForms Support. Here is their response.
Gravity Forms doesn’t have a way to export users and importing entries is also not a feature.
It’s also important to note that there is no connection between a form entry and a user so updating the entry that created the user wouldn’t update the user and vice versa.
If you create a separate form with a user registration update type feed the mapped fields on that form will be populated with the logged in user details and will update the user with the submitted values.
So yeah, it looks like the best approach is to export, then import the users into “a form” which then triggers the “update user” feed. However, there are still a couple of dark spots in my understanding of this approach (esp. since i’m still relatively new to GravityView):
To my understanding, I need to use “User Registration” form to create a view for GravityView User Profiles.
If that is the case, the “User Registration” form only triggers the “Create User” feed.
Therefore, I would have to use the “Update User” form which (I’m assuming) would allow me to access those existing users for my User Profile View
So my question is, if I use the “Update User” approach and use these entries as the data source for my user profile view, how then do I merge both the updated (i.e. existing) users with any new users coming from User Registration entries?
If you are using Gravity View for user profiles you will want to use their “Join Condition” feature. This allows you to use separate forms that essentially contain the same data for one view.
If you’re concerned about potential issues you could always use a staging site to perform this task. Take a full backup including your database before importing your users CSV. That way you can always restore a backup or you can copy your production site to your staging site.
Depending on the # of users your current site has you could always turn this in a live environment and then restore the site if you needed to.
I exported all users and ran import entries with trigger feed (and authentication off)
That added all the existing users was “update entries”.
I enabled Gravity View’s multiple forms addon and then worked with the “Join Condition” feature, but quickly realized that this is only adding additional data to existing entries where fields match between both forms.
AFAIK, this does NOT allow me to merge entries from one form into another.
To make matters even more complex for you, you can always use Gravity Flow form connector extension to just update the user registration feed with the entry data of the update user form you recently created.
So basically after you import the data for the update user form, you can update the original user registration form with the form connector extension. You can add new fields to the user registration form as well and update those fields.
Then you would have access to all of the data inside the view without using Joins. If I am fully understanding your use case, the form connector extension should work. I would still give my other suggestion a go if you don’t already own a copy of Gravity Flow.
Because if someone registers and does not do an update, they won’t be in the view, or am I missing something.
Everything else in this post when straight over my head. Once again, I’m still pretty green using Gravity View, so keep that in mind. Once I put a bit more time into Gravity View the remaining options you present may become clearer to me.
But to me, it’s like overkill for what i’m trying. In other words, I feel like I should not need to use Gravity Flow to accomplish this task.
I actually had a developer license for Gravity Flow, but I’m letting it expire because -other than to play with- I did not use it in a single project for a full year. Great tool. I just didn’t need it, and the developer cost is hard to justify in that case.