Re: [Xoops-development] addressing "blank page" problem

[R. M. v. D. <mv...@ca...>]

Sounds good.  I have been playing around with this on another small
project I'm working on and it works pretty nicely.  PHP also allows you
to override the 'exit' function (register_shutdown_function).  What I've
done is have 'trigger_error' log the error message into a static array,
then when the script ends (perhaps due to an 'exit'), then the error
messages are appended to the output.

One problem with this:

It is nice to be able to provide users with the option of leaving
debugging on or off as desired on a production site.  But if debugging is
turned off, then it really doesn't help people with the 'blank page'
problem.  If debugging is *on* then all notices/warnings etc. will also be
displayed.

Perhaps we can turn on debugging by default during installation.  Then on
the admin pages we can have a big red box that says 'Warning: you have
debugging enabled which is a potential security risk.  Please turn it off
when your site is opened to visitors.'  That way the admin user gets to
see all the messages as the site is set up and can turn them off when
ready.

Or perhaps another alternative... leave the error handler *always* on.  If
the user is the admin user, then show the messages, otherwise do not show
them.  This does not allow debugging of problems which occur only for e.g.
anonymous users though.

Or maybe this:  Leave the error handler always ON.  If debug mode is on,
show all errors and warnings (native PHP messages AND explicitly
'triggered' messages).  If debug mode is off, show only 'triggered'
messages.  If we use trigger_error very sparingly (or E_USER_ERROR for
errors-to-be-displayed) then the end user will only see a message if
something goes very wrong (e.g. can't connect to database), which may be
useful to alert the site administrator.  (In a custom error handler you
can strip out any path info so this is not a security risk.)

Any other thoughts on this?

Regards,
Mike



On Thu, 10 Jul 2003, K. Ono wrote:

> I agree that Xoops needs a centralized mechanism for handling errors.
> Using the trigger_error/set_error_handler functions seem to be the way to
> go.
>
> - Kazu
>
> ----- Original Message -----
> From: "R. Michael van Dam" <mv...@ca...>
> To: <xoo...@li...>
> Sent: Thursday, July 10, 2003 2:07 AM
> Subject: [Xoops-development] addressing "blank page" problem
>
>
> >
> > Greetings,
> >
> > There has been a huge flurry of "blank page" posts on the forums in the
> > past few months.  I think we should do something about this... i.e. try
> > and give a meaningful message instead of just the script failing.
> >
> > For example, in include/common.php... if the DatabaseFactory returns
> > 'false', I think we should explicitly print an error and halt the script.
> > (Even if the install goes perfectly, the database setup can change or the
> > database can fail to restart when a machine is rebooted.)
> > Otherwise people get the problem of 'call to a member of a non-object'
> > later on which doesn't really identify the problem (for a non-programmer).
> >
> > I was about to add (after XoopsDatabaseFactory::get()) :
> >
> > if (false === $xoopsDB) {
> >   echo "ERROR: Could not connect to database.  Please check your settings
> > in mainfile.php";
> >   exit;
> > }
> >
> > But it seems like maybe xoops could benefit from a centralized mechanism
> > for doing this.  Perhaps we can provide a custom error handler
> > (set_error_handler) and use trigger_error?  Or maybe the 'echo/exit'
> > combination is good enough?
> >
> > Database failure seems to be the most common cause of the blank page
> > problem... I'm not sure if we can catch many others... some are due to
> > corrupt files (resulting in parse error or undefined function, which I
> > don't think we can 'catch' with a custom error handler)...
> >
> > Any suggestions on the best way to do this?
> >
> > Best regards,
> >
> > Mike
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps
> _______________________________________________
> Xoops-development mailing list
> Xoo...@li...
> https://lists.sourceforge.net/lists/listinfo/xoops-development
>
>