Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This issue attempts to correct various inconsistencies between function definitions where parameters are/are not called by reference. The 7.x patches have been committed. Most effort is currently being put into 6.x-2.x.
Examples of the fixes are:
- function init() in various views_handler* - The second parameter should not be by reference, remove & (9 fixes)
- function pre_render() in views_handler* - The parameter should be by reference, add & (5 fixes)
- options_validate(), options_submit(), value_validate(), value_submit(), exposed_validate() in views_handler* - The first parameter should not be by reference, remove & (10 fixes)
- options_validate() and options_submit() in views_plugin_row* - The first parameter should be by reference, add & (3 fixes)
Original:
Rolling a patch shortly to fix a bunch of E_STRICT notices using the latest CVS branch.
Comments
Comment #1
Dave ReidMostly fixes inconsistencies in function definitions between parent classes and child classes that need to be exactly the same.
Comment #2
Dave ReidUm, oops. Forgot to sign out of my test 'normal' account...
Comment #3
dawehnerSome of them broke some stuff
Comment #4
Dave ReidWith the patch I'm still seeing:
Strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with that of views_handler_filter::value_validate()
Strict warning: Declaration of views_handler_filter_node_status::operator_form() should be compatible with that of views_handler_filter::operator_form()
Strict warning: Declaration of views_handler_field_node_new_comments::pre_render() should be compatible with that of views_handler_field::pre_render()
Strict warning: Declaration of views_plugin_argument_validate_node::options_submit() should be compatible with that of views_plugin_argument_validate::options_submit()
Comment #5
dawehnerThis one tackles 1) and 2)
The other ones are very special.
Comment #6
dawehnerThanks for the work!
Comment #7
Dave ReidThese should likely be backported to 6.x-3.x wherever possible as well.
Comment #8
Dave ReidSo dereine, is the pre_render inconsistency still an issue then? Should we file a separate issue for that one?
Comment #9
dawehnerLet's open a new issue: here is one #894274: E_STRICT pre_render
Comment #10
Letharion CreditAttribution: Letharion commentedFollowing the line of connected issues, I get the impression that this has been fixed. Closing.
Comment #12
dawehnerNo this wasn't ported yet.
Comment #13
mikeytown2 CreditAttribution: mikeytown2 commentedSubscribe from #1223996: Strict warning: Declaration of * should be compatible with that of views_handler::*
Comment #14
mikeytown2 CreditAttribution: mikeytown2 commentedWe should standardize the usage of the ampersand. Here is a patch for 6.x-2.x. Will work on one for 6.x.-3.x. I got smart and searched the code base for the inconsistencies in function definitions, rather than waiting for another error to popup.
Comment #15
mikeytown2 CreditAttribution: mikeytown2 commentedStill missed one due to
function init(&$view, &$options) {
VSfunction init(&$view, &$data) {
Comment #16
mikeytown2 CreditAttribution: mikeytown2 commentedOne thing that had to change was
3.x
2.x
Reason has to do with views/handlers/views_handler_sort.inc
Comment #17
mikeytown2 CreditAttribution: mikeytown2 commentedFound another one
Strict warning: Declaration of views_handler_filter_user_name::value_submit() should be compatible with that of views_handler_filter_in_operator::value_submit() in views_include_handler()
Comment #18
killua99 CreditAttribution: killua99 commentedTake a look to this "patch"
Comment #19
sunI tried the patch in #17 for 6.x-3.x, but I'm still getting lots of PHP Strict warnings when running tests.
Comment #20
dawehnerThere are definitive a ton of problems which were caused by d7 only patches/changes in other d7 only patches.
Comment #21
mikeytown2 CreditAttribution: mikeytown2 commented@sun
Can you provide more info on what bits of code is throwing the strict warnings in your case?
Comment #22
patricksettle CreditAttribution: patricksettle commentedUpdated patch for d6-2.x. Includes some additional E_STRICT declaration notices. Still need to go through and check to see if these are required in 3.x.
Comment #23
patricksettle CreditAttribution: patricksettle commented@sun
Some of the strict warnings may be related to this ticket: http://drupal.org/node/465332
Which was set as "won't fix" by merlinofchaos due to php4 compatibility issues.
Comment #24
apotek CreditAttribution: apotek commentedSo it looks like none of these patches are in 6.x-3.x yet.
I'm still getting tons of strict notices. Of course, you can turn these off, but this is my development box, and these kinds of notices are very *germane* (ie, inconsistent declarations are clear pathways for bugs to appear.
Can we say 6.x-3.x should drop PHP 4 support and commit these?
Comment #25
developer_426 CreditAttribution: developer_426 commentedHi there,
How to use the patch file for avoiding strict warning issues as i am getting such warning while using flag friend with views.
Thanks,
Comment #26
dawehnerLet's ignore this scope changing.
@developer_426: For specific issues please create a new issue, with the error :)
Comment #27
patricksettle CreditAttribution: patricksettle commentedAnother updated patch for d6-2.x.
Has anyone gotten a chance to look at 3.x for this?
Comment #28
patricksettle CreditAttribution: patricksettle commentedCleaned out some whitespace changes, and added fix for pre_render compatibility for 2.x patch.
Comment #29
monil-dupe CreditAttribution: monil-dupe commentedThanks hyrcan for this patch.
Comment #30
apotek CreditAttribution: apotek commented@hyrcan, thanks for the 6x-2x patch. I changed the status of the issue back to "needs review" so your patch can be tested. If it passes the tests, I'll try to roll one for 6.x-3.x based on it.
Comment #32
OlafskiHi,
thanks for the patch #28. I applied that one plus #11 of #465332: Strict warning: non-static method view::load() should not be called statically, and all warnings went away, except the following one, which was not mentioned yet:
strict warning: Declaration of content_handler_field_multiple::pre_render() should be compatible with views_handler_field::pre_render(&$values) in MY-DRUPAL-SITE/sites/all/modules/cck/includes/views/handlers/content_handler_field_multiple.inc on line 322.
Views version is 6.x-2.16.
EDIT: Sorry, maybe I was too fast. The above mentioned message disappeared after the next page load, I guess that was a cache issue (otherwise I'll keep you informed).
Comment #33
OlafskiAddendum to #32: Unfortunately I was not too fast: The mentioned warning still appears.
Does anyone know if that message is a serious issue? I'm trying to clarify PHP
5.35.4 issues in a test environment before switching the PHP version at the live site.Comment #34
merlinofchaos CreditAttribution: merlinofchaos commented#32: The error you see is in CCK module, not Views, so you'll want to pursue it there. The error is probably not going to affect functionality, so it is merely annoying.
Comment #35
carillpower CreditAttribution: carillpower commented#28: views-893128-28-d6-2x.patch queued for re-testing.
Comment #36
inky@inky3d.com CreditAttribution: inky@inky3d.com commentedIs there any chance there will be a patch for 6.3x?
A hosting company that has a number of Drupal6 sites is forcing an upgrade to PHP 5.4 later this year, and views breaks completely when this is enabled. It's not just a matter of error messages, it causes blank sections where a views page/block should be.
Comment #37
dawehnerWell, I don't have an answer how to solve the php < 5 problem. mhhh
Comment #38
dawehnerWell, I don't have an answer how to solve the php < 5 problem. mhhh can you please describe what else than the strict notices described in the patch are problematic?
Comment #39
steinmb CreditAttribution: steinmb commentedCould we branch create a 4.x branch that not support PHP 4.x?
Comment #40
Letharion CreditAttribution: Letharion commentedNo one is likely to start a new branch for D6 at this stage. PHP4 goes out soon anyway since D8 is coming out and D6 will loose support.
Comment #41
mattwmc CreditAttribution: mattwmc commentedIs it possible one fix is still missing?
Updated: And getting these:
Comment #42
mikeytown2 CreditAttribution: mikeytown2 commented@mattwmc
I would post an issue in the uuid module
Comment #43
mattwmc CreditAttribution: mattwmc commentedThanks for the reply.
Will do and I've been getting others since upgrading to php 5.4 but managed to fix some of them myself.
Comment #44
zionduc CreditAttribution: zionduc commentedI'v applied the #27 patch (just like they do in OpenAtrium 1.x file: openatrium.make-php-strict) but after this patch I got an extra error message:
So I'v created an other little patch for this issue.
I hope this helps for others.
Comment #45
joelpittet@zionduc thanks for that patch, i moved it over to it's own issue because it should be easily fixed without affecting PHP4
#2075561: views_handler_filter_user_name::exposed_validate() form variable shouldn't be a reference variable.
Comment #46
PetarB CreditAttribution: PetarB commentedCould someone just post a ZIP of the patched files? I find it difficult to patch anything but the most simplest of amendments, since I have to do it by hand.
Comment #47
mihai7221 CreditAttribution: mihai7221 commented18: views-893128-killua99-1-D6-2.x.patch queued for re-testing.
Comment #48
jonathan1055 CreditAttribution: jonathan1055 commentedI'm using Views 6-x-2.16 with php5.4 and I applied the patch from #28. This fixed 15 E_STRICT 'declaration of ... should be compatible with ...' warnings - Thank you.
However, in doing so, it introduced 4 new warnings for compatibility with
views_handler_field::pre_render(&$values)
. One of these is fixed by patch #30 in #465332: Strict warning: non-static method view::load() should not be called statically but the other three remain.Here is a patch with the details. Maybe this should be added to the patch in #28 as it is not a separate issue, just a more comprehensive fix alog with the changes made in that patch.
Jonathan
Comment #49
FrancewhoaAnother option at https://www.drupal.org/node/465332#comment-9388733
Comment #50
jonathan1055 CreditAttribution: jonathan1055 commentedHere is the patch from #28 with the four pre_render() warning fixes that I mentioned in #48 added into it. The original patch in #28 changed
pre_render($values)
topre_render(&$values)
in handlers/views_handler_field.inc. This needs to be replicated for modules/taxonomy/views_handler_field_term_node_tid.inc, modules/upload/views_handler_field_upload_description.inc, modules/upload/views_handler_field_upload_fid.inc and modules/user/views_handler_field_user_roles.incFrom #18 onwards we've only had 6.x-2.x patches, so that is what I am concentrating on.
Comment #51
jonathan1055 CreditAttribution: jonathan1055 commentedForgot to say, patch was against latest dev 6.x-2.16+6 dated 2013-10-19, but also applies cleanly to the 6.x-2.16 release.
Comment #52
ibnkhaldun CreditAttribution: ibnkhaldun commentedI guess: Perhaps a wrong patch direction
I've just read the proposed patch 50. It suggest :
-function ( &$var1, &$var2 )
+function ( $var1, &var2 )
over many methods. As php pass objects by ref, but not arrays() code suggest $var1 is passed by value, but many times $var1 will pass by ref. In particular if $var1 is a std form.
More. As old code expect $var1 passed by ref, new code won't pass arrays by ref... so you wont get a warning but can't do with your arrays wath you expect to do, particularly arrays won't be changed in those methods.
I think, the main way to patch is adding the & where needed instead of removing.
greetings
LgQ
Comment #53
hansfn CreditAttribution: hansfn commentedThis seems to be a duplicate of #1543434: strict warnings with PHP 5.4.x (which has been committed). Please consider closing this one.
Comment #54
bstrange CreditAttribution: bstrange commented@hansfn,
There are three similar topics and at this point, I'm not sure which one is 'correct'... I tried:
I tried to troubleshoot them myself but since they are both from "Unknown on line 0" ; I'm at a bit of a loss.
Any help would be greatly appreciated!
BTW: I also tried the Dev release (https://www.drupal.org/node/1543434) but no luck. Nothing rendered with Views loads on my site and at this point I'm thinking maybe between all the various patches, maybe there are a few applied that shouldn't be ... or perhaps I'm missing one... who could tell lol
Comment #55
SylvainM CreditAttribution: SylvainM commentedHere is the patch from #50 with another error fixed, but my view still don't work :(
Comment #56
SylvainM CreditAttribution: SylvainM commentedOups, sorry for previous patch, it was mixed with an other issue patch. Here is another one containg juste one more fix
Comment #57
joachim CreditAttribution: joachim commentedPatch filenames are incorrect -- roll a patch from the root of the contrib module.
Also, is this issue covered by the patch that's been committed at #1543434: strict warnings with PHP 5.4.x?
Comment #58
joachim CreditAttribution: joachim commentedIt turns out that some of the patch at #56 was already fixed by #1543434: strict warnings with PHP 5.4.x, but quite a few things were not.
Here is a reroll, with things already fixed removed, and a few more fixes I've added (for declarations of pre_render()).
Comment #59
pwolanin CreditAttribution: pwolanin commentedI'm still seeing this, but last me make sure I have the latest patches applied:
Comment #60
joachim CreditAttribution: joachim commented*sigh*
The trick might be to write a quick few lines of code that load up every class file in Views, so we get all the error messages in one go:
With the above patch, that gets me the following errors:
(and some errors from other contrib modules' views handlers too...)
I'm not seeing operator_form() though, and a search of the code of my version shows the definitions of that all match.
Comment #61
joachim CreditAttribution: joachim commentedHere's an updated patch an interdiff.
Comment #62
joachim CreditAttribution: joachim commentedOops.
Comment #64
joachim CreditAttribution: joachim commentedComment #66
v8powerage CreditAttribution: v8powerage commentedIs patch from #61 gonna fix all errors Joachim?
Comment #67
joachim CreditAttribution: joachim commentedI hope so. Try it!
Comment #68
younggeezer CreditAttribution: younggeezer commentedFYI, the change in the args to pre_render propagates complaints into every module with a views interface: image_attach, cck, date...
Comment #69
joachim CreditAttribution: joachim commentedThere's a patch to CCK, that I know at least.
Comment #70
v8powerage CreditAttribution: v8powerage commentedHi Unfortunately it didn't do the trick..
Comment #71
tsphethean CreditAttribution: tsphethean commentedComment #72
Jorrit CreditAttribution: Jorrit commentedIs it an idea to open a separate issue for 6.x-3.x? This will allow the test bot to test the patch on the right branch. Attached a patch with my current changes for this branch.
Comment #73
hass CreditAttribution: hass commentedComment #74
fonant CreditAttribution: fonant commented#61 works quite nicely here, for Views 6.x-2.18 and PHP 5.5.
Comment #75
v8powerage CreditAttribution: v8powerage commentedI disabled error reporting in htacces as i had no patience for it anymore..
Comment #76
GreenSkunkThanks for the patches!
Comment #77
DamienMcKennaClosed some duplicate issues: #2120727: Declaration of views_handler_field_user_roles::pre_render() should be compatible with views_handler_field::pre_render(&$values) , #2393285: Declaration of views_handler_field_item_node_nid::pre_render() should be compatible with views_handler_field::pre_render(&$values) , #2375079: Declaration Compatibility Issues - views_handler_filter::options_* and others
Comment #78
DamienMcKennaClosed another duplicate: #2458283: Views incompatibility in image_attach_views_handler_field_attached_images
Comment #79
DamienMcKennaAnother +1 for the patch in #61.
Comment #82
dawehnerThanks a ton, committed #61 to both 6.x-2.x and 6.x-3.x
Feel free to open up additional issues if more things are needed
Comment #83
jackalope CreditAttribution: jackalope commentedI'm using the most recent views-6.x-2.x-dev and am still getting a ton of these sorts of errors on a PHP 5.4 site:
Declaration of views_plugin_row::options_submit() should be compatible with views_plugin::options_submit($form, &$form_state) in /var/www/sitename/httpdocs/sites/all/modules/views/includes/handlers.inc on line 76.
It seems like these should be cleared up by the newest dev version or the patch in #61, but they're not; am I missing something else that needs to be fixed here?
Comment #84
DamienMcKenna@jackalope: Please open new issues for other things you find, as dawehner requested in comment #82.
Comment #85
jackalope CreditAttribution: jackalope commentedOK, will do @DamienMcKenna! Wasn't sure if this was a different thing I was finding, or the same thing that this ticket was meant to address.
Comment #86
jackalope CreditAttribution: jackalope commentedFalse alarm anyhow: I'd mistakenly applied this other patch to the newest 6.x-2.x-dev, and that is what caused these errors. Without that patch, those errors are now gone--whew!
Comment #88
IFL Todd CreditAttribution: IFL Todd commentedI applied the patch from #61, and I no longer get the Views module warning; but, still the following views related warnings about Declaration of child method should be compatible with parent method in CCK, Date, Nodequeue, UC_Views, Views_RSS, Views_Attach, and others possibly.
Does this need to be an individual issue raised with each module?
Please advise. Thank you so much,
Todd
Comment #89
SeanA CreditAttribution: SeanA commented"Does this need to be an individual issue raised with each module?"
Yep! It's usually just a matter of adding or removing an "&" symbol somewhere. Or try to ignore the warnings until they eventually get fixed.