-3

Why is recommended use ob_start() in PHP language when you need include other PHP (or template) file?

This is bad:

require_once( dirname( __DIR__ ) . '/views/file.php' );

This is good:

ob_start();
require_once( dirname( __DIR__ ) . '/views/file.php' );
$output = ob_get_clean();
return $output;

But i don't get why

lolalola
  • 3,773
  • 20
  • 60
  • 96
  • Because if you don't do it you will post a question here and it would get closed with: http://stackoverflow.com/q/8028957/3933332 – Rizier123 Jun 24 '15 at 18:09
  • It sounds like it is because the output buffering prevents any headers from being sent prematurely in the file that you are including with `require_once`. – Alex W Jun 24 '15 at 18:13
  • 1
    Who's recommending this? It's sometimes a **hacky** workaround to `output already started` errors with things like `header()` calls, but it's rarely *recommended* as the better approach is fixing the errors in a *sensible* way. – ceejayoz Jun 24 '15 at 18:15
  • 1
    _“This is bad: […]”_ – no, it is not. Without further context, your question doesn’t make any sense. – CBroe Jun 24 '15 at 18:16
  • However, if the script you are including generates output directly, and you want to catch that output in a variable (as your second example shows) – then output buffering is a way to do that, yes. – CBroe Jun 24 '15 at 18:17

3 Answers3

2

There is no such recommendation, use it if you think its necessary.

ob_start() tells PHP to start buffering output, any echo or other output by any means will be buffered instead of sent straight to the client.

This can be used for many purposes, one of them is being able to send headers even after producing output, since the output wasn't sent yet thanks to buffering.

In this particular piece of code you have, you are using output buffer to catch the output generated by your included file and storing it to a variable, instead of sending it to the client.

Havenard
  • 27,022
  • 5
  • 36
  • 62
2

It would be hard to say without understanding a little more about your program, as well as who is telling you to do this. For one thing, the return $output line at the bottom--what are you returning from?

I can think of many reasons you'd want to include scripts this way.

In PHP, the ob_* functions deal with output buffering, that is, capturing anything that gets printed to the page/screen your PHP code is running in as a string.

This may be necessary because a very common pattern in classic PHP is to write straight HTML outside of any <?php tags. When you output text this way, it gets sent directly to the screen, bypassing any intermediate processing that you may want to do with it. It's also possible that a programmer may want to define all of their includes in one place, so that they can be switched out easily, and then reference the text to be output as a variable later in the script.

It may also be a way to prevent includes that don't output any text from accidentally outputting white space, making it impossible to change headers later on in the script. I've had problems before with a large code base in which every include had been religiously closed with a ?> and may or may not have included white space afterward. This would have solved the problem with comparatively little effort.

In programming, there are often many different ways to do things, and there's not always one of them that's "right." The end goal is to create something that does its job, is maintainable, and can be comprehended by other programmers. If you have to write a couple of extra lines of code in pursuit of maintainability, it's worth it down the line.

1

ob_start() is a function that enables output buffering, ob_get_clean(); flushes the buffer, and it looks like you are returning it from a function.

This allows any print or echo statements to be added to the buffer, and then all stored to a variable and returned and printed elsewhere in your application.

Patrick Murphy
  • 2,311
  • 14
  • 17