Not working on secure pages

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!

This plugin will automatically fallback to HTTP for custom AC URL’s

That’s not happening for me. It’s omitting the protocol completely, which causes it to use https for the custom domain. This is the HTML the plugin outputs to the page:

<div class="_form_14"></div><script type="text/javascript" src="//hello.fireflypartners.com/f/embed.php?id=14&nostyles=1"></script>

I would be fine with a mixed-content warning. Right now the form just doesn’t show up at all. Thanks

Note: I deleted the plugin and uploaded the current version

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!

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.

Double checked that I do have version 6.2

One thing I noticed is that when I go to Settings > ActiveCampaign and click the Update button, I get this error:

Notice: Undefined offset: 14 in /*****/******/public_html/wp-content/plugins/activecampaign-subscription-forms/activecampaign.php on line 481

(I censored some stuff, but you get the idea)

Line 481 of activecampaign.php is where the protocol is set. And “14” is the form ID. So it has something to do with that.

Let me know if I should open a support ticket.

Thanks

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.

I was able to get this figured out. The problem was originally caused by the Simple SSL plugin. It deletes all instances of https:// from the wp_options table. I didn’t realize it did that.

I had to manually delete the settings_activecampaign row and reinstall the plugin.

You might want to consider adding a checkbox to this plugin that allows us to remove all ActiveCampaign data from our WordPress database upon plugin deactivation. I think this is best practice so your plugin doesn’t leave behind data when someone removes the plugin.

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. ??