Ravens PHP Scripts: Forums
 

 

View next topic
View previous topic
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Blocks
Author Message
fkelly
Former Moderator in Good Standing


Joined: Aug 30, 2005
Posts: 3312
Location: near Albany NY

PostPosted: Wed Aug 02, 2006 10:38 am Reply with quote

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.
 
View user's profile Send private message Visit poster's website
kguske
Site Admin


Joined: Jun 04, 2004
Posts: 6383

PostPosted: Wed Aug 02, 2006 1:18 pm Reply with quote

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).

_________________
I google, therefore I exist...
Only registered users can see links on this board! Get registered or login!
 
View user's profile Send private message
fkelly
PostPosted: Wed Aug 02, 2006 2:27 pm Reply with quote

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.
 
Guardian2003
Site Admin


Joined: Aug 28, 2003
Posts: 6793
Location: Ha Noi, Viet Nam

PostPosted: Wed Aug 02, 2006 3:58 pm Reply with quote

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.
 
View user's profile Send private message Send e-mail
Guardian2003
PostPosted: Wed Aug 02, 2006 4:23 pm Reply with quote

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.
 
fkelly
PostPosted: Wed Aug 02, 2006 5:13 pm Reply with quote

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
 
Guardian2003
PostPosted: Wed Aug 02, 2006 5:20 pm Reply with quote

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.
 
fkelly
PostPosted: Wed Aug 02, 2006 5:54 pm Reply with quote

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".
 
kguske
PostPosted: Wed Aug 02, 2006 6:21 pm Reply with quote

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?
 
fkelly
PostPosted: Wed Aug 02, 2006 7:38 pm Reply with quote

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.
 
kguske
PostPosted: Wed Aug 02, 2006 7:44 pm Reply with quote

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!
 
Guardian2003
PostPosted: Wed Aug 02, 2006 8:21 pm Reply with quote

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.
 
fkelly
PostPosted: Thu Aug 03, 2006 7:28 am Reply with quote

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.
 
Display posts from previous:       
Post new topic   Reply to topic    Ravens PHP Scripts And Web Hosting Forum Index -> Blocks

View next topic
View previous topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2007 phpBB Group
All times are GMT - 6 Hours
 
Forums ©