[wp-hackers] ob_start - good or bad?

Otto otto at ottodestruct.com
Thu Apr 23 10:44:12 GMT 2009

Well, yes, okay, I didn't know about that reason. Seems like a PHP bug to me.

The general reason to avoid output buffering is that it buffers the
output. This seems stupidly obvious, but if your output is being saved
in a buffer until the end of the thing, then it's not being delivered
to the browser until the end of the process, all at once. Meaning that
your page doesn't appear to load gradually anymore, but the whole
thing has to run first, making it seem slower.

Now, if you're using it like you are, to capture only certain output
and prevent it from displaying, then ending the buffer, you don't have
this same problem. But output buffering in general is a poor solution.
You're basically taking something intended as output and putting it
into a string instead, so that you can presumably manipulate it. The
ideal solution in such a case is to rework something to give you the
string you want directly, not to work around it.

So usually, when there's no other way to do it except output
buffering, then you probably have a good argument for adding some new
functionality to the core code instead.

Caching plugins being a notable exception to this, of course.


On Thu, Apr 23, 2009 at 4:48 AM, Donncha O Caoimh <donncha at linux.ie> wrote:
> If you use ob_start() and wait until the end of the PHP process to collect
> the output and do something with it (like WP Super Cache and other caching
> plugins do) you have to be careful about using objects.
> The latest versions of PHP5 destroy objects during shutdown before all code
> has actually been run.
> I had to "pre cache" a few blog options earlier in the process (into global
> variables) to get around this. What's worse, is that this destroying of
> objects doesn't always happen, and different versions of PHP5 do different
> things. It's head wrecking.
> Donncha
> Simon Wheatley wrote:
>> On Thu, Apr 23, 2009 at 10:35 AM, Otto <otto at ottodestruct.com> wrote:
>>> Well, there's already a get_edit_post_link() function, so why not use
>>> that instead? Okay, so it doesn't return all the a href stuff, but
>>> that's easy to duplicate.
>> I hadn't spotted that when I looked at the edit_post_link function
>> somehow, thanks.. seems so obvious now I look again. :\
>>> In general, it's a bad idea to use output buffering unless there's no
>>> other way to do it. In the case of the given code, there's definitely
>>> another way to do it.
>> For the sake of my education (and accepting that get_edit_post_link is
>> available for this specific case), why is ob_start, etc,  a bad idea?
>> Thanks Otto.
>> S
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list