Output buffer works on localhost but...

gmdavis

I have a script that I finally got to work flawlessly on my local machine. When I try to run it on my remote hosting server, I used get an error (something about exceeding 2 seconds). Now after tweaking, I just get a browser time out (progress?).

Can anyone tell me what variables might cause this? I compared the phpinfo page for both and I couldn't see anythin obvious. Except output_buffering said no value on the remote host but 0 on the localhost.

The local host is running PHP4.1.2 on Mac OS X with Apache/1.3.26.

The remote host is running PHP4.2.3 on i686, i386-redhat-linux-gnu with Apache/1.3.27

Below is the script. It allows me to include links in pages so each of the include files can be updated manually without refreshing the entire page (some of my scripts take a while to gather information and display a page). This is my workaround. I display a staic html page unless the user (or robot) requests an update.

<?
/*
function takes a filename without extension 
and evaluates the .PHP version, saving it 
to a parsed .HTM version
*/
function update($update) {

//put the file into a string for eval
$filestring = implode ('', file("$update.php"));

//parse a mixed PHP/HTML string (derived from user notes at PHP.net "eval")
ob_start();
eval("?>" . $filestring . "<?php ");
$output = ob_get_contents();
ob_end_clean();

$filename = "$update.htm";
$somecontent = "$output";

// The file will be overwritten. if file doesn't exist, create it.
if (!$handle = fopen($filename, 'w')) {
     print "Cannot open file ($filename)";
     exit;
}

// Write $somecontent to our opened file.
if (!fwrite($handle, $somecontent)) {
    print "Cannot write to file ($filename)";
    exit;
}

fclose($handle);

}
?>

<?
//include this code to call the function from a URL query "?refresh=something
if (isset($refresh)){update("$refresh");}
?>

Weedpacket

What it sounds like is that your host has the maximum script execution time turned way down (the default, and hence the probable value you have on localhost, is 30 seconds, not 2).

See if they've disabled set_time_limit() or not by (a) reverting to the version that throws a timeout error, and (b) putting a set_time_limit(30) at the top. If they have, you'll get a complaint about set_time_limit being an undefined function; in which case the problem is to find a faster way to do the job 🙁.

PS. I'm slightly worried about how you're opening the output file. If it works, fine - it's just that I've never seen "!$foo = bar" before, and ! has higher precedence than =, which means that (if PHP's precedence rules are to be beleived), it would be evaluated as "(!$foo) = bar" which is just silly. Safer is "!($foo=bar)" or better "($foo=bar)===false".

matt_4013

PHP's precedence rules aren't to be believed 😉 We had a huge discussion (argument) about this in the freenode #php irc channel. I use that method all the time, and I've never had it fail, and that struck all of us as strange, after they explained to me the problem with using it. However, it DOES work, so, who knows? 😉

suntra

I find this very strange...

eval("?>" . $filestring . "<?php ");

Why not simply use echo or print ?

echo $filestring;
// or
print $filestring;

Weedpacket

Because they won't evaluate the contents of $filestring.

Hmm.. curious. I'm getting odd behaviour myself now.

<?php
$thingy='foo';
$filestring = 'This string uses some <?php echo $thingy?>';

echo $filestring;
echo "<br>";
eval('?>'.$filestring.'<?php');

echo "<br>This doesn't.";

?>

Gives me a parse error, but

<?php
$thingy='foo';
$filestring = 'This string uses some <?php echo $thingy?>';

echo $filestring;
echo "<br>";
eval('?>'.$filestring);

echo "<br>This doesn't.";

?>

Doesn't.

gmdavis

The manual page for "eval" has a lot of comments about whether "<?php" is required at the end of a eval argument. Early posts do not have it. Later posts claim this is wrong and you need it.

Including it makes some sense to me (but that stretches the limits of my understanding). I never tried it on my remote host without "<?php". but I'll try it and see.

It'll kill me if this is a different behavior on the local and remote hosts.

UPDATE: AARRGH!!! that fixed it on the remote host.

Damn "cross-platform" PHP!