T3DD11-Workshop¶

There was a workshop about TYPO3 Logging at the TYPO3 Developer Days 2011 in Sursee. About 20 participants worked together for half a day to analyze, understand and improve Logging in TYPO3.
The workshop was very successful and it turned out to be the kickoff for the first core project for the release of TYPO3 version 4.7.

Why Logging Improvements? About the problem we face with Logging in TYPO3¶

Excerpt from the Workshop abstract:
bq. Logging is a fundamental feature of any IT system. TYPO3 has various kinds of logging features, whereas it's characteristics are determined by different factors: User roles, logging purpose, targets, APIs etc. The logging features in TYPO3 have grown over the years and seem to be scattered all over the core and various extensions. Therefore it is hard even for the experienced users to understand and keep track of it.

Results from the workshop¶

Analysis of the actual Logging implementation¶

We investigated the most common Logging possibilities and discussed their pros and cons:

BE LOG¶

API

+ THERE IS NO API, only plain SQL queries
+ Configurable log levels (systemLogLevel in Install Tool)

- Mixing information target groups
- no way to configure targets (mail, etc)
- no localization
- no event triggers (no push, just pull)

UI

+ Filters
+ Overview of TYPO3

- Usability of the Backend module
- Insufficient information / Helpless information
- Separation/Right Management

WEB > INFO > LOG¶

It displays parts of BE log, but with a very limited feature set.

- Filters
- No configuration or not known to us.

DevLog¶

API (t3lib_div::devLog())

+ Way to give additional information in array
+ Add own view, like done with fire_devlog:http://forge.typo3.org/projects/extension-fire_devlog Extension for firebug
+ Works without xDebug
+ Easy to use for developers

- Not streamlined with rest of the logging API
- Path to class not logged/shown
- DLOG constant should be part of devLog() and is confusing

UI (devlog Extension - since this is the most popular one)

+ Filter by extension

- Debug array information is shown inline, bad with big data sets

Deprecation Log¶

+ Educates developers
+ Helps developers to keep code up to date

- Repeats the same message
- Flooding
- Yet another Logging system

BE Console Log (Debug Console)¶

API

+ Allows debugging of ExtJS in BE
+ Easy to use for BE debugging
+ Separated from Page markup

UI

+ Stays open although you reload

- Stays open although you reload
- Flooding
- Where to configure?

System Log (t3lib_div::sysLog())¶

API

+ allows to log to several targets (file, syslogd, email)
+ no_cache trigger detection

- BE log cannot be chosen as a target

UI

- No UI at all

admPanel¶

Link Validator¶

Query Logging¶

Reports module in the Backend¶

caretaker Extension¶

(not discussed, to be done later)

Challenges we face with Logging in TYPO3¶

• Complexity
• Insufficient documentation: Target group specific tutorials (developer, admins, ...), Guides, Best Practices and documentation how Logging works in general are yet missing
• Information overload
• Insufficient possibilities to filter, order and cluster Logging events
• Difficulties to realize common Logging strategies
• Insufficient, unstructured and confusing configuration options
• 3rd party integration
• Confusion: too many logging APIs which work almost the same way

Aspects of Logging¶

• Logging purpose (Why...?)
• Logging target (Where/Who...?)
• Logging severity (How harmfull is...?)
• Logging implementations (What tool/method...?)
• Logging documentation (How to...?)
• Logging events (What to log?)
• 3rd party Logging systems (How to integrate...?)