In this guide, we’ll explain how to use the password generator HTTP POST, and also fix any issues that you face with it.
Below, we’ll show you the ideal campaign setup, and if your campaign is set up in a similar way, follow this guide to see if you’re facing a common issue we see. 90% of the issues we see can be resolved by going through this document. If you’re one of the 10%, don’t hesitate to contact us so we can get you back up and running.
An ideal HTTP POST campaign sequence
Ideally, we suggest users to first apply any access tags, then run the HTTP POST, add a delay timer of 1 minute, and then send a welcome email in that order.
Here’s how it should be setup:
Here’s what’s inside of the HTTP POST. You don’t need to make any changes to “Name / Value Pairs” fields. Infusionsoft sets these by default and they should be left alone for the POST to work with Memberium correctly. Changing those value pairs will cause problems with the POST.
This sequence is ideal because it will first apply the tag to your contact, then it will generate the password, and the delay timer would ensure that the HTTP POST has enough time to generate the password and then send the Welcome email.
If you’re following these instructions but you’re still facing a problem with password generation, then continue reading this article.
Does the user exist in WordPress?
This is the first and very important check. Memberium’s HTTP POST will not generate a password if the user already exists in WordPress OR if the user already has a password in Infusionsoft.
For example, if you’re trying to generate a password for email@example.com, and if the same user exists in WordPress (with the same email address) then Memberium won’t generate a password for the user.
Are emails being sent with blank passwords?
One reason for emails being sent with a blank password can be because you’re not using a 1-minute delay timer in your sequence after the HTTP post.
Try placing a 1-minute delay timer after the HTTP POST and before sending the welcome email to give the HTTP POST time to process the password update before the email is sent.
This HTTP POST also includes two optional parameters that will allow you to apply a tag, or achieve a goal on successful password generation. If you want to be double sure before sending the email, then you can use the tag in the HTTP POST, and use this tag as a goal to start a sequence which will send the email. This ensures the email is only sent after the POST has been run.
HTTP or HTTPS?
Have you recently started using HTTPS on your site? If so, then you’ll need to change your Password generator HTTP POST to start with HTTPS. Example:
Notice that it starts with HTTPS instead of HTTP.
If you’re already on HTTPS and still facing the problem, then the problem can be that Infusionsoft isn’t compatible with your SSL certificate. In this case, what you can do is to try to have one page on your site which doesn’t force SSL and use that page to do the password generation. Although this can be a problem, we rarely see this particular issue. Normally, the issue is that the site is HTTPS and then POST is using HTTP without the S.
Is your Homepage protected?
In some cases, the homepage of the website is protected which can be a problem. Our default Password generator example uses homepage, but what you can do is to use some other page also as your HTTP post.
Example, let’s say the default HTTP post is: https://yourdomain.com/?operation=makepass&auth_key=P2LwRGinl but since your homepage is protected, this won’t generate the password. You’d need to use a non-protected page for this, which can be your Login page such as https://yourdomain.com/login/?operation=makepass&auth_key=P2LwRGinl (notice the /login/ part in the URL).
If you’re using a CDN like Cloudflare, then sometimes it can also block the HTTP post.
Memberium will also by default display a notification when you start using Cloudflare and you’d need to make a few changes on your site for configuring Memberium with Cloudflare.
Is Memberium running on the frontend?
You can check if Memberium is running on frontend by checking the page source of the homepage of your site. Go to the homepage of the site
Here’s a screenshot of what you’re looking for:
If you’re unable to view this, then it means that Memberium is not running on the frontend and one reason for this is that IonCube loader is not installed or misconfigured.
In some cases, Memberium support might be able to help you fix this issue or you can also try contacting your host who’ll help you in installing IonCube.
Using a security plugin?
Sometimes security plugins can also block the HTTP POST. We’ve noticed this with plugins like iThemes Security, BulletProof Security, Sucuri, Wordfence, and WP Spam Shield.
Please refer to this article on what to whitelist.
Using a Firewall?
Some hosts have configured their Firewall or filter such that it will block HTTP POSTs. In this case, you’d need to contact your Web host and ask them to allow the HTTP POST.
For example, if you’re using WPEngine, then you will need to contact WP Engine support and request that they turn off the “redirect_bots” setting, and purge the cache. Here’s our article on how to configure WP Engine to run Memberium.
Other Issues/Still Stuck?
Sometimes it can be tricky to figure out the exact issue with HTTP POST. If you’ve followed this documentation but are still facing a problem with HTTP POST, then feel free to contact Memberium support team.