If you want and can, deactivate the smtp post plugin and install GD mail queue. Enable the option to process ALL email and tune the queue to send every 5 minutes in batches. Also put 20 seconds as max time per batch.
That will introduce some delay in your email sending, from 2-3 to 5 minutes for each batch. BUT you will be able to see if email sending is your problem.
I use GD mail queue because my hosting provider has a smtp out emails per hour (100). Works great.
Hi Anonymous20,
Thank you so much for your advice ! I installed GD mail queue in place of POST SMTP, and it works again, without 504 error !
There is just one problem remaining : it seems that when you click on "ADD REPLY" to publish a new message, the plugin takes the time to prepare the list of subscribed users (by checking the Wpforo Subscribes table, I suppose) to send the notification emails, BEFORE it gives back hand and publish the message.
And when you have many subscribers as we have, it takes a VERY LONG time (around 90 seconds), so the publisher can be confused and think that his contribution has failed.
And generally, if he has the (bad) idea to refresh the page, it generates a duplicate of the message.
Dear developers of Wpforo, would it be possible to change this?
I mean, would it be possible to validate the new message BEFORE seeing after the susbscribers list?
I don't think GD mail queue knows where to search wpForo subscribers. Those are stored in custom table. Are you sure this plugin is compatible with wpForo?
wpForo doesn't check subscribers before submitting a post. it starts check and send emails once the post is submitted.
In any case, it's a good idea to separate the notification sending process from the post submitting process. But this is a large work and can't be added quickly.
He is not talking about GD mail queue, i think he is talking about wpForo.
As for GD mail queue, works just fine with wpForo.
Hi Robert,
As far as I know, the only job of GD Mail queue is to intercept emails to be sent with PHP mail and queue them.
I don't see why it could be incompatible with Wpforo.
The fact is that it's a solution that solved my "504 error" problem, an this is the most important.
I'm glad to read that Wpforo checks susbscribers after submitting the post, ... but in this case, how do you explain that with a private forum with only 17 susbscriptions the submitting duration is a few seconds, whereas with our open forum (several hundreds of subscribers), this duration is about 90 seconds?
Ok, I mean the plugin doesn't make post submitting slow. It can't collect wpForo subscribers. The duration is long because of number of sent emails. This is the explanation. So, all is correct, it may take 90 sec in hundreds of email case.
I'm glad to read that Wpforo checks susbscribers after submitting the post, ... but in this case, how do you explain that with a private forum with only 17 susbscriptions the submitting duration is a few seconds, whereas with our open forum (several hundreds of subscribers), this duration is about 90 seconds?
Again, do not guess, use the debuger to see what exactly is taking your php and db time.
And 17 emails (as you say above) should NOT take a few seconds but be almost immediate. 17 emails is nothing actually.
Yes it should not take a long time, if it takes a long time then this is an email server issue, or it maybe some email plugin compatibility issue. It doesn't have any relation to wpForo core functions and processes.
Yes it should not take a long time, if it takes a long time then this is an email server issue, or it maybe some email plugin compatibility issue. It doesn't have any relation to wpForo core functions and processes.
Robert, we are all confused i think.
The 90 seconds delay the OP is talking is about what happens IN wpForo. What happens AFTER the emails are queued is an other story.
If the email queue (from GD mail for example) takes 2 hours to be send, it is NOT what he is talking about.
He is talking about 90 seconds delay when he presses Submit.
Also it is a good idea to enable WP debug and check the debug.log. Maybe something else is the cause. You have no idea what a debug.log can hide ....
😎
You've perfectly understood my problem, Anonymous20 !
I will follow your advice and install Query monitor to find out...
When you submit the post wpForo calls wp_mail() function for all subscribers, there is no any delay in wpForo core, the whole delay come from wp_mail(). So when you click on submit button you have to wait wp_mail() function. Submitted form and the page cannot be refreshed until all emails are not sent via wp_mail() function. This is the 90 sec delay point.
wp_mail() delay based on hosting email server and on other plugins which hook this function and do something with email sending processes.
The problem fixing points is one:
1. Don't call wp_mail() function for all subscribers when post is submitted. Call it partial using cron-job or some other solution.
If you could find other solutions please post it here.
Thank you!
For how many subscribers we are talking about ? 90 seconds is way too much. For how is the big forum ?
Are you sure that the delay comes from wpForo. There are some good debug tools for WP that you could install.
https://wordpress.org/plugins/query-monitor/
And you can find easily those problems.
Thanks for the link, I will check.
It may have up to 2000 subscribers for some topics.
Thanks for the link, I will check.
It may have up to 2000 subscribers for some topics.
Then with the debuger you can find where the delay happens. You can pinpoint the problem.
