Email sending error ini_restore() instead of warning

Hi ive had some hell time sending email through kirby. I thought its problem of my server but finaly i got somewhere and it seems to me there is some problem with kirby email function.

When doing just the simple

$email = email(array(
  'to'      => '',
  'from'    => '',
  'subject' => 'Yay, Kirby sends mails',
  'body'    => 'Hey, this is a test email!'

if($email->send()) {
  echo 'The email has been sent';
} else {
  echo $email->error()->message();

On version 2.4.1 i get whoops error

Call to undefined method Whoops\Exception\ErrorException::message()

On version 2.3.2 i get

Warning: ini_restore() has been disabled for security reasons in /data/www/kirby/toolkit/lib/email.php on line 160
The email has been sent

So the first question is - Do i have to have ini_restore() enabled on the server? It is warning, what is the reason for it?

Then there is something wrong because it seems kirby thinks that the warning is error and whops cant recognize it. Realy even if i dont use the errror function $email->send() is always false no matter what i do in 2.4.1.

The most curious thing is that email is sent every single time. Even if i get the biggest error ever.

It seems that there is something wrong with the warning logging?

Well, this is line 160:


So if ini_restore() is disabled, this will throw an error.

As regards Whoops, you can disable it if you want.

But the undefined message() method rightly throws an error.

But 2.4.1 shouldnt throw an error. It should be warning and it shouldn’t halt the whole thing.

Whoops was in 2.3. also no?

Whoops was added in 2.4.0…

And why it was warning in 2.3. and now is error?

I mean this is clearly warning and you should know about it when you debug but you can also simply ignore it because its just reseting from value to initial state.

Whoops halts everything on warnings?

Seems strange to me.

Whoops always comes up with this error page, not matter if the error level is notice, warning or fatal error or whatever.

I don’t know if there are any Whoops options to change this behavior that Kirby could leverage.

Currently, if you don’t like it, I suggest that you disable Whoops.

Edit: I my test, Whoops does throw an ErrorException, yes, but it does not halt script execution.

Yes it doesn’t halt the execution (that’s why the emails were sending).

I still think that it is a quite serious problem. You see one thing is that whoops threw an error page which i can disable. The other one is that the error didn’t show the php warning it showed error basically nothing. Realizing that it was only server warning was only possible when i used version without whoops.

Whoops wasn’t showing the php warning - it was showing error of itself. It couldn’t understand the warning that was passed to it.

This might happen quite often and i think you can’t expect people to be turning whoops on and off to get proper errors. Last thing i would expect is debug tool showing me lies in occasions where dumb php error would be fine.

Now ive used other cmses that also use whoops and i am pretty sure they handle warnings. Also on whoops github there are issues around this and whoops should be very capable handling this.

Isn’t there some problem with whoops implementation in kirby instead?

Well, yes, maybe. This is what I get from Whoops when I disable ini_restore():

Is this the same as your result?

This is different from the usual Whoops Errors/Warnings/Notices, where I get this black page.

On the emails example above.
Yes i get the same message if i just echo the error

echo $email->error();

when i try to have whoops handle the error like it is in examples

echo $email->error()->message();

I get

Strangely i remeber yesterday there wasnt the stack trace it was empty with just one error. But error was the same.

Maybe i understand it wrong and its just problem of this example. But the message() is there when i dump the error. It would probably be useful to test it on something else.

I any case ive solved the problem by making my own email driver.

It just seems that i should just get the right whoops warning if i use

  echo $email->error()->message();

Because errors it handles well, just not the warning.

I don’t think so, because there is not message() method defined. When you dump the error, you see a protected property message, but you can’t access that.

Ok so what is wrong? I shouldnt use $email->errorr()->message() or message() should be defined there?

Was i wrong the whole time?

Exactly, there is no message() method, so you can’t use $email->error()->message(), that’s what I was trying to tell you.

I understand that, but that doesn’t really explains it.

This is example straight from docs and message() is there to handle error - it exists when you make error. But it doesn’t when you make warning… So either there is anotherway how to handle warnings (and it should be noted somewhere) or message() is missing there and shouldn’t.

Where did you find that?

Thanks, I see. Hm, the toolkit error class does have a message() method, but the error that is thrown is thrown by Whoops, it seems, and Whoops does not have a message() method.

Well i have no idea what role whoops is playing there and how its implemented. I thought that its just sugar that catches all exceptions no matter what you do. So the whole error()->message() seems strange because it should bubble up automaticaly (atleast i would think) but i am really php weak so who knows.

Maybe the problem is just in the doc example and its something legacy error handling before whoops and now it should be handled differently.

But it would be nice to know :slight_smile:

Anyway thanks. Hopefuly it wasn’t wasted time.

I have opened an issue in the repo, although I’m not sure where it belongs.