Debug::log inconsistencies with Debug::dump

[Will Morgan]

I've been doing some work that requires debugging and it's really bothered me that the output of Debug::log doesn't expand or serialize its input, nor does it show where it's logging from like Debug::dump does.

Another gotcha is that all input is put in to debug.log, when it would be handy to log things in to separate files for different priorities.

Can I get a green light on the core team to put these improvements in a PR?

[Ingo Schommer]

Hey Will, sorry for the late response, busy time!

On 14/11/2013, at 2:50 pm, Will Morgan <ave...@gmail.com> wrote:

I've been doing some work that requires debugging and it's really bothered me that the output of Debug::log doesn't expand or serialize its input,

You mean Debug::log($myObject) doesn’t call __toString()? It should. It also shouldn’t call ViewableData->debug() IMHO,

I don’t like HTML formatting output at such a core level, when you don’t even know what the output writer will be yet.

nor does it show where it's logging from like Debug::dump does.

SS_Log::log() gets a backtrace by default, its up to the specific formatter to use that. SS_LogErrorFileFormatter does include the origin.

Another gotcha is that all input is put in to debug.log, when it would be handy to log things in to separate files for different priorities.

You can add different writer for different priorities: http://doc.silverstripe.org/framework/en/topics/error-handling

The underlying Zend_Log is pretty flexible there. What are you missing?

Can I get a green light on the core team to put these improvements in a PR?

Depends on what they are, maybe outline your approach here first? :)

@Cam, in case you’re listening in, do you have any input

on this regarding the capabilities of your logger bridge to Monolog?

Ingo

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/groups/opt_out.

[Cameron Spiers]

Hey Ingo and Will,

There is a bit of a distinction between logging in your app for the purposes of tracking errors etc in a live application, and logging that you do for the purposes of debugging during active development. But I think the ideal would be for your logging solution to handle both. So in keeping with that if you were going to use functionality offered in the default SS install, I recommend the use of the SS_Log::log method over the Debug::log method. Perhaps Debug::log should be phased out?

The idea behind the logger bridge was to enable support for PSR-3 loggers, and also to allow the capturing of errors thrown and triggered by SilverStripe through a consistent system. I like Zend Log and it is quite similar to Monolog, but Monolog in particular has support for many of the types of logging systems we use at Heyday, hence the solution.

Monolog has some good handlers for debugging during development, in particular the ChromePHPHandler, and the FirePHPHandler, which will send your logs to the browser using a header. This is obviously not for use in your production environment, so you can make these handlers enabled only when your site is in dev mode using the Except or Only conditionals in the Injector system. See "Advanced-style setup" https://github.com/camspiers/silverstripe-loggerbridge

Cam

--

Cameron Spiers Senior Developer

Ph. 04 831 5130   heyday.co.nz

Heyday is a digital agency based in Wellington, New Zealand. It employs 35 staff and drives the online presence of brands through insight, ideas, design, delivery and improvement. Clients include Weta, Meridian Energy, GIB, Ecoya, ANZ, Trilogy, Gallagher Group and Z Energy. Please visit our website for further information.