Bug #13784
Wrong severity in call to t3lib_div::devLog()
| Status: | New | Start date: | 2011-03-11 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | Estimated time: | 1.00 hour | |
| Votes: | 0 |
Description
tx_ncstaticfilecache uses PHP LOG_* constants for logging, and sends them also to t3lib_div::devLog()
But LOG_* are not compatible with t3lib_div::devLog() severity level.
t3lib_div::devLog() goes from low to high
OK -> error
-1, 0, 1, 2, 3
PHP LOG_* goes from high to low
EMERG -> DEBUG
0, 1, 2, 3, 4, 5, 6, 7,
patch attached
History
Updated by Steffen Müller about 2 years ago
Instead of mapping PHP<->TYPO3 severites, it would be more clean to put the "TYPO3" severity levels into class constants and replace all PHP LOG levels.
Another problem is that DEBUG does not exist in TYPO3 severites, but we have OK, which does not exist in PHP log levels. The meaning of OK seems to be out of the scope of the PHP log severites. For me it best matches INFO, but past discussions show that opinions differ. So the mapping in the patch does not fit 100%.
You can find a list of severites in the doc comment of devLog()
Severity: 0 is info, 1 is notice, 2 is warning, 3 is fatal error, -1 is "OK" message
http://api.typo3.org/typo3v4/current/html/classt3lib__div.html#a08129952019716c65c7ebd2be26a6a81
The conclusing of this issue for me is, that TYPO3 logging needs refactoring (of the core) to better match severites the rest of the world (syslogd, php log, ...) uses. But of course this is out of the scope of this issue...
Updated by Sebastian Mendel about 2 years ago
Yepp, you are completely right.
Especially with 'out of scope' for comments on T3 logging facility.
With all this in mind i have written the patch.
Leaving this broken is not an option IMHO, and i will call it broken, cause it reports simple notices as errors and errors as ok - this should really be fixed.
And waiting for the core to change it's logging facility is not a solution.
This is not a bug in the core or a missing feature, it is a bug in static file cache and should be fixed there.