activecampaign

Hi Nate,

I tested this using my own WordPress install (with your AC account details), and I see our plugin properly using HTTP. Screenshot:

https://screen.ac/0q1v412e1733

So it still feels like your plugin is not on the latest version – can you confirm it’s plugin version 6.2?

https://screen.ac/3N1m2M3C2Q3O

Let us know if you are still stuck (we may need a support ticket submitted so we can log-in to your WordPress install).

Thanks!

Hi Nate- first, make sure you are using our latest plugin version (it’s best to delete it entirely and re-add it, so it obtains the latest bug fixes which are not always new versions).

If your WordPress site enforces SSL, then your AC CNAME will need to support SSL as well.

This plugin will automatically fallback to HTTP for custom AC URL’s, but you may get a mixed-content warning in the browser, so it’s best to make sure your certificate is valid and working for your custom AC domain.

Let us know if that still doesn’t help solve it.

Thanks!

Thanks for the suggestion! We are going to update that now.

Hi, I’m not sure that functionality is offered. Our plugin only allows embedding subscription forms and setting up site tracking.

Please let us know if we can answer any questions! ??

Hi, not easily. The forms are cached in the WordPress database (when you use the plugin) so it’s not easy to modify the source form HTML. You would have to copy/paste the form HTML from within ActiveCampaign to accomplish that.

Hi, sorry – we don’t currently integrate with ultimatemember.com. You might have to reach out to their developers to see if they can integrate with ActiveCampaign. Another idea is to use a tool like Zapier to sync data between apps.

Sorry – I forgot the wp_options.option_name value is serialized. Can you revert your change (or disconnect, then reconnect the ActiveCampaign plugin)? Then submit us a support ticket so we can actually log-in to your WordPress database to help further.

Thanks!

Hi, the code that produces the response is within our app, so it can only be changed after the API call is made (and the message received).

To customize the form HTML, you would have to modify the form HTML in the WordPress database. See the wp_options table WHERE option_name = 'settings_activecampaign'.

Hope that helps!

Hi, you would just use the [activecampaign form=1] shortcode anywhere in the widget body. Obviously change the “1” in my example to your actual form ID. ??

Hope that helps!

Hi, it’s in the API wrapper files:

activecampaign-api-php/Form.class.php

function process(...

// successful request
"message" => $contact_request->result_message,

// request failed
"message" => $contact_request->error,

Example of how you could change it:

// successful request
"message" => "My custom SUCCESS message here",

// request failed
"message" => "My custom ERROR message here",

Thanks! We’ll have this updated.

Hi Lisa – sorry, I don’t recall. Please email our help desk (help at activecampaign.com) so we can obtain your WordPress login details to check the issue out.

Thanks! ??

Item 2 will be fixed/improved. I have added either “form_result_success” or “form_result_error” class names to that div based on the Ajax response code.

Item 4: I don’t see an easy/quick way to improve this without having to build a new plugin feature that allows admin users to set custom response messages. For example, on success you could type in the value you want to have displayed. Same for error. As the messages are just generic responses from our API, they were not really meant to be displayed to a public user, but instead the developer using our API should read the response and display a custom message accordingly. We just haven’t built-out our WordPress plugin far enough to allow that yet. I love the idea and will add it to our development queue.

Regarding translations, I agree that needs to be improved also. The API responses (that are currently displayed) are translated based on the ActiveCampaign user settings (within ActiveCampaign). But I don’t see why we can’t translate the response (again?) within WordPress before displaying/returning it to the UI. Something we can test and consider.

Item 5: I see the error now after applying your code into my theme file: jQuery is not defined. We do, in fact, output the JavaScript when the form is embedded onto the page (it’s actually saved with the form HTML code when we cache it into the WordPress database). I am open to suggestions on how to improve this. My question: is this something common that users do in WordPress (moving jQuery to the footer with custom theme code)? Just wondering how many users would actually need a fix for this, or if it’s something that only power-users know how to do.

Hi, we have implemented fixes for your items 1 and 3 (which will be available within the next couple days). For item 2, we already provide a unique DOM ID for the Ajax message:

https://d226aj4ao1t61q.cloudfront.net/lkfixe4w_screenshot2015-06-17at10.13.51am.png

Is that enough for what you need to do?

For item 4, I am not sure how we would allow custom response messages. We hard-code “Contact added” and “Contact updated” in our API response (as well as any error messages). The only option I can think of is to update the plugin code to override this message.

Regarding item 5, I haven’t seen this error yet. Can you provide an example of what the error is, and how we can replicate it (I have a local install of WordPress). Then we can fix that also.

Thanks!

Hi, thanks for the feedback! We will review each and decide on implementing fixes or improvements.