Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter ladytruckview

    (@ladytruckview)

    Hi Gui,

    Thank you for looking into this. The issue has actually been resolved, and it turned out not to be a plugin or theme conflict.

    The cause was a list-specific setting in MailPoet. In the settings for the subscriber list, the “Confirmation email” field was still pointing to the default confirmation email. After changing it to my custom visual confirmation email, the correct email started being sent immediately.

    So the global visual confirmation settings were correct, but the list-level confirmation email setting was overriding them.

    Thanks also for mentioning the CAPTCHA issue — I’ll check that separately.

    Thread Starter ladytruckview

    (@ladytruckview)

    I have done some additional troubleshooting and I was able to narrow the issue down further.

    First, I ruled out a theme/plugin conflict using WordPress Troubleshooting Mode. I tested with a default WordPress theme and only MailPoet enabled. The same default confirmation email was still sent.

    I then checked the MailPoet database configuration. The signup_confirmation setting contains:

    enabled = 1
    use_mailpoet_editor = 1
    transactional_email_id = 2

    Newsletter ID 2 exists in wp_mailpoet_newsletters, has the type confirmation_email, and contains my saved visual confirmation template.

    I also intercepted the HTTP request immediately before MailPoet submits the message to:

    https://bridge.mailpoet.com/api/v0/messages

    The outgoing payload already contains the default confirmation content:

    • “Hello there” — present
    • default “Click here to confirm your subscription” CTA — present
    • my visual confirmation content/subject — not present

    The MailPoet Sending Service successfully accepts the request with HTTP 201 Created, so the message is not being replaced by the Sending Service.

    This indicates that MailPoet is generating the default confirmation email locally before the message is submitted to the Sending Service, even though the database configuration correctly points to the visual confirmation email.

    MailPoet version: 5.35.1.

    Could you please advise what could cause MailPoet to bypass the configured confirmation_email / transactional_email_id during the confirmation email generation process?

    Thank you.

Viewing 2 replies - 1 through 2 (of 2 total)