Home » Forums » Bugs

Test or Live Mode Prevents Proper Include in Template

Fri, 03/21/2008 - 22:18 — jmorant@cloud9l...

In dev mode all my templates include properly when using include file='some_file.tpl' inside of a .tpl file. When I switch to live or test mode only the template I call is accessed. None of the include file calls seem to be parsed.

There is no error I am just seeing a really messed up layout because the include usually contains my css files. Below is a really basic example. To demonstrate how little it takes for me to see this issue.

When you run the example you should see a page with text and a blue background in dev mode. In Test or Live mode you get a white background with text because neither of the includes are parsed. Please note that occasionally one of these includes does work on different pages and I can figure out for the life of my why. If you no one can reproduce this error I can setup a temporary server to help solve this issue as it is driving me nuts I am sure I am losing performance since these pages are not cached. This appears for me on Apache 2.2.4 to the current running PHP 5.2.2 to the current on both Fedora and Ubuntu so it is not isolated to a specific setup with the latest Smarty and Pear library patched into Zoop.

In general staying in dev mode works since I handle most errors with a try catch block and a clean display, but in the end I do not want random bad input allowing users to see the debug display (which btw is very helpful).

-- Begin header.tpl ---

<html>
<head>
<title>Test Page</title>
<style>
body {
 background:blue;
}
</style>
</head>

--- End header.tpl ---

--- Begin body.tpl ---

{include file='header.tpl'}
<body>
Test Page
</body>
{include file='footer.tpl'}

--- End body.tpl ---

--- Begin footer.tpl ---

</html>

--- End footer.tpl ---

‹ Zoop Does Not Set Secure Attribute for Cookie Over HTTPS

{literal}

Submitted by john on Fri, 03/21/2008 - 22:27.

try adding {literal} to the header.tpl, like so:

<html>
<head>
<title>Test Page</title>
<style>
{literal}
body {
background:blue;
}
{/literal}
</style>
</head>

Though it doesn't make sense that this behavior would be different in 'test' vs. 'dev'

No Luck

Submitted by jmorant@cloud9l... on Mon, 03/31/2008 - 17:29.

Adding the literal does resolve the syntax error that would occur but does not solve the cache issue. Please note the {literal} smarty tag was present in my original test I just forgot to add it to the comment when typing it in the post. It is also important to note that I am not getting any errors in Live mode the includes just seem to be ignored as if they are not present. All other smarty tags process in the .tpl file just not the includes. This leads me to believe it is a cache issue which my be related to the file path, because reverting back to dev mode yields correct results with out changing any code.

Another thought, if the error log code is generating an error before it is written I would not being seeing any errors correct? Is there a way to write errors to the screen in Live mode the way dev mode does to check this case?

bug in error.php

Submitted by john on Mon, 03/31/2008 - 18:23.

I found some bugs in error.php. If you get the latest zoop from the svn repository, they are fixed. After you do so, you can define("LOG_FILE", "php://output"); to display errors in live mode.

The bug obscured errors in live mode, so that they were neither logged nor reported. Errors are now always logged in test and live mode, and you can define a global variable:$silentErrors = array('Warning'); to not display certain types of errors. This is probably not the method we will settle on to hide errors, but I put it in there as a temporary measure.

I apologize for the difficulty. Using the methods above, you should be able to determine what's going wrong with these include tags. Let us know how it goes.

Zoop 1.2 Errors

Submitted by jmorant@cloud9l... on Thu, 04/03/2008 - 22:45.

I got the errors from Zoop 1.2 to output to the log file. I fixed one of the errors by hand and got the errors to output correctly. Below is what I get when I access a single page. Please note that these errors repeat many, many times on a single page access. I can only assume that they do not show up in the dev mode because the error level is not set to Strict. These appear to be coming from not only Zoop, but also the Pear libraries. I have tried the packaged Zoop Pear Libraries and the newest Pear libraries, but neither of these make a difference. Can I make live or test mode not run in error level Strict to maybe alleviate these?
Error #10.47f55b9717016:

Unknown "Non-static method database::makeDSN() should not be called statically" in file /www/zoop/db/mysqli.php (on line 19)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b9717306:

Unknown "Non-static method DB::connect() should not be called statically, assuming $this from incompatible context" in file /www/zoop/db/database.php (on line 63)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b971748e:

Unknown "Non-static method DB::parseDSN() should not be called statically, assuming $this from incompatible context" in file /usr/share/php/DB.php (on line 520)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b9717779:

Unknown "Non-static method DB::isError() should not be called statically, assuming $this from incompatible context" in file /usr/share/php/DB.php (on line 551)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b9717916:

Unknown "is_a(): Deprecated. Please use the instanceof operator" in file /usr/share/php/DB.php (on line 594)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b9717e6e:

Unknown "Non-static method DB::isError() should not be called statically, assuming $this from incompatible context" in file /usr/share/php/DB.php (on line 557)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b9718019:

Unknown "is_a(): Deprecated. Please use the instanceof operator" in file /usr/share/php/DB.php (on line 594)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"
Show Details

Time Thu, 03 Apr 2008 16:35:03 -0600
Error #10.47f55b97181b4:

Unknown "Non-static method DB::isError() should not be called statically, assuming $this from incompatible context" in file /www/zoop/db/database.php (on line 64)
URL: "https://192.168.2.10/admin/index.php/tasks/Totals"

app/error.php

Submitted by john on Mon, 04/07/2008 - 16:00.

This is what's in the svn repo:

http://svn.zoopframework.com/filedetails.php?repname=Zoop+Repository&pat...

in function error_live_handler

    if($type == 'Unknown')
        return;
    //This error occurs a lot in PEAR classes.
    if($type == 'Strict' && $errstr == 'Assigning the return value of new by reference is deprecated')
        return;

At the moment, the zoop error handler doesn't respect your ini's error_reporting setting. Instead it reports all errors. This is probably a high-priority fix. You can use the above to avoid this problem in your own app, as a temporary fix.

error.php

Submitted by john on Mon, 04/07/2008 - 18:02.

I added a function, ignore_error($errno, $errstr), that takes error constants as it's first parameter, and some fragment of an error string as it's second parameter. Zoop will then ignore errors that match that description.

Zoop also now respects the error_reporting level set in .ini, or with the error_reporting() function.

Any error that is ignored using the previous two methods will not be logged, and no message will be displayed.

Zoop previously was setting error_reporting(E_ALL) itself, but will not do so in the future.

These changes are now committed in svn.

The fix worked!

Submitted by jmorant@cloud9l... on Mon, 04/07/2008 - 18:23.

Thank you so much for the fix! Now the caching problem is gone and I am rolling in LIVE mode finally. I applied the temporary fix to my 1.2 Zoop app/errors.php to get it working. My log file is also down to 0 errors so they were all being generate by the pear libraries and the strict logging level.