PHP bug with print_r($var,true) & output buffering callback handler

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

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

Hmm. I'm not getting it now. I'll report back if I see it again.

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 :- You can't even call functions using the output buffering functions like print_r($expression, true) or highlight_file($filename, true) from a callback function..

For now I've just changed, in my copy:-

RCS file: /cvs/drupal-contrib/contributions/modules/boost/boost.module,v
retrieving 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);

That would be good.

Would boost_print_t still work if the module was (temporarily) disabled?

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....

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?