A little mistake in mail sending controller

Hi there,

If you take a look at code generated by yiic webapp for each new, out-of-box application you’ll find inside SiteController.php in the code for actionContact() this piece of code:




	$headers="From: {$model->email}\r\nReply-To: {$model->email}";


	Yii::app()->user->setFlash('contact','Thank you... bla, bla, bla...');



Are you 100% sure that $this->refresh(); is correct and necessary?

In my situation (development environment on Windows using XAMPP 1.7.3) that caused sending e-mail function to fail with either message from PHP that maximum execution time of 60 seconds was exceeded (though message appeared always after about 2-3 minutes since executing malformed code) or a messagebox from Firefox saying that it detected that server is trying to perform an illegal redirect.

In either of these situations, when I looked into my sendmail.log file I’ve noticed that my e-mail message was sent not once but hundreds of times! And truly - my mail server was bloated by whole bunch of exactly the same e-mails generated by that Yii app and I was only wandering if it will not block my localhost as SPAM sender! :)

I had to change it to $this->redirect(array(‘contact’)); to get email sending function back to work. After that I’ve got result I wanted (back to contact page) and I’m pretty sure that this piece of code is an error as in my understanding of how Yii (and PHP and HTTP redirections) works, it forces PHP to refresh the address (action) taken for actually sending e-mail, not displaying contact form again, as it might be in creator of this code intensions.

refresh() does basically the same as $this->redirect(array(‘contact’)). See here. Note that the $_POST data does not get re-send when calling refresh().

Don’t know what the problem is in your case.

Yeap, also got no clue, what was wrong? Seen refresh() source code before, but the results were quite indisputable. Once I changed refresh() to redirect, sendmail started to have one line per each request (not hundreds of them) and neither PHP nor Firefox reported timeout or incorrect redirect ever since that. Weird, but true…