starred/monolog

Fork 0

mirror of https://github.com/Seldaek/monolog.git synced 2026-04-27 00:25:50 +03:00

[GH-ISSUE #1866] cannot access private method #798

New issue

Closed

opened 2026-03-04 02:18:06 +03:00 by kerem · 8 comments

kerem commented

2026-03-04 02:18:06 +03:00

Owner

Originally created by @buexplain on GitHub (Jan 5, 2024).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1866

Monolog version 3

PHP Warning:  Invalid callback Monolog\Handler\RotatingFileHandler::customErrorHandler, cannot access private method Monolog\Handler\RotatingFileHandler::customErrorHandler()

Originally created by @buexplain on GitHub (Jan 5, 2024). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1866 Monolog version 3 ```php PHP Warning: Invalid callback Monolog\Handler\RotatingFileHandler::customErrorHandler, cannot access private method Monolog\Handler\RotatingFileHandler::customErrorHandler() ```

kerem

2026-03-04 02:18:06 +03:00

closed this issue
added the
Bug
label

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 12, 2024):

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

@Seldaek commented on GitHub (Apr 12, 2024): 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

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@lcharette commented on GitHub (Apr 13, 2024):

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 :

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

@lcharette commented on GitHub (Apr 13, 2024): 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**

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@lcharette commented on GitHub (Apr 13, 2024):

~~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

@lcharette commented on GitHub (Apr 13, 2024): ~~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

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 13, 2024):

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

@Seldaek commented on GitHub (Apr 13, 2024): 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

kerem commented

2026-03-04 02:18:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 15, 2024):

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

@Seldaek commented on GitHub (Apr 15, 2024): @lcharette can you please check using dev-main if this problem is fixed for you?

kerem commented

2026-03-04 02:18:08 +03:00

Author

Owner

@lcharette commented on GitHub (Apr 16, 2024):

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

@lcharette commented on GitHub (Apr 16, 2024): I confirm problem is fixed with `dev-main`. Thanks !

kerem commented

2026-03-04 02:18:08 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 17, 2024):

Great

@Seldaek commented on GitHub (Apr 17, 2024): Great

kerem commented

2026-03-04 02:18:08 +03:00

Author

Owner

@interactiveRob commented on GitHub (Sep 17, 2024):

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.

@interactiveRob commented on GitHub (Sep 17, 2024): 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.