Closed buexplain closed 6 months ago
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 :
fopen
fopen
fopen
trows an exceptioncustomErrorHandler
(even if we use @fopen
), then do the rest of it's job and return false
.customErrorHandler
againHere'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.
Monolog version 3