Gravity Support Forums Topic: Member Directory

Gravity Support Forums Topic: Member Directory https://legacy.forums.gravityhelp.com/topic/member-directory Gravity Support Forums Topic: Member Directory en-US Sun, 19 Apr 2026 23:25:30 +0000 http://bbpress.org/?v=1.0.1 <![CDATA[Search]]> q https://legacy.forums.gravityhelp.com/search.php gverhoff on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-7000 Mon, 05 Jul 2010 11:55:38 +0000 gverhoff 7000@https://legacy.forums.gravityhelp.com/ 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: <pre><code>global $wpdb; $results = $wpdb->get_results("SELECT f.id, 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 (f.id = f1.lead_id AND f1.field_number = '1') INNER JOIN ".$wpdb->wp."rg_lead_detail as f2 ON (f.id = f2.lead_id AND f2.field_number = '2') INNER JOIN ".$wpdb->wp."rg_lead_detail as f3 ON (f.id = f3.lead_id AND f3.field_number = '3') INNER JOIN ".$wpdb->wp."rg_lead_detail as f4 ON (f.id = 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']."------------"; }</code></pre> Any ideas on how to fix this issue? Thanks in advance, -Gary Solitude on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6664 Fri, 25 Jun 2010 07:19:30 +0000 Solitude 6664@https://legacy.forums.gravityhelp.com/ Hee Hee Carl Hancock on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6663 Thu, 24 Jun 2010 23:54:26 +0000 Carl Hancock 6663@https://legacy.forums.gravityhelp.com/ 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. wunderdojo on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6659 Thu, 24 Jun 2010 22:54:35 +0000 wunderdojo 6659@https://legacy.forums.gravityhelp.com/ 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. Carl Hancock on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6622 Wed, 23 Jun 2010 22:20:06 +0000 Carl Hancock 6622@https://legacy.forums.gravityhelp.com/ 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 WordPress.org 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. wunderdojo on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6618 Wed, 23 Jun 2010 17:30:33 +0000 wunderdojo 6618@https://legacy.forums.gravityhelp.com/ 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. wunderdojo on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6617 Wed, 23 Jun 2010 17:14:50 +0000 wunderdojo 6617@https://legacy.forums.gravityhelp.com/ 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. <pre><code>global $wpdb; $results = $wpdb->get_results("SELECT f.id, 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 (f.id = f1.lead_id AND f1.field_number = '3.3') INNER JOIN ".$wpdb->prefix."rg_lead_detail as f2 ON (f.id = f2.lead_id AND f2.field_number = '3.6') INNER JOIN ".$wpdb->prefix."rg_lead_detail as f3 ON (f.id = 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']."------------"; }</code></pre> 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 (f.id = f4.lead_id AND f4.field_number = '6') -- making sure to change the field_number to whatever corresponds to your age field. Carl Hancock on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6612 Wed, 23 Jun 2010 15:40:42 +0000 Carl Hancock 6612@https://legacy.forums.gravityhelp.com/ 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. manifestcreative on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6610 Wed, 23 Jun 2010 15:30:14 +0000 manifestcreative 6610@https://legacy.forums.gravityhelp.com/ 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. Carl Hancock on "Member Directory" https://legacy.forums.gravityhelp.com/topic/member-directory#post-6605 Wed, 23 Jun 2010 15:02:06 +0000 Carl Hancock 6605@https://legacy.forums.gravityhelp.com/ 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.