Hi Martinaelena.. thank-you for the bug report!
That code handles the database upgrade. If your db needs upgrading, Postman is going to get stuck here. i’m sorry for any inconvenience this has caused. I will release a fix right away.
By installing Postman v0.24, I was able to reproduce your error by attempting an upgrade to v1.3.1:
[10-Feb-2015 18:54:08 UTC] PHP Fatal error: Call to private PostmanAuthorizationToken::__construct() from invalid context in /Users/jasonhendriks/Sites/wordpress/wp-content/plugins/postman-smtp/postman.php on line 115
And create a fix:
[10-Feb-2015 19:00:37 UTC] DEBUG PostmanActivationHandler: Activating plugin
[10-Feb-2015 19:00:37 UTC] DEBUG PostmanActivationHandler: Upgrading database: copying Authorization token from postman_options to postman_auth_token
[10-Feb-2015 19:00:37 UTC] DEBUG PostmanActivationHandler: Upgrading database: setting Authorization type to OAuth2
[10-Feb-2015 19:00:37 UTC] DEBUG PostmanActivationHandler: Upgrading database: creating auth_type and enc_type from authorization_type
[10-Feb-2015 19:00:37 UTC] DEBUG postman.php: Normal exit
Please download v1.3.2.
I was able to activate, but the plugin is not working for me. I am using contact form 7. Getting an error: Failed to send your message. Please try later or contact the administrator by another method. I have the latest contact form installed as well. any ideas?
And you said the test e-mail works for you, but sending with the Contact Form fails? Would you please send me a screenshot of the Mail panel inside your Contact Form 7 settings to jason -at- hendriks -dot- ca.
I will set up a contact form the same as yours and see if I can reproduce your error. My contact form works fine.
Because the code inside wp_mail() runs outside of the Postman admin panel, i.e.. when you run Contact Form 7, a surefire method to pinpoint the issue is to enable logging in your WordPress wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
the log file at wordpress/wp-content/debug.log should pinpoint exactly what’s going wrong with your Contact Form 7 submission.
Be sure to disable debug when you’re done.
Hi martinaelena. I’ve been sending emails over and over on my test production site, chef.jasonhendriks.com, trying to reproduce what you see, and finally my Contact Form 7, out of the blue, told me it couldn’t send email.
I had debug on at the time and the log says that it was a socket connection error. I tried it a couple more times and it worked once, then didn’t work again. Seems my host (OpenShift) is having connectivity issues. At one point it told me “Couldn’t resolve host ‘www.googleapis.com'” It’s nothing consistent though.
I was wondering what host you are using?
Hi martinaelena. I figure it’s a timeout issue. I’ve added the ability for the user to override the TCP Read Timeout in the next version.
okay, Thank You. I will try it again on the next version!
Jason, I also had timeout issues with my web host using another plugin, and had to hack it to get it to work, basically adding parameters to override $phpmailer->Timeout and $phpmailer->Timelimit in WordPress’s old version of PHPMailer. Is that what your connection and read timeout parameters correspond to?
Details: http://www.mcbsys.com/techblog/2015/01/increasing-the-wp-mail-smtp-timeout/
I can’t comment on phpmailer without looking at the source code but I see no reason to doubt your hunch.
In Postman, the connection timeout is passed to PHP’s fsockopen and the read timeout is passed to PHP’s stream_set_timeout.
On an unrelated note Mark, I tried to comment on your blog a few days ago and when I hit submit I got an error saying the Captcha file wasn’t readable… then I tried to leave you a message through the contact form and the entire site crashed.
Sound like you need to ditch your anti-spam comment filter. I use both Anti-spam and Math Comment Spam for Comments… and Contact Form 7 Honeypot for Contact.
Amazing how many timeout hoops the connection must jump through. I hadn’t heard about fsockopen and stream_set_timeout. I had heard that some hosts have PHP timeout limits, and some hosts allow increasing those. With help from my hosting company, I had increased PHP’s max_execution_time and max_input_time to 500. In the end WordPress default 10-second PHPMailer timeout was the culprit. The PHPMailer debug output was helpful in finding that.
Thanks for the site/Captcha feedback. Will reply offline.
What sucks about a long timeout is that PHP/WordPress is single-threaded, and if your email really takes 60 seconds to send, that’s 60 seconds where the user can do nothing else on your site.
I’m toying with the idea of saving messages in the database and sending them in the background, but the rub with that is approach is that the user will see an immediate success message even if the message fails to send a few minutes in the future.. something to ponder.
I think you’ve hit the core of WordPress email woes: if you’re on a shared hosting plan, using the host’s local SMTP relay is fast, but subject to spam blocking. But authenticating and sending through an external host may take too long. Background sending seems like the holy grail. It had crossed my mind to wonder if delayed_job (which I’ve used with Ruby) could work for that and whether my host would allow it.
IMO when you tell the sender “success,” you’re only saying (like any email program) that we’ve accepted your mail and will try to deliver it. Keeping a copy in the database is a big step up from throwing it into the wild and hoping it gets through.
You’re basically talking about duplicating SMTP functionality inside WordPress: accept mail, queue it up, try repeatedly to deliver it, report failures. It would be nice to be able to see and debug the outbound queue in the back end rather than worrying about mail disappearing into the ether and wondering where/how to find bounce messages.
