Mailpoet repeating connection since last update

Hello,

Please try updating to MailPoet 3.6.2.
3.6.1 version has the issue where an incompletable scheduled task may cause high resource usage. The problem has been fixed in 3.6.2.

We have noticed that for some sites the 3.6.2 update is not offered for some reason, so you may have to perform the update manually, by downloading the update from the plugin repository and uploading it to your site.
We’re still looking into why the automatic update may not be offered.

Best regards,
MailPoet Team.

Hallo,

Thank you for your quick support.

I have downloaded the update MailPoet 3.6.2. Tried to install but I got the error report that the targetdirectory already exists /var/www/wp75004/1/hcat.nl/wp-content/plugins/mailpoet/

What should I do, I don’t want to remove MailPoet 3.6.1, because I am afraid that I lose everything. Unless you can guarantee I don’t lose my information.

Arnold

Hello Arnold,

Indeed, you should first delete the old version of MailPoet 3.6.1, then upload and activate the new version of MailPoet 3.6.2.
Otherwise, as you’ve seen, WordPress will not allow you to install the new plugin version and will instead return an error “Target directory already exists”.

Existing MailPoet data is retained on plugin deletion, so you should not lose any information.

Best regards,
MailPoet Team.

Thank You for your quick response.

Everything went okay!

Now a new error appears while I am planning a new mailing. I want to change the date, but nothing happens.

Error-report: Only tasks of type “sending” are accepted by this class

Arnold

@arnold60,

Great to hear the update went okay!
However, the error you are seeing is not something we have seen before.

Could you please get in touch directly with us via this form? https://www.mailpoet.com/support/wordpress-forums/
We would like to investigate your case in more detail.

Best regards,
MailPoet Team.

The 3.6.1 version caused excessive CPU usage on my SiteGround hosed site, causing my site to be shut-down for hours. Can you guys PLEASE include doing a test deployment and monitoring on a SiteGround hosted instance and verify that your application is behaving properly BEFORE pushing an update?

This cost people hours of time and frustration trying to determine the cause and mitigation.

@bslush,

We are sorry for the convenience. There are a couple of hosting providers, SiteGround included, that impose strict limits on CPU/RAM utilization. We are aware of that and hence recommend that users configure the “site visitor” option for the our task scheduler. Unfortunately the 3.6.0 release introduced a bug whereby this option wasn’t respected. This was fixed in 3.6.2. We are constantly improving our QA process but please understand that it’s very difficult to consider every possible site configuration and test against it.

Again, we work hard to ensure that we don’t introduce any breaking changes and when issues do arise, we are quick to resolve them (as evidenced by last week’s multiple releases).

Best regards,
MailPoet Team.

Thank you

MailPoet Team,

Assuming you are using agile best practices, one of the keys to success is test automation. You should be able to use a SiteGround Git repository to push your changes to SiteGround as part of your build/release process. You can then setup an automatic job to tell you if there are any CPU spikes (or other anomalies).

As for the multiple releases, that’s great (or possibly an indication of gaps in your QC processes) but unfortunately I was not informed so could not take proactive action. Maybe there’s a mail sending service you can find to send notifications?

I’m normally not snarky, but this has been quite painful and costly.