Log Writer Configuration
Most of the logger configuration can be done by configuring the log writers.
The configuration of log writers can be either done in the application.ini / installation.ini or hardcoded in PHP.
System-Admins should add their custom writer configuration to the installation.ini.
Please see ErrorHandling and Application Logger for information about the log levels.
The configuration in application.ini is reserved to translate5 developers - since this file is overwritten on each update.
When overwriting resources.ZfExtended_Resource_Logger.writer.mail.receiver in installation.ini the default value from application.ini is overwritten too. That means the default receiver should be added to installation.ini too:
resources.ZfExtended_Resource_Logger.writer.mail.receiver = 'your receiver'
resources.ZfExtended_Resource_Logger.writer.mail.receiver = 'our default receiver from application.ini'
DirectMail different users for different errors
With the filters it is possible to setup multiple DirectMail Loggers with different receivers for differently filtered events:
Task Writer Configuration
The TaskWriter is a editor specific writer, it logs only events containing information about a task.
The events are logged in a dedicated table, accessable via the frontend.
Only warnings or events more severe as warnings are written by default to the task log. So no notices about tasks are additionally logged.
Also on code level new writers can be added on the fly to a logger instance.
Each writer can have an list of filter rules. See the above module.ini example. The filter rules are connected via "or", that means one of the filter rules must be valid in order that an event is logged to that writer.
Each filter rule is it self, a semicolon separated list of expressions. All expressions of one rule are connected via "and", so all expressions must be evaluated to true in order that the rule is valid.
An expression consists of a keyword, an operator and a value, for example: "level <= warn". Each keyword can be used multiple times, so "level >= warn; level <= trace" would also be possible.
They keyword must be always the first operand! So "warn <= level" would give an error since it can not be parsed.
In the following table a list of valid keywords and operands is listed:
Is used to compare with the log levels as defined at the top of this page.
The second operand must be a valid log level: "fatal", "error", "warn" etc.
Example: given FATAL(1), configured "level <= WARN(4)" the event is filtered, since level 1 (fatal) is lesser then level 4 (warn)
|<=||Is true if the current level is equal or has a higher severity as the configured one.|
|>=||Is true if the current level is equal or has a lower severity as the configured one.|
The domain (origin) of the event must be matched completely.
|!=||The domain (origin) must not be equal to the configured one.|
|^=||The domain (origin) must start with the configured string.|
|$=||The domain (origin) must end with the configured string.|
|*=||The domain (origin) must contain the configured string.|
|exception||=||The exception equals the given exception class name|
|!=||The exception is different to the given exception class name|
|*=||The current exception is a subclass of the given exception name|