[TYPO3-v4] Harmonizing severity levels

[François Suter]

Hi,

> I think changing the order and integers for the FlashMessage status
> should be trivial, because they are "new", their order sucks anyway and
> anybody who has used it will have used it using the constants, so the
> integers behind it are "safe".

Yep, makes sense.

> We have sysLog!
> -----------------
>
> But try to keep in mind that in TYPO3 core we have sysLog(), which is
> probably what people are confusing when trying to find the "right set"
> of severities, comparing with Unix syslog and Log4j:
>
>                  // Severity constants used by t3lib_div::sysLog()
>          const SYSLOG_SEVERITY_INFO = 0;
>          const SYSLOG_SEVERITY_NOTICE = 1;
>          const SYSLOG_SEVERITY_WARNING = 2;
>          const SYSLOG_SEVERITY_ERROR = 3;
>          const SYSLOG_SEVERITY_FATAL = 4;
>
> devLog() doesn't need to have this complexity. Its a "developer log"
> which sounds to me that it is required only during development or for
> debugging purposes. Its already very confusing for a developer to
> understand when to use devLog and when sysLog, more confusing because
> both allow similar severities.

Yes, we have sysLog, but this can't be compared with devLog. sysLog logs 
to some file, send mails or uses the server's syslog or PHP's error log. 
While this is useful sometimes, it is not easy to browse or search for 
records, compared to what the "devlog" extension offers with its 
database storage. I never use it for debugging.

And yes, to reply to your other mail, we also have 
$GLOBALS['BE_USER']->writelog() which writes to the sys_log table.
This one has several more problems IMO:

1) it already logs a lot of things. So if you want additional output, it 
may well be lost among all the rest. For example, an entry in sys_log is 
created for every TCEmain manipulation. On many of clients sites I 
import data every night, meaning that I have some 20,000 records in 
sys_log created *every day*. How should I find some extra logging in the 
midst of all this?
2) devLog serves yet another purpose that sys_log IMO. sys_log for me is 
exactly what its name implies: a log of system activity (TCEmain, login, 
etc.). devLog OTOH is for development. As you mention below TYPO3 can 
run in "full debug" mode when TYPO3_DLOG is on. Same goes for 
extensions. As such the devLog may also generate a vast quantity of 
entries, which you generally want to filter in some way (and here I mean 
filter *before* logging and not filter on display). The "devlog" 
extension offers a lot of criteria for such filtering.
3) the sys_log BE module totally sucks, whereas the devLog has been 
through many improvement cycles.

What I find redundant is sysLog and sys_log.

> An admin / developer enables DLOG in Install Tool only while trying to
> figure out why something doesn't work or while developing their
> extension. I usually use devLog as a "nicer way" to "debug()".

It's not just a nicer way to debug(). When you have some asynchronous 
stuff (e.g. Scheduler tasks) that you want to debug or some other kind 
of actions that happen when you're not looking, debug() is useless. You 
need log such output.

> =>  If an extension (or some core component) encounters an error, it
> should not use devLog to report it!!! It should log to sysLog, else only
> developers will see the error.

Not only. IMO it should also log to sys_log.

> I personally would prefer to have one single "logging" interface: "sysLog":
>
> - adding a SYSLOG_SEVERITY_DEBUG = -1
> - transform the "devlog" extension into a general "syslog" extension
> - integrate it into core as a sysext.
>
> Its a shame that several TYPO3 installations doesn't even know about
> sysLog because it is not configured by default.

What I would see is to introduce the structure I'm currently working on 
for the devlog: there's a central logging method which then calls a 
number of "log writers", that may write to various supports (database, 
file, error log, whatever). In a sense this is what t3lib_div::devLog() 
was meant for originally (as it just defines a hook), but my experience 
shows that it's nice to be able to filter log entries using many 
criteria before writing them. And those setting should be valid for all 
log writers, rather than having to be defined again and again for each 
extension that implements the t3lib_div::devLog() hook.

Furthermore if we have a more consistent structure, maybe we could have 
a single BE module to read all logs (and just switch between log sources).

> BTW: I find it silly that our core authentication services activate
> their devLog calls when DLOG is enabled. Usually these userauth devlogs
> are only interesting if you are trying to debug some authentication
> mechanism and there is already a SC_OPTIONS to activate it. See attached
> patch #1, maybe others have a similar feeling.

Well, DLOG is supposed to be a general debugging flag. RealURL also logs 
everything if DLOG is on. In my own extensions I generally have my own 
debug flag, but also react on the DLOG flag.

Cheers

-- 

Francois Suter
Cobweb Development Sarl - http://www.cobweb.ch