• Resolved kbaldac

    (@kbaldac)


    Getting this error message when adding topics or replies to the forum:

    Nov 11, 09:34:41
    Fatal error: Maximum execution time of 120 seconds exceeded in /wp-content/plugins/bbpress-notify-nospam/bbpress-notify-nospam.php on line 918

    Getting this on the current version, 1.18.6, and started getting it on the previous version, 1.18.5, last week (but had been using the previous version for a while). I thought it might relate to a GD bbPress Toolbox update but I still get the error even if I roll back the Toolbox update.

    Sending about 50 notifications when a topic or reply is posted. Hosting is on a shared server.

Viewing 15 replies - 1 through 15 (of 16 total)
  • Plugin Author useStrict

    (@usestrict)

    Hi @kbaldac,

    Have you tried turning on the Background notifications options in Settings > Forums > Email Notifications? That usually does the trick.

    Cheers,
    Vinny

    Thread Starter kbaldac

    (@kbaldac)

    Thank you for the very quick response. Yes, I set background notifications but then we didn’t get any notifications at all. Any other ideas? Your plug-in has worked absolutely fine for us for several years now.

    Plugin Author useStrict

    (@usestrict)

    Background notifications require plenty of visits or a working real cron job as wp-cron isn’t very reliable.

    Setting up a real cron job varies from host to host, but if yours gives you cPanel, then this tutorial should be good enough:

    https://www.siteground.com/tutorials/wordpress/real-cron-job/

    Cheers,
    Vinny

    Thread Starter kbaldac

    (@kbaldac)

    Thanks Vinny. I do have CPanel access but I think this is one I’ll discuss with our hosting company. But we get perhaps 500 visits a day which I would have thought would be enough. There’s almost never a time when there’s no visitors. Do they need to be logged in visits?

    Plugin Author useStrict

    (@usestrict)

    I don’t think they need to be logged in, no. But you’ll really be better off with a real cron job. The unreliability of wp-cron is well known in the WordPress community.

    Thread Starter kbaldac

    (@kbaldac)

    Vinny,

    I think we’re making some progress. We turned on email logging and our host substantially increased the timeout interval and, although the system still ‘crashed’, we got a different error message that pointed us in another direction. It appears that the UTF-8 encoding setting, which I think the plug-in may default to ‘on’, is causing a problem on one of our forums that has a single quote in the subject line of notifications.

    We’ve now turned off the UTF-8 encoding and the system is no longer crashing. We can see in the email log that the system thinks notifications are now being sent, however we haven’t yet received any of the notifications and we’re working on tracking them down. If you have any ideas on this, let me know.

    We know we’ve got problems with 1.18.5 and 1.18.6. Do you think we should try rolling back to 1.18.4 or an earlier version (if so, which one)? Thanks.

    Kim

    Plugin Author useStrict

    (@usestrict)

    Hi Kim,

    Increasing the timeouts is only a temporary solution at best, and it’s still bad user experience as the user will have to wait a lot before they see the success screen of their post.

    UTF-8 encoding in the subject line only really kicks in if the function iconv_mime_encode() is available in your host’s PHP. What is the error message that you saw when it crashed?

    Regarding rolling back, 1.18.6 has a check in place for the existence of mb_convert_encoding() (which it previously just assumed existed) and falls back to htmlspecialchars_decode(utf8_decode(htmlentities(...))) if it doesn’t.

    Rolling back is not a good idea.

    As for tracking the messages, what mailing plugin do you have installed, if any? Are your messages going through your host, or some third party service? I recommend trying Mailgun as they have all sorts of logging you can use to debug mail delivery.

    Cheers,
    Vinny

    Thread Starter kbaldac

    (@kbaldac)

    Thanks Vinny. It’s not the extended time interval that stops it from crashing. When UTF-8 is turned on and there’s a single quote in the subject line, I get the topic being put into the forum but also I get:

    ‘The server encountered an internal error or misconfiguration and was unable to complete your request for .’

    and I get:

    Fatal error: Maximum execution time of 360 seconds exceeded in /wp-content/plugins/bbpress-notify-nospam/bbpress-notify-nospam.php on line 918

    (this would time out at 120 seconds before the timeout interval was increased)

    And the email log only gets 1 notification (rather than the expected 50 or so) that is sent to no_reply@<domain name> with the content of the topic submitted on the forum.

    With UTF-8 turned off and a single quote in the subject line (same forum), I get the topic being put into the forum, the forum ‘submit’ completing in reasonable time and the 50 or so expected notifications being written to the email log. I still need to track down where they went to but there is no system error or crash and the notifications are at least being generated as reflected in the email log.

    I will have my host reduce the extended time interval back to what it was since the time interval was not the problem, it just was a result of the code executing endlessly when UTF-8 encoding was turned on. However, should I have real timeout problems in future, I’ll keep in mind the alternative to wp-cron. It’s just not the solution for the problem I’m having at present. It concerns me that I can’t roll back to a version where this doesn’t happen but hopefully I can continue to avoid the problem by keeping UTF-8 encoding switched off.

    Our mailing is through our host and we have logs to track it down. I’ll let you know when I find what happened to the notifications! Thanks.

    Kim

    Plugin Author useStrict

    (@usestrict)

    What PHP version are you running? Google says iconv_mime_encode() was a bit buggy in 5.2 or 5.3.

    Thread Starter kbaldac

    (@kbaldac)

    php 5.6 and WordPress 4.9.8 with a Genesis framework.

    Plugin Author useStrict

    (@usestrict)

    Please reach out to your host and mention the iconv_mime_encode() issue. They can test it separately by putting the following in a regular PHP file:

    
    $preferences = array( 'input-charset' => 'UTF-8', 'output-charset' => "UTF-8", 'scheme' => 'Q');
    var_dump( iconv_mime_encode( 'Subject', "Testing subject", $preferences ) );
    
    Thread Starter kbaldac

    (@kbaldac)

    Will do.

    Thread Starter kbaldac

    (@kbaldac)

    Vinny,

    Just to let you know that both 1.18.5 and 1.18.6 are working again as long as we turn off UTF-8 encoding in the subject line. As a separate issue, we found that not all of our notifications were being delivered due to email volume limits set by our host. Thanks for all your very rapid help.

    Kim

    Plugin Author useStrict

    (@usestrict)

    Hi Kim,

    Thanks for letting me know. Would you mind testing 1.18.4 as well? There really isn’t any difference that would affect the UTF-8 subject line. The iconv function used has not been changed in forever, and I check if it’s available before trying to use it.

    I suspect whatever happened was on your host’s end. Maybe they changed how PHP is used by the web server (fast-cgi, mod_php, etc.) and that started causing the issue.

    As for email volume limits, I strongly recommend using Mailgun. It’s free for up to 10000 monthly emails.

    Marking this as resolved.

    Cheers,
    Vinny

    Thread Starter kbaldac

    (@kbaldac)

    Vinny,

    We went back to 1.18.4 and get the same problem exactly if UTF-8 encoding is turned on:

    Fatal error: Maximum execution time of 120 seconds exceeded in /wp-content/plugins/bbpress-notify-nospam/bbpress-notify-nospam.php on line 916

    Only one no-reply@<domain name> email in the email log, rather than the 50 or so expected ones. All works fine if we turn off UTF-8 encoding.

    Possibly, I had UTF-8 encoding turned off on our production system and then enabled it at some point. Thanks.

    Kim

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Timeouts’ is closed to new replies.