Fatal Errors in Subtemplate only lead to blank page

Hi,

I build a site based on modules which are loaded on various tbs-events. It's like

Index.php with tbs loads Main Template -> in various sections there is [onshow;script=modules.php;subtpl] with parameters -> modules.php generates new [onshow;script=<some module>.php;subtpl] according to the parameters passed, every loaded module loads in subtemplate-mode it's own template and merges it with data. Works perfectly, except that if I mess something up in the code, eg. a syntax-error, the page remains simply blank and no error shows up. This makes it often really tricky to debug, because a) I don't know which module caused the error and b) intensive work makes blind to obvious mistakes. I suppose this has to do with the subtemplate-mode, is it a tbs-behaviour that fatal errors in subtemplates just lead to blank pages and do not show errors? Because if the error is thrown from my database object for example, even if it happened in a subtemplate, it shows me the error as supposed (it's a simple errormessage output through echo and then die() in a global session-object). Is there a way to make tbs show me the fatal errors that happen in my subtpl-scripts?

Thanks
Rudy  

I think I found the cause, in function meth_Misc_RunSubscript TBS uses @include... this of course causes PHP to ignore any error within the included script. Why is @include needed and not simply include? I'm sure there are some thoughts behind this... are there any side-effects without suppressing the errors, or can I change that without worries?

Ok, right now I'm working with the changed version with include instead of @include. As of now, I didn't encounter any problems. But... I discovered MANY warnings, notices and such, things I didn't see with suppressed errors. It cost me a few hours going through all this. I don't blame TBS of course, this were my errors and TBS is still the best choice I made for this project, but I would hardly recommend to change the way subscripts are included to a way that errors and, depending on the error_reporting setting of course, warnings and notices show up. This would make development easier and resulting applications more secure. An error you don't see you haven't made... at least you think :)

regards

hi Rudy,

> a syntax-error, the page remains simply blank and no error shows up

In sub-template mode, the usual output is redirected into a buffer (see ob_start() or "output buffering" at the PHP manua). Thus, if any PHP fatal error occurs, then no message can be displayed.
I don't know any PHP feature to walk around this.

Hi Skrol29, thanks for answering.

But the problem is not the output-buffering (which I'm familiar with since I use it a lot), but the suppressed errors with @include which you use in function meth_Misc_RunSubscript().  With @include you don't see notices, warnings and fatal errors that occure in included scripts, and a fatal errors lead to a blank page.

I propose trying to get rid of this "@". The only thing I see is that you check the return-value of this @include() - which returns false if the included script does not exist - in function meth_Locator_Replace and place your own TBS-Error-Message in case Parameter "noerr" is not set. You can achieve the same with first checking in function meth_Misc_RunScript() the existance of the file with file_exists, and use a regular include without the @ when the file is present. This would solve the odd behaviour.

Since I don't use subtpl for scripts that aren't physically present it didn't matter changing


to


But looking a bit deeper in the code I finally came up with the following, which preserves the "noerr" functionality of subtpl-Function without outputting a PHP-Error when a Subtemplate does not exists.


This runs fine, and I finally can see all warnings, notices and errors that happen in Subtemplates, no more blank pages. Hope you can use that, else I put that on my list to change with every update (a list that btw. doesn't exist yet :))

The other thing is that when there is a problem with the file (not existing, not a PHP script, ...) the PHP error message will not be helpful for the TBS user because the message complains about a TBS code line, while a TBS error message should be more relevant.