Provide watchdog aware renderers

I think a better solution would be to not put the log message body through format_string() function which t() uses. The attached patch provides a clone of t() with the only exception that log4php_t() skips calling format_string.

better title?

added '// Construct plain-text message' back :)

I'm not sure I understand "why not just change the sanitization to !variable?"
All messages that come from core and contrib will have % or @ or ! in them. You can't change that.
Do you suggest replacing all '@' and '%' to '!variable' in log4php watchdog implementation? I would not like to do that to be honest

Hi Erik,

I gave this issue a bit more thought and I think you might be (partially) right :)

I'l like to step back and reiterate (even though we already know this) what the default logging (dblog module) system does:

• it takes care of the both creating and displaying of the logs
• it uses t() function in order to get 2 things done: translatable logging messages and escapes the %, @ and ! "tokens" that exist within the message for security reasons.

Regarding displaying of the messages, DBlog's approach works just fine when all you want to do is see your messages in the browser.
Obviously, when you want to tail your logs within a file (within a terminal) this approach doesn't work well which is what the initial patch was trying to fix.
Now, the additional issue we face is that Log4PHP can have appenders to any kind of source so we should take that into consideration.

Considering the above I think it might be a good idea to try and let the user/sysadmin decide how he/she wants this module to behave. So I reckon providing a sane default with the option to customise would be the best of both worlds instead of hardcoding it as per my patch, or doing strip_tags on the message before inserting it as current code does.

I'll provide a patch soon, until then let me know if this approach makes any sense.

I was thinking that we can provide different log4php Layouts for this that will deal with formatting/stripping of the message.The user of the module would then only reference the relevant Layout in their log4php.xml file.

From what I can see custom modules can use $conf['log4php_config'] at hook_init() time (as long as they are loaded before log4php module) to alter that config during run time. I don't like globals like that but for the time being it works and (unfortunately) it is a Drupal thing so module developers will be aware of it.

Yes that should work. I'll try and do it this weekend, but I don't mind if you beat me to it :)

That was a looong weekend :)
Assigning to myself so I can take of it soon

Attached patch provides renderers that are Drupal aware. It also sets the default renderer to LoggerRendererDrupalPlainLocaleObject which will do what the patch in comment #4 did: log a localised version of the message without passing the message through format_string().

Oops I forgot to add the renderers to the patch. This one is the correct thing

Hey Erik,

I downloaded the stable build archive and it doesn't contain the includes directory
I think you might have merged the patch from #14rather than #15 which actually contains the renderer files.