Diagnostic block

Posted: Wed Aug 02, 2006 10:38 am

This topic is for developers or those involved in debugging PHP code in Nuke and not recommended for "production" sites.

As anyone who has spent time working with Nuke knows, trying to debug a problem can be very difficult. Index.php calls mainfile which calls nukesentinel which returns to mainfile which calls header and then calls footer etc. etc. etc. (That's not an actual sequence but an example). Trying to figure out where a problem occurs and then pinpoint the problem can be a hassle of major proportions.

When I started I would put an echo into the various programs (say near the top of nukesentinel.php I'd put "echo 'got to nukesentinel'); so I could trace the flow. Then I'd go down into the functions within and put in echoes, perhaps showing the name and value of certain suspect variables. These would generally echo out at the top of the page before any tables the theme output but there could be problems. For one thing in Forums you'd get a message about the browser not supporting frames, and in any screen that showed the security image the image would be suppressed by the echoed statements. So you couldn't switch easily back and forth between admin and non-admin users which is often needed in debugging.

One day recently an idea sprung into my head, why not create a diagnostics block. Then you could accumulate information throughout the various php programs that were executed and output them using Nuke's built in output functions. Here's the block I'm using now (I took the copyright out for display here):

Code:

<?php


if ( !defined('BLOCK_FILE') ) {


    Header("Location: ../index.php");


    die();


}


global $contentx, $contenty, $contentz;


$content = $contentx;


$content .= $contenty;


$content .= $contentz;


//echo $content;


// $content = "Here goes the content you want in your new block";





?>

The $contentx, $contenty and $contentz variables are accumulated in various programs in PHPNuke. I'm currently looking at issues in sentinel and mainfile but these can be changed or expanded at will. I'll be posting a separate topic about mainfile in the making nuke efficient area but here's a brief example of accumulating the information:

Code:

foreach ($_SESSION['config'] as $key => $value) {


      $contentz .= $key . '='. $value . '<br>';


   }

Once you have the block in your blocks directory you just go into admin and activate it. I've alternated between positioning it top left and center down depending on need.

I'm just running this in a totally test system right now so I display it to everyone, but I believe you could even have it just display to admins in a production system. A further refinement would be to set some kind of flag so that diagnostic variables were only accumulated when diagnostics was turned on.

registered · Site Admin Joined: Jun 04, 2004 Posts: 6437

Interesting. I was considering using something like Only registered users can see links on this board! Get registered or login! in the footer with a parameter so that admins could control this (of course, it would only display for admins).

Posted: Wed Aug 02, 2006 2:27 pm

Phpdebug looks interesting too. I was looking at one of the integrated editors that has debug functions but it requires a module to be installed on the server. In most shared server environments they are not going to do that for you.

Probably I should be using something more "meaningful" that $contentx, $contenty, $contentz as variables. For instance if collecting diagnostics on sentinel make them $sentinel_diags or if in mainfile $mainfile_diags or forums, $forum_diags or some convention like that.

Posted: Wed Aug 02, 2006 3:58 pm

Very interestng and very much needed!!
Perhaps this is more appropriate in the 'Developers' forum but I'm not sure that has open access if you're looking for feedback from 'the community'.

I'm looking forward to where you go with this fkelly.

Posted: Wed Aug 02, 2006 4:23 pm

As an aside, I think I have some script or other somewhere last lists al the functions and variables of a script it is used against and the files which specific functions are called in.

Posted: Wed Aug 02, 2006 5:13 pm

I was looking for feedback from the community and I stuck in the "disclaimer" part to kind of warn non-developers off. If that's not a good approach just let me know.

I get the impression that sessions is very much dependent on individual environments or maybe that it used to be and isn't any more. At any rate I was hoping that a few people with test environments could try this out and let me know their results and also that there might be folks who have been down this path before who could contribute. I have no aspirations to reinvent the wheel or repeat any one else's mistakes. I'm too old for that. Smile

Posted: Wed Aug 02, 2006 5:20 pm

Your idea regarding sessions has certainly got me intrigued. I'm not sure how a 'session refresh' would work - for example if a user updated the account or forum profile dat, how the data held in the session would get refreshed (assuming the techique you outlined was used for that).
Please excuse the typo's, its a little hard to type whilst bouncing along in this thing.

Posted: Wed Aug 02, 2006 5:54 pm

Not sure what "thing" you are in. Smile

I think the basic idea of a session is that you establish a "session" with a particular web site when you log in (though you might not even have to log in for it) and all the information that's stored in session variables is saved until you end the session. There is a time out for a session, so if you leave the computer eventually it will end anyway. So, updating an account or forum profile wouldn't work immediately per se. However, if we were aware that we were using sessions we could update the session variable for the account (there might be multiple session variable for an account, or an array like I used for 'config') and that would work.

I used sessions in a couple of custom modules that I did and they coexist quite well with PHPnuke. I go back and forth between nuke and my modules all the time without any real difficulty and most of the security in my modules is controlled by session settings. I'm just not sure whether this is "generalizable".

Posted: Wed Aug 02, 2006 6:21 pm

I'm not aware of any issues using sessions on different servers or operating systems, though there may be some with different versions of PHP. Did you check php.net for details?

Posted: Wed Aug 02, 2006 7:38 pm

I read a lot of details on php.net and elsewhere. I'm not saying that I understood them all but I read them. Personally, on the systems I've used, it's worked very well but I was just concerned that it might not work for everyone and that's why I've "hedged" the way I have. I do have to do the session_start() that I stuck in mainfile but other than that the session variables have been there when I tested for them.

It goes without saying (maybe) that modifying mainfile affects everything in PHPNuke so I wanted to see if some others were willing to test under different conditions.

Posted: Wed Aug 02, 2006 7:44 pm

Understand. I didn't mean to imply that you hadn't researched it - just that you can sometimes get the benefit of the different conditions you mentioned by checking the comments there. It's amazing how much knowledge is in the comments!

Posted: Wed Aug 02, 2006 8:21 pm

fkelly I'd love to test this but sadly, I'm overdue for a rebuild on my Spamlist module and I still have that forum language monster to vanquish.

Posted: Thu Aug 03, 2006 7:28 am

Kguske: Yeah, I've been reading thru the comments and that's what gives me pause. I think this may be more related to the thread on speeding up mainfile and we are mixing the threads up somewhat. In that thread Montego suggested that I'd want to test the heck out of this and I agree. While sessions would seem to be a purely PHP (not operating system or web server related) phenomenon, the comments make me concerned that they may operate differently on different platforms.

And as to Guardians earlier comment, you can unset specific session variables or the whole session although I don't think that would be needed that often with the configuration type variables. If we ever stored user variables in a session then we'd definitely want to unset them when someone logged out and make sure they got reset when someone logged in.