activecampaign

I’ve added a ticket to address the unnecessary Fonts request, but it may not be picked up right away. Thank you for the report.

Our latest release has improved clarity around the shortcode and attributes. 8.1.5

I’ve added a ticket to address the Fonts request, but it may not be picked up right away.

Sorry for the delay. There was a bug identified with the tracking ID retrieval process that was extremely intermittent.

In our latest release 8.1.5 we added an additional fallback check that should resolve this issue. Please let us know if it persists.

As of writing, we’ve released version 8.1.0 which should address this issue.

Hello!

Thank you for surfacing this, we’re looking to address it in our next release which should occur in the first week of November.

Hi Ken!

Can you let us know a little more about when and where this issue occurs? What user actions are performed when you notice the issue happening?

You can send our support team an email so it’s easier to share this information, and we can login to your WordPress install to examine things: help@activecampaign.com.

Let us know how we can help.

Thanks!

Hello! Sorry for the delay.

This plugin only handles embedding subscription forms and site tracking.

The only way to automatically send campaigns based on WordPress posts is via our RSS-type campaigns. If you send our support team an email on what isn’t working, they might have some suggestions on how to improve things, or other ideas on what you can do: help@activecampaign.com.

Thanks!

Hi Michael!

Sorry about this. It seems like a failure of your server accessing our API for some reason. I believe the plugin tries to get account info (using the account_view method) and fails, and therefore the account domain is missing, which is why that portion of the form JavaScript source is just missing.

Like you said, you can just hard-code the $instance["account"] value in the plugin, which resolves the issue. That can be done right around this code spot:

// get account details.
$account = $ac->api("account/view");
...
$instance["account"] = "myaccount.activehosted.com";

We will see if this is anything on our end that we can prevent.

Hello!

Can you please submit an official support ticket to us, so we can log-in to your WordPress install and take a closer look at these issues? You can email help@activecampaign.com.

Thanks! ??

Hello! Thank you for this feedback. We appreciate it. We will consider this for a future update of our plugin.

Let us know if we can help with anything else.

Hello! I tried visiting your site to see the issue, but I am getting a DNS error. Any chance you can email our help team so we can take a closer look? We may need to log-in to your WordPress install to find out what’s going on. My guess is even though the plugin was removed, the shortcode still resides in the page/post. The shortcode is just text, so that wouldn’t be automatically removed when uninstalling the plugin.

https://www.activecampaign.com/support/

Let us know if we can help!

Hi, sorry about this! Are you still experiencing this error? If so, get in touch with our support team so we can login to your WordPress install and take a closer look.

Thanks! ??

Hi Nate,

Thanks for letting us know. We will review your suggestion.

We also released an updated version of our plugin over the past weekend that should help avoid this issue going forward. The basic change was instead of trying to load the form using the ActiveCampaign custom domain (CNAME), we always use the .activehosted.com domain which has a valid certificate. So we can safely load that domain via HTTPS always, and the forms are generated fine.

Let us know of any other questions or concerns. ??

Hi Nate,

During my own tests, I don’t ever see that PHP error, so for that one you can submit a ticket so we can log-in to your WordPress install and take a look.

We are looking into ways to improve the SSL issue.

For now if your WordPress site uses SSL (on the public side where the forms are embedded) *and* you use an ActiveCampaign custom domain, you’ll need to setup SSL for your custom domain, otherwise your site won’t be able to load the form script (you’ll see a browser security warning about mixed content).

If your ActiveCampaign custom domain already has SSL support, then you can just make that line say $protocol = "https:" (or just comment that line out) so it tries to load the SSL version of the form script.

If your WordPress public side only uses HTTP, then forms should always load fine (no plugin changes needed).

Hope that helps! Let us know if not.

One more thing I forgot – after you reinstall the plugin, go into the ActiveCampaign settings in WordPress, and click “Update” again so it re-fetches the forms and caches them properly in the WP database. That might be the issue.