XF 2.0 debug: best practices for displaying variables (console log, file system or xf_admin_log for crons ...)

Marcus

Well-known member
Is there a best practice for displaying variables when writing an addon?

1. If I write a cron, what is the preferred debug method? Writing to the admin log? Or to a file system, is that possible?

2. For functions like preSave(), is it best to show the output in the browser console log? Is there an xf function to do that?

Or do you recommend xdebug or another external tool ? What do you use for debugging?
 
There are \XF::dump($variable) and \XF::dumpSimple($variable) at your hand. When you run a cron job manually, those two will deliver their output to the result page pf the cron execution. As long as you're not doing ajax stuff, they will also work perfectly fine in places like preSave()-functuions, etc. If ajax comes in, I stick with phps var_dump($variable), that will throw the stuff into the browser console as XF is not able to parse the reply.
 
I wrote
\XF::dump($featuredThread); to my add-on service function but I got error in console.

'PHP: <script> Sfdump = window.Sfdump || (function (doc) { var refStyle = doc.createElement('style'), rxEsc = '
 
The dump functions mentioned are generally designed for an HTML output context.

As mentioned, if using an Ajax response and looking at the console, you need a text-oriented dump function, like the default PHP tools (var_dump, print_r, etc).
 
@pangamma, yes1. If that's not possible - you can use remote debugging, but I don't recommend doing that kind of thing unless there's a really good reason.
 
\XF::logError('my error here') will write to the xf error log which you can view in the admin panel. You should use this whenever possible. XF logs Exceptions there too, so it takes care of pretty much everything.

As for var dumps, if you're not comfortable with using an IDE or xDebug or what have you, you can dump to the screen, which is also visible in ajax requests (just look at the ajax response in the browser's dev tools).

However it's actually more comfortable to dump to a text file and view it in the browser, e.g. file_put_contents('my_error_text_file.txt', print_r($var, true), FILE_APPEND)

If you're debugging production sites, it's even more important to dump to a text file so as not to output to the screen for all the world to see. Or, condition the screen dump with a cookie, e.g. if ( !empty($_COOKIE['viewable_only_by_me']) ) then print_r(.....), or limit it to your IP address etc.
 
Top Bottom