Zach Skaggs

To be clear, I am NOT an active member of the Ninja Forms team…but you should be aware that in much of the world, the biggest holidays of the year are being celebrated, on top of the fact that there was a weekend involved. I’m sure the team will reply to you when they return to the office after spending much needed time resting and enjoying the holidays with their families. You continuing to berate and belittle the team publicly here over the holidays is a bit much…please be patient. Happy holidays to you and yours @sdagency.

Yes, I am sure that my SMTP setup is correct…every other plugin sends fine through it…it should hijack all wp_mail calls by default, except it’s own log does not show any attempts from MailPoet newletters.

When I configure MailPoet to use the Mandrill SMTP correctly instead of using the other SMTP plugin, it still does not actually send any emails. The logs in MailPoet say that mail was sent, but there are no logs showing the message in Mandrill. MailPoet is saying it’s sending messages, but nothing, in fact, is sending.

SMTP ports are not blocked on my server, as again, Mandrill works find to send these from every other WordPress plugin via wp_mail (served by my SMTP plugin).

The issue is not PHP mail. The issue is not SMTP ports blocked on my server. The issue is very specifically something in MailPoet not playing nicely.

I assumed since this is a support forum for Mailpoet, that would be clear.

It’s Mailpoet emails which are not sending. The effected plugin is Mailpoet. All other emails from all other plugins are working properly.

I listed the ways I have tried to configure MailPoet in my original comment.

• This reply was modified 4 years, 9 months ago by Zach Skaggs.

Unfortunately, this is being overridden by GMail. This is actually a good thing, as it stops the message from being marked as spam…but it can be frustrating. Many mail services do not honor changing the “FROM” address for spam-related reasons.

Please note that we only check these forums about once a week, so if you have any more questions and need assistance, please reach out to us at https://ninjaforms.com/contact/ for faster assistance!

.ninja-forms-req-symbol {
	color: green !important;
}

The rule above can help you change that color on your site. Please let us know via the link above if you need anything more!

Hey, @badcase! It sounds like you’re looking to set up your own integration, so you might be interested in our custom hook action. You can check it the documentation for it here: https://developer.ninjaforms.com/codex/custom-form-action/

This absolutely happened, and we were already making preparations on our end to make it right before this was posted.

I need to make one thing clear, and that is that we do NOT store ANY credit card information.

Our credit card processor, Stripe, stores a charge authorization. This authorization was not correctly revoked last year when you cancelled your subscription due to a bug in the e-commerce software used to run NinjaForms.com. For that, I am honestly, truly very sorry.

We should have double checked with the processor, and I take full responsibility for this mistake.

As mentioned, we were already making arrangements to make this right for you, and you will hear from us soon via our normal private support channels.

Absolutely! You can simply remove the “Save Submission” action that is added by default with your new form, and it will accomplish this goal!

Our devs have looked into this, and this cookie is not being created by Ninja Forms in the current version that we can find anywhere in our code. Can you provide more detail on where you are seeing this created so we can try to assist? Feel free to open an issue with more details here: https://git.saturdaydrive.io/ninja-forms/ninja-forms/issues

Can you submit a support ticket to our team at https://ninjaforms.com/contact/ so we can take a closer look? Ask them in your ticket to escalate the issue to Kenny.

Do you see this in the current 3.3.3 release? We found the issue, which was related to some old, inert code from a previous opt in system. It’s removed in the current release.

We’ve not been able to replicate this, but we’ve seen several reports of the behavior and we’re looking into it now. This certainly was not intentional…I’m sorry for the trouble.

Not yet but this is functionality that will be in the next release. For now any logged-in users will get their data in the export or delete request. There needs to be a few additional steps to get it working with any form submission email is there could be multiple emails per submission, etc.

If you had then you wouldn’t have this issue, but it’s still entirely our fault because we should have caught it to make sure it still works properly on older versions. That’s entirely my fault and again I’m very sorry.

It looks like this is a result of an out of date WordPress version plus an improper check on our end for some new functionality. I’m so sorry and take personal responsibility. Our team is on it now and will be updating ASAP.