pixelbrad

Manual database upgrade works now. Thank you for addressing the issue in a timely manner.

Thanks. I’ll run plugin updates on the site later today or possibly tomorrow. I’ll update you here afterwards.

@qodeinteractive The site was using Elementor 3.4.0 before updating to 3.4.2.

Looking further into this, it appears once a minute (the schedule for cron event emp_cron_emails_process_queue), the site attempts to send the same event reminder email. It seems like every time the cron even runs, 100 (the default) attempts are made to send the email.

Looking at the EM_EMAIL_QUEUE_TABLE mail queue table (wp_em_mail_queue), there is only one email in the queue, and it’s the same one the site keeps trying to send. Not sure how to clear this out other than manually deleting the row.

—

Okay, I’ve spent some more time looking into this and I’ve figured out what’s happening and why.

1. Postmark is responsible for sending emails generated by the website, including emails Events Manager tries to send out.
2. When Postmark attempts to send the event reminder to the person still in EM’s email queue, Postmark’s API returns an error.
3. Postmark’s wp_mail function returns false if the response is either a WP_Error object or if the API response code is not 200. In attempts to send the event reminder to this person, Postmark’s API is giving us a response code of 401, so wp_mail is returning false.
4. EM’s EM_Mailer class (events-manager/classes/em-mailer.php) is checking if $send (the result of calling wp_mail) is true or false (line 58). If false, EM is attempting to append $phpmailer->ErrorInfo to $this->errors[] (line 60).
5. Since the site is not using php mail, the variable $phpmailer is presumably empty, thus, attempting to access object property ErrorInfo fails. That explains the notice.
6. We’ve actually configured EM on this site to use WP Mail, not PHP mail function (WP Admin > Events Manager > Settings > Email tab > Email settings > Mail sending method option). So why EM_Mailer class is assuming we’re using phpmailer seems like an oversight. To the best of my knowledge, we’ve always had EM configured to use WP Mail (i.e. we didn’t recently change this setting).
7. EM_Mailer’s send function returns the same value as $send, which returns the same value as wp_mail, which in our case is false (explained in point 4 above).
8. Events Manager Pro’s process_queue function (events-manager-pro/addons/emails/emails.php, line 155) checks the result of EM_Mailer->send on line 185 to dictate whether or not the database row (i.e. the item in the queue) can be deleted. Because EM_Mailer->send returns false, the item is never removed from the queue.
9. Because the row never gets deleted, process_queue loops over and over the queue trying to send the email. The default limit of queued items processed per cron event is 100, and I don’t see where I can change that, so I assume 100 is the limit in our case. process_queue loops over the same email up to 100 times every minute, because the email is failing to send out, and EM is failing to remove the email from the queue.

So that explains why Postmark has logged 1.15 million attempts to send that email to this date, and why we’re seeing so many PHP Notices logged.

What’s not clear to me is how I’m supposed to clear this queue item (without manually logging in and deleting it), or why this queue item is not being purged after so long. The event has long since passed – the event reminder is useless at this point.

I am going to delete this item from the queue manually, just to put a stop to this nonsense.

Hello,

I’m working on the same site as @kisabelle.

We’re still seeing this notice logged, dozens of times per page load. I’m not really sure where it’s coming from, what’s happening that is causing the notice to be logged, or how to stop it.

We’ve been having an issue where the same email, an event reminder from this Events Manager plugin, is attempting to send out non-stop to one person. It started mid-June, and since then, Postmark has logged 1.15 MILLION attempts to send the same email to the same person. We’re wracking our brains trying to figure out how to stop this.

If it makes any difference, Postmark implements its own wp_mail function, which ultimately sends the email data to Postmark’s API endpoint. On every attempt to send this specific email, Postmark returns an error:

{"ErrorCode":406,"Message":"You tried to send to a recipient that has been marked as inactive.\nFound inactive addresses: REDACTED.\nInactive recipients are ones that have generated a hard bounce, a spam complaint, or a manual suppression. "}

Please help us with this.

Thanks,
Brad

It sounds like the download finishes, but you can’t open the file you’ve downloaded. AI1WM creates exports in a sort of proprietary file format, *.wpress. You can’t open it like you could a zip file. Unfortunately, that’s just the way it is with this plugin. But for moving sites from one place to another, this plugin excels at that.

So if you’re trying to move a site from one place to another, here’s what you would do:

1. Create and download a backup archive on the source site (the site you want to move).
2. Spin up a fresh WordPress installation on your localhost (or wherever you want to move the site to). This means downloading WordPress core, jumping through the hoops of connecting it to the database, etc.
3. Install the All-in-One WP Migration in that new WordPress site.
4. Head into AI1WM’s import page and import the backup file you downloaded (the *.wpress file).
5. You’ll be prompted to overwrite the files and the database. Proceed, and make sure the import tab/window stays open until the process finishes.
6. Once it finishes, reload the page.

The plugin works completely fine on my end, and is actually my preferred plugin for moving sites around. What kind of issues are you experiencing?

This is not an issue with AI1WM. You can check with your hosting provider to increase maximum upload size, or you can figure it out yourself.

I understand this is resolved, but wanted to chime in with my two cents anyway.

I have been using MainWP Child for 6+ months on my client’s website. They have a fairly busy ecommerce website with plenty of public and admin traffic.

I was just pulling my hair out about during a database migration because the wp_options table kept failing to import. I traced it down to a single row. The problematic row had an option_name of mainwp_child_subpages and a value over 120 million characters in length.

After browsing through MainWP Child’s code, it seems this option is unused in the current version. Excluding this row from my import allowed the import to proceed unhindered.

Not too sure what this would have been used for, or how it grew to such a size, but my oh my did this ever give me a headache.

• This reply was modified 4 years, 7 months ago by pixelbrad.
• This reply was modified 4 years, 7 months ago by pixelbrad.

Wonderful, thank you!

Bumping this.

I’m experiencing issues stemming from this plugin’s loading of the AWS SDK as well.

One of the sites I work on uses this plugin, and uses a backup plugin called BackupBuddy. BackupBuddy can send backups to remote destinations, such as AWS S3. While C3 is active, interacting with an S3 remote destination in any way fails (sending a backup to a remote destination, trying to view the contents of a remote destination, etc.).

Hi Bogdan,

I made a mistake. I was very confident in my assumption that my web server’s error display was turned off by default, but that proved to not be the case. The update to MainWP Child simply stopped setting display_errors to false, as the changelog indicates.

My fix was to explicitly set display_errors to off in my web server’s PHP configuration.

Thank you for taking the time to test on your test sites. I’ll mark this as resolved.

Hey Josh,

I’m not sure which network panel you’re referring to.

It certainly seems that way..

Great, so document as such in the changelog ??