Version 1.4.1 issues

Hi @ceenaree,

Thanks for your feedback.
In fact, the new version (1.4.1) should have similar behavior as the previous one (1.4.0) concerning automatic email sending. It only add the error notice in admin if something bad occurs while requesting a processing of your queued emails.
Moreover, it is not a “Development” version, you can safely pull it. WordPress always list a “Development” version in the Select of the downloadable previous versions.

This version was built to help people debugging errors when something bad occurs while automatic processing emails (through cron). It record the last error message encountered and notice it in admin. Note that the error could be dismissed but it may come back if the same error occur repeatedly.

Having this error message is interesting as it state that you are trying to send more e-mails than your cron can manage in one call. (It takes too much time)

A “cool” thing is that I have the same message as you on my installation. This is due to the fact that automatic e-mail sending goes through a wp_remote_get to your server using the default timeout of 5 seconds (which is really short).
If wp_remote_get timeout, your website could produce duplicate email sending as it may run a new queue processor while the previous one is still running.

I am going to create a new version (1.4.2) which may use WP_CRON_LOCK_TIMEOUT to compute a dynamic timeout to put on this wp_remote_get.
Don’t know if we should set somehing like WP_CRON_LOCK_TIMEOUT / 2, WP_CRON_LOCK_TIMEOUT - 5 or whatever.

Yours faithfully,
Birmania

Thanks @birmania

Currently version 1.4.0 is sending automatically and not falling behind on the queue but I agree that having the admin message is great to see if something went wrong as it has show us now. Looking forward to the new version to test it out.

Hi @ceenaree,

I just published v1.4.2 with the following features :

* Feature: Added capacity to store, list and purge sent mails
* Feature: Display basic informations about processing (max. time it take per run) to help adjust queue limit
* Feature: Mail lists are moved from “Tools” to a new tab called “Supervisors”
* Bugfix: Mails processing through wp-cron now use a timetout linked to wp-cron configuration (WP_CRON_LOCK_TIMEOUT / 2)

Feel free to test this new version and tell us if it solve your errors.
Note : You can now access the time it take for your app to send a batch of mail in the new Supervisor->Processing tab.

Yours faithfully,
Birmania

Hi @birmania,

Thanks for the update. There is no error message now and the new features are great. It also is helpful to have the max delay which is maxing at 16sec of me today.

One thing though, it is not automatically sending. I have to keep checking it and manually processing the queue in tools.

Hi @birmania,

I have noticed a conflict with this new SMTP mailing Queue version and BackWPup plugin. When your plugin is active the BackWPup job run fails with the “cURL error 28: Operation timed out after 5000 milliseconds” message when uploading the backup which was not happening before. If I deactivate your plugin the BackWPup job runs with no errors.

Hi @ceenaree,

Considering the missing automatic run :
After digging a bit, I found that WordPress may fail to requeue a scheduled task in wp-cron in really special context.
It already happened to me and I may consider adding a consistency check in the SMTP Mailing Queue Plugin to verify this point.

Can you please check the following :
1. Install (just for the check) the ‘WP Crontrol’ extension : https://fr.www.ads-software.com/plugins/wp-crontrol/
2. Go into ‘Tools>Cron Events’ admin menu
3. Check if ‘smq_start_queue’ is present in the list and that ‘Next Run’ is in the future
=> The fact is that mails are processed when ‘smq_start_queue’ is executed by wp-cron so if it is missing in this list, it is a bad news.

If ‘smq_start_queue’ is not present and ‘Don’t use wp-cron’ is unchecked in your ‘Advanced settings’, it means that the scheduled event failed to re-schedule.
A workaround to re-insert ‘smq_start_queue’ in the list is to save your ‘Advanced settings’, even without modifying anything.

Considering the BackWPup error :
Are you sure that it is caused by the new version of SMTP Mailing Queue ?
Because it seems that many users of BackWPup are currently experiencing the same issue as you. See : https://www.ads-software.com/support/topic/dropbox-upload-fails-with-curl-timeout-error/

What is “fun” is that they got the same error as us, using the default WP timeout of 5 seconds. Hope that they will find a way to solve this.

Yours faithfully,
Birmania

• This reply was modified 3 years, 5 months ago by Birmania.

Hi @birmania,

Thank you for the explanation. Before I received your email I was making small changes to Advanced Settings. I changed the queue limit to 8 and the wp_cron interval to 180 to see if the reduction would help. It did and the queue is going automatically. Could it be that the time interval was too long?

On the BackWPup I see what you mean and I had the same problem again today but I left on the SMTP Mailing Queue plugin and the manual backup worked. So yes seems the cURL error is spreading like THE virus ??

Right now things seem to be ok for the queue. Thanks for all the effort!

Hi @ceenaree,

According to this stackexchange post, it seems that periodic events can fail to reschedule when process take too long (more than WP CRON LOCK is allowed too).

You did well by updating values of your advanced settings. I just published a version 1.4.3 which will check ‘hourly’ if ‘smq_start_queue’ is still scheduled and will automatically reschedule if not found.

Moreover, I moved the processing error message from admin global dashboard to ‘Processing’ supervisor tab. It will be less intrusive and will still allow to debug errors.

Happy to listen that your BackWPup plugin is still working. Hope that they will solve their cURL timeout issue.

Thanks for your high-value feedbacks !
Yours faithfully,
Birmania

• This reply was modified 3 years, 4 months ago by Birmania.

Nevermind, you can directly update to v1.4.4.
The v1.4.3 is good but it was not registering the sanity check process on plugin update (only on activation).

V1.4.4 solve this point by enabling the sanity checks on plugin updates too.

Yours faithfully,
Birmania

Hi @birmania,

Thanks for the updates. Will see how it performs over the next few days with the advanced settings lowered as I have at the moment. If all goes well I will increase the settings closer to the original levels to see how it performs and handles the errors.

Thanks again for all the effort.

Cameron

I’m also getting the curl error in the original post.

SMTP Mailing Queue : Unable to call process queue due to following error ‘cURL error 28: Operation timed out after 5000 milliseconds with 0 bytes received’

I don’t know if the updates to the plugin fixed this and I need to dismiss the error. Knowing that you’re fixing the issue, I didn’t reply until now.

Below is the response I got from my host. I also wanted to ask if this was a problem on their end.

The cURL is supported and it is enabled. cURL version is?7.22.0 set on server.

In order to fix this issue, please contact the plugin vendor and ask them to allow one of the currently supported ciphers
DHE_RSA_AES_128_CBC_SHA1
DHE_RSA_AES_128_CBC_SHA256
DHE_RSA_CAMELLIA_128_CBC_SHA1
DHE_RSA_AES_256_CBC_SHA1
DHE_RSA_AES_256_CBC_SHA256
DHE_RSA_CAMELLIA_256_CBC_SHA1
DHE_RSA_3DES_EDE_CBC_SHA1
DHE_DSS_AES_128_CBC_SHA1
DHE_DSS_AES_128_CBC_SHA256
DHE_DSS_CAMELLIA_128_CBC_SHA1
DHE_DSS_AES_256_CBC_SHA1
DHE_DSS_AES_256_CBC_SHA256
DHE_DSS_CAMELLIA_256_CBC_SHA1
DHE_DSS_3DES_EDE_CBC_SHA1
DHE_DSS_ARCFOUR_SHA1
RSA_AES_128_CBC_SHA1
RSA_AES_128_CBC_SHA256
RSA_CAMELLIA_128_CBC_SHA1
RSA_AES_256_CBC_SHA1
RSA_AES_256_CBC_SHA256
RSA_CAMELLIA_256_CBC_SHA1
RSA_3DES_EDE_CBC_SHA1
RSA_ARCFOUR_SHA1
RSA_ARCFOUR_MD5

Hi @shawnrisk,

If you get this error there is high probability that you are currently using v1.4.1. Is it right ?
Event if it does not prevent your email from being sent, it is a bit annoying to have the error you mentioned regularly displayed in admin dashboard.

If you need to, you can upgrade to the latest version (1.4.4) which should solve your problem.

Concerning the response of your provider, it is sad to observe that they did not really answer your problem. You have a problem with request timeout and they forward you to SSL Handshake / PHP-cURL compatibility error which is not the case.

Do not hesitate to inform me if version update fixed your problem or not.

Yours faithfully,
Birmania

Thanks for the update.

I’m using version 1.4.4. What I don’t know if I’m suppose to dismiss the warning and see if this comes back or the warning will go away on its own.

Hi @shawnrisk,

I see clear now, you can dismiss the warning without any risks as it will not go away on its own. Moreover, it will not re-appear.

Yours faithfully,
Birmania