Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

My php program is wrapped in ob_* function. #76

Open
kargnas opened this issue Jun 21, 2013 · 5 comments · May be fixed by #91
Open

My php program is wrapped in ob_* function. #76

kargnas opened this issue Jun 21, 2013 · 5 comments · May be fixed by #91

Comments

@kargnas
Copy link

kargnas commented Jun 21, 2013

PHP-Error using ob_* function. But my site use ob_*function, too.

I think many websites programmed like this, this issue is need to resolve.

@reFX-Mike
Copy link

Sample problem here. I use sessions and the whole website is wrapped into multiple ob_* functions that act as a quasi-macro-template engine.

After the script 'ends', the ob_functions get called in reverse order, adding required javascript etc. to the headers only when they are actually needed.

If I try to use phperror in this context, all I get is a blank-page, even when no error occurs.

@bitifet
Copy link

bitifet commented Nov 5, 2013

Maybe you can use ob_get_level() to determine how many buffering levels you are in and deconstruct it storing contents in a array stack with ob_get_clean().

Then write whatever you want to stdout and rebuild all buffering levels again walking above mentioned stack and executing ob_start() and echoing data per each stack level.

The problem is that, if the application needs to output any http header you already have initiated the document output and end up with a warning (and no header emitted at all).

Alternatively, you may store your output in some variable and render it at the really end of the script execution by custom shutdown function...

@reFX-Mike
Copy link

Are you suggesting I should re-write how my entire website works to accommodate phperror? Don't you think that's a little backwards?

I just tried to provide more detailed information, so it would aid in debugging the potential problem.

In my particular case, no headers OR content are send to the output until the VERY end, after the last ob_handler (the one that gz_compresses everything) is processed.

@bitifet
Copy link

bitifet commented Nov 6, 2013

No. I don't suggest anything.

I'm only provided a few ideas about how to address the problem. No matter where it is implemented.

Actually, I where thinking about defining the above mentioned shutdown function within php-error itself. Why not?

And, finally: I don't know who you are. You could be a developper interested in contributing to achieve the solution or a php-error active developper (which I'm not)

If you are offended because I tryed to help, I apologize for that. But I'm not too much worried... ;-)

@bullfrogchampion bullfrogchampion linked a pull request Oct 10, 2014 that will close this issue
@bullfrogchampion
Copy link

I know I'm a bit late to the party, but I've just submitted a pull request for this issue. Because this is only my second ever pull request, I didn't link it to this issue properly, but I think they should at least mention each other now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants