My site is having PHP Version 5.4.11. I have installed boost, after that recent log entries is filled with "Only variables should be passed by reference" error.
"Only variables should be passed by reference in /homepages/ddd/xxxxxx/htdocs/sites/all/modules/boost/boost.module on line 4697."
But when i installed this locally there is no such issue. In my local machine the PHP Version 5.3.2-1ubuntu4.17.
Can any one tell me is this a version compatibility issue or not?
Thanks
Krishna
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | boost-strict-1907276.patch | 2.32 KB | mw4ll4c3 |
Comments
Comment #1
jjma commentedI'm having a similar issue with the same version. Any patches?
Jon
Comment #2
jjma commentedStill experiencing this issue on our sites. Any suggestions or patches?
regards,
Jon
Comment #3
Anonymous (not verified) commentedPHP variable reference errors appear quite frequently in all versions of boost (in my experience) it depends on the php.ini file and the settings for error_reporting E_STRICT, E_WARNING.
Boost is hooked in to try and cache the output of drupal, some modules (or core components of drupal) start output then return or return nothing, so boost is hooked into passing nothing. There's nothing that can really be done as the error fires and throws before any analysis can be carried out. Ill try and illustrate.
so we can't put anything in myFunc to tell us what is being called as the error has been thrown and the function aborted, plus backtracing only leads to a function in Drupal that we wouldn't be maintaining and that could produce valid output. One of the frequent triggers for this in the 7.x series is the httprl crawling mechanism on the status report page, the crawler is designed to be used by cron and produce no output to the browser and on the report page it does a diagnostic to see if it is locked which has no content but boost is hooked in afterwards (as it would need to be for a valid crawler) and so it always throws this error.
It's a very minor notification rather than a serious error that unfortunately is beyond the remit of boost to solve unless there was an additonal non referenced function put in in front of boost to check validity of the variable, but to my knowledge that cannot be done without referencing it and throwing an error - catch 22, though quite interesting.
Comment #4
jjma commentedThanks for the explaination. Would you recommend turning down the level of boost logging so watchdog isn't filled with the error notifications from boost?
Jon
Comment #5
Anonymous (not verified) commentedOnly if it is really bothering you :)
Comment #6
mw4ll4c3 commentedHere is an (ugly) patch to the parsing in boost_get_content_type() and boost_cache_css_js_files().
Array manipulators such as _pop and _shift are designed to act on a stored variable, receiving it by reference... as such they'll never stop complaining if you pass them a value without capturing it into one.
These specific warnings can be avoided by doing just that. Despite the obvious visual differences in the code, this patch performs the same (or equivalent) operations, in the same order.
The only notable change is the use of the list() construct, to capture the first value of arrays. This has only been done in places where only the first value is relevant, and the shifted array was being discarded immediately.
Comment #7
cparkner01 commentedAfter applying the patch I am getting the following:
Fatal error: Cannot redeclare boost_cache_css_js_files() (previously declared in /modules/boost/boost.module:4679) in /modules/boost/boost.module on line 4711
Would really love to get this patch to work as the errors are building up in watchdog fast
Comment #8
Anonymous (not verified) commentedI'd recommend manually adding the patch as it doesn't say which version it's against and your error appears to indicate that the function exists twice so probably some lines have been inserted.
Comment #9
cparkner01 commentednevermind I'm just dumb, got it working! awesome job thanks!
Comment #10
Anonymous (not verified) commentedIf running Apache then it would probably be more appropriate to set error_reporting in .htaccess as it's easier to switch from development to production, these pages may help with php_value in the file.
http://php.net/manual/en/configuration.changes.php
and
http://php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
Comment #11
mw4ll4c3 commentedPrevious patch still applies cleanly to the latest (November 19th) development release (6.x-1.21+3x-dev)
Haven't tested it against 6.x-1.21 itself but I suspect it's fine against that, too.
Comment #12
yan commentedThe path from #6 seems to do what is promised. I applied it manually to 6.x-1.21 and the error doesn't appear any more. I'm using PHP 5.5.
Comment #14
bgm commented@mw4ll4c3 : thanks for the patch! Tested & applied to 6.x-1.x.