Forums

Email test fails but PHP *can* send email

Permalink
V5.8.2

The C5 dashboard email test for default PHP fails with:
The following error was found while trying to send the test email:
Unable to send mail: Unknown error

However doing putting mail('me@myplace.com', 'test', 'testing'); into the package's controller on_start() result in an email arriving immediately in my inbox after a page load so Apache php.ini is obviously fine and email through default PHP certainly works.

So what's going on?
surefyre
 
surefyre replied on at Permalink Reply
surefyre
Even more bizarrely using the C5 own mail object works perfectly:
$mail = \Core::make('mail');
        $mail->setTesting($testing);
        $mail->setBody("Dear concrete5 team\nYour CMS is by far the best I\'ve ever seen.");
        $mail->addParameter('mailContent', $body);
        $mail->load('default', 'packagehandle'); // add any parameters before loading the template
        $mail->setSubject($subject);
        $mail->from($from, $from_name);
        $mail->to($to);
        $mail->sendMail();


But writing my own email class isn't going to suddenly make system generated emails like registration validation suddenly start working.
surefyre replied on at Permalink Reply
surefyre
I'll submit a bug then so someone somewhere checks it.
surefyre replied on at Permalink Best Answer Reply
surefyre
For anyone reading this with the same problem I believe I found the fix. Finally.

In my installation, for whatever reason - and this is both dev and live which were both setup as standard C5 installs from 8.2.1 individually - the validation email from and fromname are null and this causes the validation registration email to screw up.

I put this in my package controller to explicitly set the values in C5
//
        // Fix validation email address info cos C5 team forgot to put it in?
        \Config::save('concrete.email.validate_registration.address', 'noreply@theonegroup.co.uk');
        \Config::save('concrete.email.validate_registration.name', 'The One Group');


Now it works. I really hope this helps folks with the same issue. Will add it to my bug report.

Now just don't tell the client I spent about a day in total finding this fix...
crowljor replied on at Permalink Reply
crowljor
I believe this is my issue but have no idea where to look for this. Can you give me more of a step by step of where I should find this and change the script?

Thanks for any of your help.
Jordan
surefyre replied on at Permalink Reply
surefyre
Of course, no problem. I actually ended up moving the code into the package install method as it really only needs to run once as it mods the config file via the C5 builtin functions. This is because I believe there's a bug in C5 which causes extra closing brackets to be written to the config file in question if it's run on every page load, which should be unnecessary anyway.

Anyhoo, this is how my package's install method starts, put any other install stuff you need for your package in there as usual. I raised a bug about this though in the meantime this would seem to work.

public function install()
    {
        $pkg = parent::install();
        // Fix validation email address info cos C5 team forgot to put it in?
        \Config::save('concrete.email.validate_registration.address', 'noreply@somedomain.co.uk');
        \Config::save('concrete.email.validate_registration.name', 'My site/co name');
        ... your code follows
}


The first line sets the FROM address for verification emails, the second line the FROM name e.g. noreplay@somedomain <My site/co name>

You could also mode the file by hand though this is not the 'approved' method of doing it. In <yourc5root>/application/config/generated_overrides/concrete.php you could add:
'email' => [
         'validate_registration' => [
             'address' => 'noreply@somedomain.co.uk',
             'name' => 'My site/co name',
         ],
     ],


Though the code is much easier to maintain imho
surefyre replied on at Permalink Reply
surefyre
N.B.

Recent versions of C5 have the email config in the dash now but if you're stuck with an older version (in my case a server can't have php upgraded for the moment so is running an older install) then changing the above 'validate_registration' string to 'default' seems a more robust fix.