dabernathy89

That’s odd – it should work without trouble. What is the error message?

Glad you got it working!

RE: your followup – I think that is a case where conditional logic makes sense. Another option could be to leave the ‘value’ for the radio field blank, but i’m not sure if that would have any unintended side effects.

(BTW you don’t have to insert the merge tags manually- there is a button to the right of the text area that will open up a dropdown for inserting them)

You should be able to get away with using one feed. For a radio or dropdown field, you can use a merge tag to insert the option the user chose. For checkboxes, if you choose the parent field (instead of an individual option), it will automatically give you a comma separated list.

For any of those fields, if you want to pass through the value instead of the label, you can change the merge tag like this:

{My Checkbox Field:1} —-> {My Checkbox Field:1:value}
{My Radio Field:2} —-> {My Radio Field:2:value}

See the GF documentation on merge tags: https://www.gravityhelp.com/documentation/article/merge-tags/

So in your case, the ‘tags’ box in the NationBuilder feed would look something like this:

{My Checkbox Field:1:value},{My Radio Field:2:value}

Which could end up getting passed to NationBuilder like this:

area-of-interest-1, area-of-interest-2,four-hours-to-give

So my best guess here is that you have some long field names that are causing this. I tested on my install with a really long field name and the dropdown did indeed overflow out of the box.

In the next update I can add some CSS to help prevent this. In the meantime, you can try just reducing your browser window size – at a certain breakpoint, WordPress’ mobile styling will be applied and the dropdown will no longer overflow (its parent <td> element is set to “display: block;”).

The only issue I can see is that your code is assuming that the number held in the custom field corresponds to the array index of the field inside the $form['fields'] array. I’m looking at this part:

$fields[$tiebreaker_next1]

It might be better to store the ID of the GF field in the ACF custom field. You would need to loop through the fields each time to check, but you could extract that to a function like get_gf_field_by_id( $id, $fields ) or something.

FYI this is completely normal behavior for credit card fields. The point of Stripe is that the CC data is not sent to the website’s server, so there is no way for the server to send back the CC data to fill out the form when there is a validation error.

Hey Phillip – what values are you using in the custom fields? It looks like they’re supposed to be indices from the $form[‘fields’] array, is that right?

Also – consider adding boolean ‘true’ as the 3rd parameter to the in_array() function, which will use strict comparison. Hard to say if it will help since i’m not 100% sure what the code is doing here.

Right now there is no way to do that, unfortunately. Hopefully being able to track ties is something I’ll be able to include soon.

I may be able to add a new merge tag to hold this data. The question is how this should be stored, though – should it be separated just by line breaks, or by “<br>” tags? Not sure what the best option is.

Additionally: if you’re using conditional logic for different confirmations, you would need to make sure all of your conditional logic checks that the new “ties” merge tag is empty.

Can you confirm you’re on the latest versions of everything:

GF 2.0.7
Quiz Addon 1.1.0
WordPress 4.6.*

I’ve tested that combo and everything is working correctly for me. If you are on the most recent versions and still running into issues, try disabling other plugins (particularly GF plugins) to see if that helps. You can also install the ‘Query Monitor’ plugin to see if there are any PHP errors.

– Daniel

Just pushed up an update – you will need to reactivate the plugin, as the update will force it to deactivate.

If the plugin is not working for you, it’s better to leave a comment in the support section than to leave a bad review.

It seems that between 2.0.6 and 2.0.6.4, the Rocket Genius folks pushed out a breaking change in the way that add-ons are registered (which should not happen in a patch release). I’ll push out a fix today to address it.

Hey, just now seeing this issue. I think the fix I just pushed up might solve the issue, but it could be unrelated. I will test it out.

Looks like I never saw this, sorry about that – glad you figured it out!