[SOLVED] include file, but not outloud...

[aximbigfan]

Hi all,

 

I made an app that need to check if the file included has certain variables in it. But, the problem here is that if the file has like "echo "test";" in it, then "test" gets output onto the HTML. Anyway to include the fiel so that variables can be checked, but that echos, or plain text (ie, out of php tags) will not?

 

Chris

[resago]

don't echo it. :-\

[KrisNz]

Or, if thats not an option, use output buffering.

[haku]

Don't use output buffering - its sloppy coding that slows things down for the user.

 

Rather than echoing "test" in the file, set $something = "test", then on pages that need to output test, use echo $something after the include statement.

 

Either that or you can build in a conditional check to see what the current page name is. If the current page name is the file that you DONT want to echo test in, then don't echo test. If its any other page, then echo test.

[aximbigfan]

The reason why the variables need to be checked, is that the php app has a configuration file, and the user can upload a new configuration file. The problem comes in with I can't control what is in the user supplied config file.

 

Basically, I just want to read the variables and thats it, no output.

 

Chris

[KrisNz]

...Which is why you should use output buffering.

 

It's as simple as

<?php
ob_start();
include("user_file.php");
ob_end_clean();

if (isset($user_var)) { 
//....
}
?>

 

Perhaps a better alternative, would be to check the uploaded file at the time its uploaded for the required variables, and reject it with a message to the user as to why its unacceptable.

[aximbigfan]

Well, I stayed way from it when the other user said to, but this works, thanks!

 

Topic solved...

 

Chris

[haku]

It may be your only solution in this case when you have no control over the files that are being included. But if you can get access to the template by which those files are being written somehow, taking the echo statements out of them would be a better option. output_buffering slows things down. What it does is store everything in memory until it hits ob_flush(), which means the user doesn't get a constant stream of input, but rather has to wait until the script has finished buffering. This slows down your site, sometimes significantly.

[KrisNz]

Do you have a benchmark or an example/article that demonstrates this please?

[haku]

From php.ini

 

Output buffering allows you to send header lines (including cookies)

; even after you send body content, in the price of slowing PHP's

; output layer a bit.

 

From php.net:

 

This function will turn output buffering on. While output buffering is active no output is sent from the script (other than headers), instead the output is stored in an internal buffer.

 

Its right there in the name - output buffering. It buffers the output.

[KrisNz]

Not really, theres some ambiguity in that since it states earlier in the file

 

; - output_buffering = 4096        [Performance]

;    Set a 4KB output buffer.  Enabling output buffering typically results in less

;    writes, and sometimes less packets sent on the wire, which can often lead to

;    better performance.  The gain this directive actually yields greatly depends

;    on which Web server you're working with, and what kind of scripts you're using.

 

Plus the default setting for php is to have buffering on with a max of 4k of data, essentially spitting things out in 4k chunks.

 

I'll also quote this from another thread

http://www.dynamicdrive.com/forums/archive/index.php/t-11082.html

 

[using output buffering] You don't want to do that unless you have to. It will slow down the script.I would disagree with that statement for three reasons (though it's not necessarily an exhaustive list):

 

 

By buffering data, the preprocessor can send data to the server in large segments, rather than piecemeal.

Output buffering allows filters to be applied that might not otherwise be possible. An obvious example is compression. Though it's not necessary to compress output, the benefits typically outweigh any possible performance penalty.

Output buffering provides the opportunity for the script to determine the content length and set the corresponding Content-Length header. Without this header, the connection must be closed in order to signal the end of the entity. Any further requests must establish another connection, rather than using persistent connections defined by HTTP/1.1.

 

If anything, the use of output buffering should be common practice, not something to avoid. In fact, output buffering is enabled by default in the recommended configuration to accumulate writes into 4kB chunks.

 

Also this

http://www.ipbwiki.com/Practical_PHP_Programming:Output_buffering_performance_considerations

and this

http://www.linuxformat.co.uk/wiki/index.php/PHP_-_Output_buffering

 

Those articles suggest that performance depends on compression, and the content you're compressing but theres no suggestion that it will grind your server to a halt.

 

It's all interesting stuff anyways...