Cluster2 g*hs**ere.com upgrade issues - MERGED thread

PHP is screwed since "upgrade"

Jodo --

The recent upgrade is killing business!! You've broken every site that uses PHP. My hosting clients are losing business because of this. Their quote and contact forms are now disabled returning the following error:

Warning: mail() [function.mail]: SMTP server response: 553 sorry, that domain isn't allowed to be relayed thru this MTA (#5.7.1) in D:\hshome\maidhouston\maidhouston.com\s3nd\s3nd9.php on line 110

Warning: Cannot modify header information - headers already sent by (output started at D:\hshome\maidhouston\maidhouston.com\s3nd\s3nd9.php:110) in D:\hshome\maidhouston\maidhouston.com\s3nd\s3nd9.php on line 111
 
Re: PHP is screwed since "upgrade"

have you sent a ticket?
I did not see any ticket like this a couple hours ago. We are available via ticket at a priority.
I am merging this to CL2 upgrade thread.
 
Re: PHP is screwed since "upgrade"

My client was just advised of the error. They traditionally get NUMEROUS quote inquiries over the weekend and received ZERO. A site user finally called them to report the problem on both quote and contact forms.

They have seriously lost business because of this.

The ticket is in the cue now. I'm posting here because this issue needs immediate action and I had another issue that sat on hold for over a week un-responded to.
 
Re: PHP is screwed since "upgrade"

squidz said:
My client was just advised of the error. They traditionally get NUMEROUS quote inquiries over the weekend and received ZERO. A site user finally called them to report the problem on both quote and contact forms.

They have seriously lost business because of this.

The ticket is in the cue now. I'm posting here because this issue needs immediate action and I had another issue that sat on hold for over a week un-responded to.
Click to expand...

It doesn't look to be a upgrade related error, looks like using php mail() function and it needs to use phpmailser class and do SMTP auth.

still giving it a check but ticket is undoubtedly the best method.
We send a notice of this upgrade via email, problems can and will happen after upgrades. This MAY be one of them. Did you notify your clients of the upgrades happening?
 
The form has been working fine for well over a year. The last message my client received was Thursday. So, I would very much say it was an upgrade issue.

AND, someone has already responded to the ticket and the form now works.
 
My clients were advised there was an upgrade. But, the thing is that this upgrade disabled some part of every site I host with PHP in it. A couple were noticed immediately because the sites were offline completely. This one isn't data driven so it worked fine, but obviously the mailing feature did not.
 
squidz said:
My clients were advised there was an upgrade. But, the thing is that this upgrade disabled some part of every site I host with PHP in it. A couple were noticed immediately because the sites were offline completely. This one isn't data driven so it worked fine, but obviously the mailing feature did not.
Click to expand...

This isn't exactly correct.

php.ini you were using had smtp being a remote mail server, and it should have never worked before, if it did. I am sorry for the troubles you had, but for remote mail server in php.ini you have to use SMTP Auth.

We moved it to localhost and it is working for you now. But this wasn't something we did during the upgrade.
 
Stephen said:
This isn't exactly correct.

php.ini you were using had smtp being a remote mail server, and it should have never worked before, if it did. I am sorry for the troubles you had, but for remote mail server in php.ini you have to use SMTP Auth.

We moved it to localhost and it is working for you now. But this wasn't something we did during the upgrade.
Click to expand...
Err I apologize.

Akshay was working issue same time as me and was editing the php.ini different variables, it wans't your php.ini to start with. I didn't check the backups(takes quite a while) just to know this.
Anyway, it is fixed now. Still best to use SMTP Auth with phpmailer to ensure delivery :)
 
Stephen...I never set any .ini file at any time on any site I host. The php.ini issue is one that was created with the upgrade. It killed the .ini file I had on a Drupal site as well, which Support had to set in the first place.

This site was moved over to my hosting over a year ago and has operated just fine. I did not create, code or design it.

If it works great. I'll move on. But it is a fact that all of the PHP issues I've had so far happened as of Thursday.
 
squidz said:
Stephen...I never set any .ini file at any time on any site I host. The php.ini issue is one that was created with the upgrade. It killed the .ini file I had on a Drupal site as well, which Support had to set in the first place.

This site was moved over to my hosting over a year ago and has operated just fine. I did not create, code or design it.

If it works great. I'll move on. But it is a fact that all of the PHP issues I've had so far happened as of Thursday.
Click to expand...

yes I apologized about the ini already.


It is actually best to have one with phpmailer setup.
It helps ensure mail delivery with rDNSed mail servers.
What we have done is not for phpmailer but you can use it and base off of that.
 
thanks Stephen. when I have a chance I will look into the phpmailer you are referencing. I appreciate your replies.
 
You must log in or register to reply here.
Back
Top