After upgrading PHP from 5.6 and 7.2.4, the php error log is full of messages like this, even when just loading the front page without logging in:
PHP Warning: Declaration of PKPUsageEventPlugin::getEnabled() should be compatible with LazyLoadPlugin::getEnabled($contextId = NULL) in /usr/local/share/ojs/lib/pkp/plugins/generic/usageEvent/PKPUsageEventPlugin.inc.php on line 0.
My code is 3.1.1 out of the box except that I added a mathjax plugin. After logging in, I get the same type of messages and ones like this involving quite a lot of different functions. In some examples, the argument list is the same but the default values are not.
PHP Warning: Declaration of SubmissionFileDAO::fromRow($row) should be compatible with PKPSubmissionFileDAO::fromRow($row, $fileImplementation) in /usr/local/share/ojs/classes/article/SubmissionFileDAO.inc.php on line 23
PHP Warning: Declaration of PluginGridHandler::loadCategoryData($request, &$categoryDataElement, $filter) should be compatible with CategoryGridHandler::loadCategoryData($request, &$categoryDataElement, $filter = NULL) in /usr/local/share/ojs/lib/pkp/classes/controllers/grid/plugins/PluginGridHandler.inc.php on line 20
Everything I do produces 5-10 such messages in the php error log.
This posting is a bit similar to this one but the comments there about restful urls don’t seem to be relevant. The same happens with restful urls turned off or on (and when they are on, they work as I have a .htaccess file for them).
@harolg Maybe so, but several thousand characters written to the error log every time someone does anything will create an excessively large log in no time, and it buries messages that may be more important.
You have a good point there. You can also play around with your php.ini to have the way the error log will present the errors:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; This directive informs PHP of which errors, warnings and notices you would like
; it to take action for. The recommended way of setting values for this
; directive is through the use of the error level constants and bitwise
; operators. The error level constants are below here for convenience as well as
; some common settings and their meanings.
; By default, PHP is set to take action on all errors, notices and warnings EXCEPT
; those related to E_NOTICE and E_STRICT, which together cover best practices and
; recommended coding standards in PHP. For performance reasons, this is the
; recommend error reporting setting. Your production server shouldn’t be wasting
; resources complaining about best practices and coding standards. That’s what
; development servers and development settings are for.
; Note: The php.ini-development file has this setting as E_ALL. This
; means it pretty much reports everything which is exactly what you want during
; development and early testing.
;
; Error Level Constants:
; E_ALL - All errors and warnings (includes E_STRICT as of PHP 5.4.0)
; E_ERROR - fatal run-time errors
; E_RECOVERABLE_ERROR - almost fatal run-time errors
; E_WARNING - run-time warnings (non-fatal errors)
; E_PARSE - compile-time parse errors
; E_NOTICE - run-time notices (these are warnings which often result
; from a bug in your code, but it’s possible that it was
; intentional (e.g., using an uninitialized variable and
; relying on the fact it’s automatically initialized to an
; empty string)
; E_STRICT - run-time notices, enable to have PHP suggest changes
; to your code which will ensure the best interoperability
; and forward compatibility of your code
; E_CORE_ERROR - fatal errors that occur during PHP’s initial startup
; E_CORE_WARNING - warnings (non-fatal errors) that occur during PHP’s
; initial startup
; E_COMPILE_ERROR - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; E_USER_ERROR - user-generated error message
; E_USER_WARNING - user-generated warning message
; E_USER_NOTICE - user-generated notice message
; E_DEPRECATED - warn about code that will not work in future versions
; of PHP
; E_USER_DEPRECATED - user-generated deprecation warnings
;
@haroldg The php folks moved this particular event from E_STRICT to E_WARNING, which is where most warnings reside. So suppressing it cannot easily be done without suppressing most warnings.
As an experiment, I copied the code from this web page, together with a call to orbisius_p3778_warning_suppressor_supress_warnings(), to the main index.php file, before the other code.
This successfully removes this family of warning messages from the log for the actions I tested. Of course that is not the proper place to put it. Moreover, I’m not sure it will always work since some other parts of OJS install an error handler and only one is allowed at a time. But as a short-term cosmetic fix it seems ok.
@bdm,
Swelling of error_log is a common server problem.
In my case, I have scheduled to delete the file everyday with cron job.
If some problem come to my notice, I can log those errors on demand and look into the error message.
This is one way to deal with increasing error_log file.
The PHP language specification here describes the limits on adjusting function signatures on inheritance. Note this definition of compatibility especially. I think that all the examples I gave are errors by these definitions. Brendan.
@asmecher These messages fill up the error log at a great rate and are a real nuisance. I hope your team can systematically clean the code to remove them in some version before too long.
Considerable work has already been done for this as part of https://github.com/pkp/pkp-lib/issues/3578, which will be released shortly in OJS 3.1.2. However, it’s a large codebase, and PHP’s language standards are a moving target, so it will be an ongoing effort. PRs are welcome.
Regards,
Alec Smecher
Public Knowledge Project Team
I am using version ojs-3.1.2-4, no matter what I’ve tried, I still get a lot of “php Warnings” in error.log. I also set in the php.ini this directive “error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT” and restart apache, but Warnings are still there.
Do you know of a way to filter these Warnings, so that I can better read the real Error messages?
That’s more of a PHP question than an OJS question; I’d suggest checking through the error_reporting documentation, and possibly StackOverflow.com. Meanwhile, we’re gradually fixing the issues that cause the warnings, so each release should see fewer of them.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks @asmecher! I thought by setting “error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT” I will get rid of Warning messages, do you think so? I have read php manual, stackoverflow and as well as documentation within the php.ini. do I not understand something?
In my experience the details are dependent on your version of PHP; from release to release messages will wander between hard exceptions, warnings, deprecations, notices, etc. I’m afraid you’ll have to experiment to find the mix that works on your system.
Regards,
Alec Smecher
Public Knowledge Project Team
superb, now that I know and have a direction I will try to tailor my environment to get what I want the best I can. Thanks so much for sharing @asmecher !