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.

Member Directory

  1. erueschhoff

    I had purchased this plugin because I thought it would be a good way to create a member profile - by creating a form that they could complete all the necessary information to be displayed on the profile - granted it would not be tied to the user profile in the database it would allow for members information to be displayed to the network, would be easy to complete, and could be edited easy - BUT -- I have had a terrible time trying to get this plugin figured out -- I can't get forms to post and I'm not sure how to create the custom template. I have a custom template that has worked using tdo min forms - but I really don't care for the clunkiness of that plugin and would really like to figure out how to do this with gravity forms. Any suggestions?

    Posted 12 years ago on Saturday June 19, 2010 | Permalink
  2. I'm dealing with a similar situation. I used a gravity form to collect membership information for a business but couldn't figure out any easy way to then work with it. In the end, I've created a new plug-in with a script that imported all of the Gravity form info. and a gform_post_submission hook that adds new form submissions into my new membership system automatically. If something like that might help in your case, let me know and I can pass on what I've come up with.

    Posted 12 years ago on Sunday June 20, 2010 | Permalink
  3. Gravity Forms does not do user registrations or user account editing. So any integration between the two would have to be completely custom using API hooks. We do plan on introducing user registration capabilities in a future release, however it won't be until later this year.

    Posted 12 years ago on Monday June 21, 2010 | Permalink
  4. erueschhoff

    Carl - I am not asking it to integrate with my user registrations or user account editing. This is totally seperate. Registered users are given a link to complete the gravity form that will allow them to list their member information in a post that can then be displayed to the public. I was using this route to avoid all the non-sense with the wordpress user profile because it is just too difficult to work with and display.

    This is about getting the gravity forms plugin to allow forms to be published as posts as highlighted in the features. I'd really appreciate some support how to make this happen.

    Posted 12 years ago on Tuesday June 22, 2010 | Permalink
  5. erueschhoff

    Newport - I would love any help I could get on this. I think what you have done would work for me, but I still want to be able to understand how to use this plugin per the features highlighted - so that is why I also posted the reply to Carl. Thank you so much for your help!

    Posted 12 years ago on Tuesday June 22, 2010 | Permalink
  6. If you want Gravity Forms to create or publish a post you need to use the Post Fields in the Form Builder. Only Post Fields create post data. When you add a Post Title or Post Body field to your form it has additional options to set if the post is published automatically or set as a draft, if the author is set to the user submitting the form, etc.

    There are a variety of Post related fields. Post Title, Post Body, Post Tags, Post Category, Post Image as well as Custom Fields that create post custom fields.

    These are the only fields that will create post data, and a Post Title and Post Body have to exist on your form for a post to be created.

    What exactly are you having a problem with?

    Posted 12 years ago on Tuesday June 22, 2010 | Permalink
  7. I'm having the same issue as erueschhoff. I think that what we're both attempting to do is to pull the submitted form information from the database and display it within a page. Each page would show the details that the visitor submitted: Business Name, Telephone, etc. I don't want a new post for every entry, rather would prefer that I can query the database and display the fields I want.

    It's basically a public view of the Gravity Forms 'Entries' for a specific form.

    Posted 12 years ago on Wednesday June 23, 2010 | Permalink
  8. Current Gravity Forms doesn't have functions designed to show entry data on the front end. It is something we plan on adding in the future so it will do it sometime down the road.

    Until then you would have to roll up your sleeves and write the functionality yourself. The entries are stored in the database so you could reverse engineer the code used to display entries in the backend and copy-n-paste it to create custom code to display entries on the front end. It would be a customization.

    Posted 12 years ago on Wednesday June 23, 2010 | Permalink
  9. Can you offer any further insight such as what database table(s) to look in? I'm good with PHP, and learning SQL, so any info/tutorials/resources, etc. will be very helpful.

    Posted 12 years ago on Wednesday June 23, 2010 | Permalink
  10. The best place to start would be to examine the entry_list.php and entry_detail.php files within the plugin. This is where the entry display code resides. There is an entries table where the entries are stored. However you will need to look at the entry related PHP files to see how to parse the data and display it.

    Posted 12 years ago on Wednesday June 23, 2010 | Permalink
  11. You guys are looking to do exactly what I just did. Here's the quick rundown.

    Gravity Forms stores form entries as field number = field value. Each entry also includes the form number. There isn't an easy way to work with that unless you make a chart of your field numbers and what they represent. As in, field 5 = email address; field 6 = work phone number; etc. When you have that, you can simply query the Gravity Form table to display your info. on the front end using INNER JOINs. But that does get pretty tedious.

    What I did was make a plugin that sets up some new tables -- members, member_meta, etc -- and then uses the post_submission hook to call up a function that adds members to those tables. Then I can easily work with them. So right now I have a table with the standard gravity forms entries and completely separate tables that have the same info. as the forms (initially, anyhow) which are what I then work with.

    If you want to just do simple lists of info. from your forms, a great work around is to install the Shortcode Exec PHP plugin. That lets you create a short code from the backend and stick whatever code you want as the shortcode's action. So if you want to get a list of names and email addresses from a form, you can use the plugin to make a new short code. In the dashboard you just the text you want to use for the shortcode, like 'my-list' and below that you get a WYSIWYG box where you can enter the php code to display the list. As an example: If you have a form whose ID is 1 and two fields you want to display, a name field with ids 3.3 for first name and 3.6 for last name, and an email address field with id 5, then you could paste the following.

    global $wpdb;
    $results = $wpdb->get_results("SELECT, f1.value as first_name, f2.value as last_name, f3.value as email FROM ".$wpdb->prefix."rg_lead as f INNER JOIN ".$wpdb->prefix."rg_lead_detail  as f1 ON ( = f1.lead_id AND f1.field_number = '3.3') INNER JOIN ".$wpdb->prefix."rg_lead_detail  as f2 ON ( = f2.lead_id AND f2.field_number = '3.6') INNER JOIN ".$wpdb->prefix."rg_lead_detail  as f3 ON ( = f3.lead_id AND f3.field_number = '5') WHERE f.form_id = '1');
    foreach ($results as $result){
    echo "Name: ".$result['first_name']." ".$result['last_name']."";
    echo "Email: ".$result['email']."------------";

    Then you can use your new shortcode [my-list] in your pages and posts.

    For each form field you want to display, just do another INNER JOIN. At the start of the sql statement you're listing all of the fields you want returned and using aliases so that you can easily access them. So if you had another field, age, you could add f4.value as age and then another INNER JOIN ".$wpdb->prefix."rg_lead_detail as f4 ON ( = f4.lead_id AND f4.field_number = '6') -- making sure to change the field_number to whatever corresponds to your age field.

    Posted 12 years ago on Wednesday June 23, 2010 | Permalink
  12. Continuing the last post, if you want to streamline your SQL query, you can also use a RIGHT JOIN to simply return all of the field_ids and field_values that match each lead_id. That would give you results like:

    lead_id = 1 field_id = 3.3 field_value = Bill
    lead_id = 1 field_id = 3.6 field_value = Smith

    To work with that, you can turn those into an array setting the array key as the field_id and the value as the field_value and then you can access all returned info. via the field_id -- but again, you have to know the field_ids. If all of your fields have unique names (set under the advanced tab when you create the field, choose Allow field to be populated dynamically and then enter the name you want to use where it says Parameter Name) then you can do so more complex stuff to get the field names from the Gravity Forms form table but that involves unserializing the form data and some more complicated loops.

    Carl -- or anyone else at Gravity Forms -- your plug-in has a ton of cool features. The documentation is non-existent -- seriously, I have read every single post in this forum to figure out as much as I have about it. Your API hooks page has zippo info. on how to use them, just three examples which is far from all that's available and no help explaining how to implement them properly. Everytime someone asks about some basic documentation you guys post back that you're working on it. For more than half a year. What is the major hold up with sitting down for one afternoon and typing up some basic stuff? Prompt Forum support is nice, having your customers not need to endlessly post to the Forums would be much nicer.

    I would also suggest that intead of constantly replying "We're working on it for a future release" with no info. on how soon to expect that release is also of little help. If you're going to release an update that addresses a need someone has now, they might be able to wait or they may need to find an alternative. How about publishing some timelines -- basic project management stuff to show what's currently in the works and when you expect to release.

    Finally, if you want to solve the near constant conflicts that Gravity Forms has with other plug-ins, try releasing beta candidates to at least a handful of programmers so you can get feedback before you put them out there in wide release. Maybe you do that now, but if so, clearly not to a broad enough audience.

    Sorry to write such a snippy post, but I've frankly gotten to the point where I don't want to use this plug-in for future projects b/c I spend more time debugging it than I would have just building the forms.

    Posted 12 years ago on Wednesday June 23, 2010 | Permalink
  13. First, we are already aware that the API documentation is non-existant. We are a very small team (3 people to be exact) so until we are done working on what we are currently developing, the API documentation is going to lag behind. Most of the API hooks that have been added have been user requests that we went ahead and added, which is why only a few of them are documented. Once we are done with our current development cycle we plan on improving the API documentation

    The vast majority of our customers never have to post in the forums. Those active on the forums are a small fraction of our customer base, most of them aren't endlessly needing help as you put it.

    Second, we don't develop our product based on your needs. We develop the products based on OUR needs and that of the overall customer base. Every request isn't going to make it into the product. We don't give timelines because as soon as we give a timeline and for whatever reason we don't meet that timeline users are going to have an issue. I apologize if that isn't how you do development, but we do things on our timeline... it's a product and not custom client work.

    Third, we don't have constant conflicts with Gravity Forms. Most of the conflicts that occur are the same conflicts over and over again from plugin or theme authors that don't really know what they are doing. In fact we rarely have to change any code within Gravity Forms itself to resolve a conflict because it is usually always an issue with someone elses code.

    We can't prevent plugin conflicts because we have no control over other peoples code. There are 10,000+ plugins in the repository alone and countless others not in the repository. Beta testing, which we do, only goes so far. As I mentioned we rarely have to change code in Gravity Forms to resolve a conflict because it is usually always an issue with code unrelated to Gravity Forms that is causing the problem.

    Posted 12 years ago on Thursday June 24, 2010 | Permalink
  14. Touchy touchy! I'm a small shop too, I know what it's like. But still, no reason not to jot down notes on any API hooks you whip up for clients and stick at least those as posts in a sub-category of the forums. You might just find you start getting some useful code back from clients who have needed to do some customization / extension themselves that could save you guys some effort.

    Posted 12 years ago on Friday June 25, 2010 | Permalink
  15. Believe me if we had the bandwidth to whip up the API documentation right now we would. It's on our list of things we plan on doing, however we only have so many hours in the day to accomplish what we want to do.

    We do plan on expanding the API documentation, however the person best suited for this task (unlike user facing documentation) is our lead programmer... so until we can take a break from our current development cycle the API documentation is on the back burner.

    Posted 12 years ago on Friday June 25, 2010 | Permalink
  16. Solitude

    Hee Hee

    Posted 12 years ago on Friday June 25, 2010 | Permalink
  17. gverhoff

    I'm trying to implement Newport's SQL solution above to pull out some form data and display it on a page using Shortcode EXEC PHP. I keep getting an error that says I need to use return instead of echo. I changed the echos to returns, but I still get the error. Here's my code:

    global $wpdb;
    $results = $wpdb->get_results("SELECT, f1.value as first_name, f2.value as last_name, f3.value as city, f4.value as state, FROM ".$wpdb->wp."rg_lead as f INNER JOIN ".$wpdb->wp."rg_lead_detail  as f1 ON ( = f1.lead_id AND f1.field_number = '1') INNER JOIN ".$wpdb->wp."rg_lead_detail  as f2 ON ( = f2.lead_id AND f2.field_number = '2') INNER JOIN ".$wpdb->wp."rg_lead_detail  as f3 ON ( = f3.lead_id AND f3.field_number = '3') INNER JOIN ".$wpdb->wp."rg_lead_detail  as f4 ON ( = f4.lead_id AND f4.field_number = '4') WHERE f.form_id = '4');
    foreach ($results as $result){
    return .$result['first_name']." ".$result['last_name']."";
    return .$result['city']." ".$result['state']."------------";

    Any ideas on how to fix this issue?

    Thanks in advance,

    Posted 11 years ago on Monday July 5, 2010 | Permalink