This is weird.. I can't reproduce it (https://3v4l.org/ZHA87) and I don't really see why it would do this as the callback is only used within the context of StreamHandler /cc @corentin-cres

I was able to replicate this UserFrosting by removing write permission to the log file, which resulted in a similar error message :

Fatal error: Uncaught Error: Invalid callback Monolog\Handler\StreamHandler::customErrorHandler, cannot access private method Monolog\Handler\StreamHandler::customErrorHandler()

Using the example above (https://3v4l.org/ZHA87) on the same environment and on the same file (without write access) returned the proper output :

string(40) "Failed to open stream: Permission denied" string(9) "Test test" 

The difference is our app use a custom StreamWrapper. So the core PHP fopen isn't actually called by Monolog's StreamHandler, but our own. And both will invoke customErrorHandler, which won't work on our side since the method is private. Therefore, customErrorHandler must be public.

Note the actual process when customErrorHandler is public is similar to this :

1. Monolog StreamHandler call fopen
2. Our own StreamHandler calls fopen
3. fopen trows an exception
4. Our StreamHandler invoke customErrorHandler (even if we use @fopen), then do the rest of it's job and return false.
5. Monolog invoke customErrorHandler again

Here's a way to replicate : https://3v4l.org/PjtpI

(Forget the open_basedir restriction in effect error... that means it's working, simply I can't replicate a non-writable file on the editor)

There we go. Both should return "Failed to open stream" : https://3v4l.org/LsBph

Great, thanks for the investigative work there! I guess maybe using a closure instead would be better, otherwise public method with an internal phpdoc.. Anyway I'll look at this next week

@lcharette can you please check using dev-main if this problem is fixed for you?

I confirm problem is fixed with dev-main. Thanks !

Great

just in case anyone else from Userfrosting winds up here and is wondering which log file @lcharette is talking about above. --

That would be the /logs/userfrosting.log file. In my case, the app did not have write permission on the log which triggered the same private method issue discussed here.