Regularly I’m asked to give help with Newsletter plugin for very very odd issue. The last one is worth to be told.
A plugin user was setting the SMTP parameters to send the newsletter using an external SMTP provider. Nothing special, standard connection with standard values.
But every time he tried to send a test email the admin page redirect to a 404 error page. To be clear, errors could happens but usually they produce a 500 code, or a message or a blank page. There the 404 error page was the one of WordPress, the same page displayed when a non existent content is requested.
OMG, how was that possible?
I asked the guy to contact the hosting support to get at least a server error log. As most of the time happens with cheap hosting provider, no error logs were available (actually they were but we didn’t receive instruction on how to find them).
I even asked if there was a firewall, but they said no, all external connection are open.
So I asked for an administrative access to the blog owner, patched Newsletter to report step by step the process of sending the SMTP test message. The system broke on the “send” action inside the WP mailing library. No way to touch that file without an FTP, so I asked for an FTP account.
I got it. I create a test page with only the few lines of code required to send a test email with the mailing library. Argh, no way, always a 404 error page on “send” call.
I sent back the test page URL to him asking to forward the URL to the support so they can debug the problem, of course the problem was neither in Newsletter nor in WP.
The answer with few lines of an Apache access log showing the server responding 404 when the test page is accessed. Are you kidding us? We know that!
I really kicked off my head on the keyboard of my laptop (ok, sorry, I’m not that pretty girl in the picture…).
Debug of the WP mailing library was required. Since I’m old on those kinds of problems and almost sure it was a connection problem, I copied the WP library to add debug info without interfere with the blog.
That library has an error suppression (grrr) which I removed and a log started to appear. Of course the problem reported was “stream_socket_client(): unable to connect to host:25 (Operation now in progress)”. Remember we have initially excluded firewalls. Never trust an hosting provider, never.
I tried even to use the phpinfo() function to find out if there was something in PHP installation that could explain the problem (other than a firewall), but of course the phpinfo() function was disabled for “security reasons”.
Has the story an happy ending? Of course no, we’re still waiting for an answer from the support… which will be… (I’ll update the post as soon as I talk back again with the blog owner).
Conclusion
When your hosting provider says the plugin you installed (even with 200.000 installs over the World) is not working because badly written, feel free to ask me to help, but then change the provider! :-)
Total time for this debug session was at least 3 hours in chatting, mailing, coding.
To know
This is just one complicate issue, of course not related to Newsletter, I faced over the 4 years my plugin is used by bloggers. I saw database encoding set with exotic values inside the wp-config.php which was blocking the plugin to install, redirects to the blog home page when saving a newsletter in raw mode and with the <html> tag in its content, blank page on newsletter saving because it contained the “update” word.
