zaus

You’ll have to check with pardot, but I’m guessing the “Email” and “First Name” fields are actually the labels, and you’ll need to map to their ‘machine names’ instead.

Oh man I feel dumb. The clue was “Could not locate success clause within response” – that’s because everyone misunderstands what the ‘success clause’ setting means. It’s not a message my plugin shows to the user, it’s exact text the plugin looks for in the 3rdparty response, and if it doesn’t find it then it assumes something failed and causes the form to return the failure result everybody is seeing.

You only use that setting if you’re expecting the endpoint to return a response. If “nothing” means it succeeded you should leave it blank. I misinterpreted the question(s), thinking you were expecting the success clause to be there.

First, a point of etiquette: please don’t hijack support threads with another plugin, it confuses things.

Second, as I tell everyone asking for help, posting the contents of your debug email will really help us help you.

A minor point: you don’t need to (and probably shouldn’t) put endpoint-specific fields in your general-purpose contact form, unless you want them in the email or whatever else the form does normally. You add them (the hidden fields) to my plugin’s mapping as static values with the “is value” checkbox.

I suspect your problem is that one of the hidden fields isn’t mapped correctly; it’s usually the case that the endpoint is missing some required value which causes it to lose its mind. Sometimes they give useful error messages, and sometimes they just fall apart to discourage hacking around (which is kind of what my plugin does).

Maybe the 13344[748926] name isn’t mapping as expected? I could tell you more if you share the “user post” and “submission” sections of the debug mail.

Oh I get it. Same thing should apply, just populate it with the user profile from the page you’re on (wp should have some variable or function to get it). Or if you have control over the url, the easy way would be to have their user name in the query string (like ‘mysite.com/contact?agent=person1’) and then you can use my Dynamic Fields plugin with ##GET{agent}##, or any other form-plugin specific way to use a GET param.

Someone else had the same question ~2 years ago — https://wordpress.org/support/topic/map-to-civicrm-plugin

As they support an API (http://wiki.civicrm.org/confluence/display/CRMDOC/Using+the+API, specifically REST) it should work:

// For external services
http://www.example.com/sites/all/modules/civicrm/extern/rest.php
  ?api_key=t0ps3cr3t
  &key=an07h3rs3cr3t
  &json=1
  &debug=1
  &version=3
  &entity=Contact
  &action=get
  &first_name=Alice
  &last_name=Roberts

Try enabling wp_debug and checking log files, could tell you more.

There is a practical length limit, even though the backing field size is apparently 4GB, because the settings array gets serialized (which is pretty verbose).

See similar discussion: https://wordpress.org/support/topic/cant-save-a-new-service

That’s because that’s not how it works. The form plugin (cf7, gf, etc) posts to itself regularly, my plugin basically copies that submission and sends it to the endpoint you specify, server-side (not client-side). If you enable debug mode and put your email in the admin debug recipient field you’ll see what’s going on.