2

Does anybody know how to make a disabled function (in my case ini_set()) stop throwing an error? I usually have it like @ini_set() but on this WP plugin, it STILL fills the error_log with:

[30-Apr-2018 12:01:39 UTC] All-in-One Event Calendar: ini_set() has been disabled for security reasons @ /home/burp/public_html/wp-content/plugins/all-in-one-event-calendar/all-in-one-event-calendar.php:81 #2

I suspect it's because that ini_set actually sets a callback function and another ini_set() is called within that ini_set() function defined. Here's the error_log'ed line 81 in question:

@ini_set( 'unserialize_callback_func', 'spl_autoload_call' );

I'm the server administrator and I disabled ini_set() years ago and I have no problem with this, I just want to MUTE the error logging on that script. +100 WP sites that all include ini_set() are NOT reporting any error, only this particular one, despite the @ before the ini_set().

that-ben
  • 245
  • 1
  • 13
  • 5
    Did you read the error message? It's the not function throwing that error, it's PHP throwing that error. – John Conde Apr 30 '18 at 12:29
  • I know? I'm asking how to MUTE the ini_set() – that-ben Apr 30 '18 at 12:30
  • 1
    The best way to disable the error would be to remove/fix the line in question. If this is a 3rd party script, contact the maintainers to find out if it's necessary and if you can remove it. – aynber Apr 30 '18 at 12:31
  • 1
    Jesus christ, I KNOW, I'm the server administrator and I disabled ini_set() years ago and I have no problem with this, I just want to MUTE the error logging on that script. +100 WP sites that all include ini_set() are NOT reporting any error, only this particular one, despite the @ before the ini_set(). Is this clearer? – that-ben Apr 30 '18 at 12:32
  • 1
    @that-ben learn to use your title/body to clarify the question clearly instead of adding words to make it seem comical in the future. The confusion has arose because you never clarified exactly what you meant. – Script47 Apr 30 '18 at 12:38
  • 5
    The `@` decorator just suppresses the *default error **display** handler*, not any custom ones or logging per se. (It's often called "error suppression operator", but that's somewhat misleading.) – mario Apr 30 '18 at 12:39
  • @mario At last an answer that's related to the question! Thanks for some light at the end of the tunnel Mario! Any suggestion how to overcome it? (mute the error_logging) – that-ben Apr 30 '18 at 12:41
  • For portable code (under your circumstances), the program could check whether or not `ini_set` is disabled. If you need to support EOL PHP versions, you can parse ini_get returns (if you didn't disable that as well): [PHP exec - check if enabled or disabled](https://stackoverflow.com/q/2749591/367456) - Or make use of the parameter of [`get_defined_functions`](https://php.net/function.get-defined-functions.php) – hakre Apr 30 '18 at 12:48
  • @hakre I do not need to know if ini_set() is disabled, it's always disabled on all sites on this server and I want to leave it like that for security purposes. I only want to mute that particular line which is the only ini_set() line to trigger this error log on +100 WP sites that all have at least 1 ini_set that's perfectly muted with @ini_set(), this is the only one that sticks to error logging for some reason, probably because it's a callback which could in turn include another ini_set() that's not muted. I have to download all the files and mass search on all files. – that-ben Apr 30 '18 at 12:52
  • @that-ben: I've read that. Either fix the error handler and/or make the code portable (for which I just commented, for the other others have commented). If you knew ini_set is disabled you could not use it under that circumstance. But I got it: Just fix the damn error_handler you've got a problem with. Do that now :) – hakre Apr 30 '18 at 12:55
  • 1
    So many ways that things went wrong in this thread. – Elin Apr 30 '18 at 13:01

1 Answers1

2

The error control operator @ would normally suppress the error message, however a custom error handler defined with set_error_handler can still cause the error to be logged via error_log.

error_reporting will return 0 if the call that triggered the error was preceded by an @. The error handling function should check that before logging the error:

if (error_reporting()) {
    // Report the error
    error_log(...)
}

Looking at the calendar code below, you can see that error_log is called for non-fatal errors. You could simply add a check for error_reporting in that script.

https://github.com/wp-plugins/all-in-one-event-calendar/blob/86c4e20dab7b199b20207fb3918a8807f7342fab/lib/exception/handler.php#L287

Alternatively you could disable error_log or re-enable ini_set for that page.

POST MORTEM EDIT: It is worth noting that despite the error log specifying the error was caused by ini_set() being disabled, the error was originating from deeper in the callback of the function defined within the ini_set() in question (the line 81 displayed in OP). So basically, the error is not even relevant at all. It's bubbling up to the ini_set() and creates confusion as the reason and even the line is not about the error that was actually thrown.

that-ben
  • 245
  • 1
  • 13
jspcal
  • 50,847
  • 7
  • 72
  • 76
  • So error_reporting(0); then that faulty line then error_reporting(E_ALL); ? – that-ben Apr 30 '18 at 12:43
  • But doesn't @ effectively do this (setting the error reporting level to 0 temporarily) already? So it would only need to check that error handler, correct? – hakre Apr 30 '18 at 12:49
  • 1
    To honor the `@` operator, the user-defined error handler function needs to manually check `if (error_reporting())` before calling `error_log`, which it doesn't seem to do now. See the snippets above. – jspcal Apr 30 '18 at 13:10