PHP bug with print_r($var,true) & output buffering callback handler
mikeytown2 - June 15, 2009 - 09:40
| Project: | Boost |
| Version: | 6.x-1.x-dev |
| Component: | PHP compatibility |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
| Issue tags: | documentation |
Description
If your page uses print_r, var_export, with the second parameter TRUE; it causes PHP to fail when used within an output buffering callback handler (like boost does).
Cannot use output buffering in output buffering display handlersPHP Bug
http://marc.info/?l=phpdoc&m=114122422804066&w=2
Alt Function
http://www.php.net/manual/en/function.print-r.php#75872
#1
I've just run into this too, after upgrading to 6.x-1.0-beta2.
If there's anything I can do to help, please ask.
Nigel
#2
Sadly this is a PHP bug. Current workaround is to define your own print_r() function. obsafe_print_r() is a ok alt (see links in first post).
#3
Sorry for my ignorance, but I'm still relatively new to Drupal and PHP.
Does that mean I have to look through all my modules and replace print_r with obsafe_print_r, and then put the obsafe_print_r function in something like includes/common.inc that's used everywhere?
Regards,
Nigel
#4
What does the error say exactly? Boost even uses a print_r(), so it only happens in special circumstances. Most peoples webpages do not display the raw output from an array.
#5
Hmm. I'm not getting it now. I'll report back if I see it again.
#6
It's only an error if you call a buffering function, like print_r($var, true), from within a buffer handling function, like _boost_ob_handler has been defined to be by ob_start('_boost_ob_handler). It's listed in the PHP manual too http://php.net/ob_start :- .
For now I've just changed, in my copy:-
RCS file: /cvs/drupal-contrib/contributions/modules/boost/boost.module,vretrieving revision 1.3.2.2.2.5.2.66
diff -r1.3.2.2.2.5.2.66 boost.module
476c476
< watchdog('boost', 'There are <strong>php errors</strong> on this page, preventing boost from caching. ERROR: <pre>%error</pre> !link <br /> !performance', array('%error' => print_r($error, TRUE), '!link' => l(t('Lookup Error Type'), 'http://php.net/errorfunc.constants'), '!performance' => l(t('Turn Off Error Checking'), 'admin/settings/performance')), WATCHDOG_WARNING);
---
> watchdog('boost', 'There are <strong>php errors</strong> on this page, preventing boost from caching. ERROR: <pre>%error</pre> !link <br /> !performance', array('%error' => 'Type: '. $error['type'] .', message: '. $error['message'] .' on '. $error['line'] .' in '. $error['file'], '!link' => l(t('Lookup Error Type'), 'http://php.net/errorfunc.constants'), '!performance' => l(t('Turn Off Error Checking'), 'admin/settings/performance')), WATCHDOG_WARNING);
#7
I should just add obsafe_print_r() to boost; call it boost_print_r(), that way if someone encounters this problem again they can replace print_r without adding in a new function.
#8
That would be good.
Would boost_print_t still work if the module was (temporarily) disabled?
#9
@NigelCunningham
sadly no, so it's not the best fix.
#10
Yeah, I've been bitten by this one, as well. Looks like the print_r() inside the error_get_last switch statement is causing PHP to choke. If you could add obsafe_print_r()/boost_print_r() that would be great.
Personally, I hate how print_r() interrupts the normal output flow anyway. It's caused me many issues over the past year or so I've programmed in PHP....
#11
Also, I noticed that in that very same error-checking switch statement that the E_NOTICE, E_USER_NOTICE, etc. cases are there, but commented out. I remember that in the original issue I posted regarding the error checking that they had been in there so that errors that don't show on the screen don't stop Boost from caching. Is there a reason they were removed?
#12
Please test this patch
#13
committed
#14
Automatically closed -- issue fixed for 2 weeks with no activity.