I have been using the latest PHP 5.4.1 with Drupal 6.25 [Pressflow] - as of April 24th 2012.
Of all the D6 code issues I faced, The Views D6 Module was the most 'difficult' with PHP 5.4.x.
Over +25 PHP 'warnings' like; = "Strict warning: Non-static method", "Strict warning: Declaration of views_xxx should be compatible with views_xxx::xxxx", Warning: Illegal string offset 'xxx' in views_xxx"
I made changes to Views 6.x-2.x-dev release, tested, and then created a patch file [the difference between latest Views 6.x-2.x-dev release @ 20th April 2012 - and the final working result].
Here it is:
Comment | File | Size | Author |
---|---|---|---|
#52 | views-php5.4-1543434-52.patch | 1.15 KB | hansfn |
#43 | increment.txt | 896 bytes | pwolanin |
#43 | PHP5.4-1543434-43.patch | 10.84 KB | pwolanin |
#38 | views-make-it-work-in-PHP5.4-38-1543434-6.x-2.16.patch | 10.09 KB | mvwensen |
#28 | views-php5.4-1543434-28.patch | 17.55 KB | nitishchopra |
Comments
Comment #1
Peter Bowey CreditAttribution: Peter Bowey commentedFor those that prefer to see the views-2.x-dev.php_.5.4.x.patch live:
Please *note* that this patch does *not* cover all the likely areas that Views needs 'changing' for the new STRICT PHP 5.4.x syntax. This patch covers the Views API sections / areas that I presently use. However, it will serve as 'seed' point to guide / motivate others.
Without such changes I had 'Views' breaking code under PHP 5.4.x. (certain views hooks failed totally!)
The other slightly challenging common D6 module (with PHP 5.4.x issues) was 'ctools' - which I found has similar issues due to interfacing with 'Views'.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedAs has been discussed many times in the past, Views 2.x is PHP4 compatible. The 'static' keyword did not exist for methods in PHP4. This means that Views 2.x will always cause STRICT warnings in PHP 5.2 and later. Those changes are disallowed.
Plus, please don't add code attributes in a patch. Attributions go in commit messages. Otherwise our code would be littered with attributions as literally hundreds of people write patches that get committed.
Comment #3
Peter Bowey CreditAttribution: Peter Bowey commentedI have *existing* D6 clients that are stuck with Views 2.x; as they have such a huge [but older] database that the new Views 3-or-4.x would create days of work re-creating.
So, creating this is going to be a help for other 'older' sites - and the 'poor' Developers that maintain them.
I am sorry that does not help the current Views releases - but this 'issue' is based on seeing corrupted Views migrating old sites - to the new Views. It is not so trivial - to migrate to the latest Views! Been there - done it!
I am not suggesting 'changes' to something you do not 'support' => Views 2.x!
I am thinking of the D6 community benefit for other older sites.
Comment #4
merlinofchaos CreditAttribution: merlinofchaos commentedOkay, so you want to provide FATAL errors to people using PHP4 because you get E_STRICT warnings with PHP5?
This makes sense...how?
Comment #5
merlinofchaos CreditAttribution: merlinofchaos commentedOh and at the same time, you use derisive language when discussing my decision to disagree. That's awesome.
Comment #6
merlinofchaos CreditAttribution: merlinofchaos commentedComment #7
merlinofchaos CreditAttribution: merlinofchaos commentedOh here's a hint: Turn off E_STRICT warnings. That's the only solution that works for both PHP4 and PHP5.
Comment #8
Peter Bowey CreditAttribution: Peter Bowey commentedI am sorry for the lack of clarity - no harm meant - or any kittens harmed!
This is not targeted to PHP 4x users - or developers!
I trust that is made clear enough by carefully worded intent:
Quote: read "Patch file for Views 6.x-2.x-dev to work with PHP 5.4.x"
I trust that it will help those using PHP 5.4.x - with older Views?
I am now unsure what is intended on the above references?
I am sorry if you are harmed - by any words I have written.
Comment #9
merlinofchaos CreditAttribution: merlinofchaos commentedMy point is: Your patch, if applied, will cause FATAL errors to people using PHP4.
Views for Drupal 6 (both 2.x and 3.x branches) is PHP4 compatible. That has always been our policy. It was written, originally, for PHP4, and we will not apply patches that break that compatibility. These E_STRICT errors are something that PHP5 users are forced to live with, and we tell people stuck using older Drupal 6 code to turn E_STRICT off if using newer versions of PHP. That is the only solution that allows both PHP4 and PHP5 to function.
Comment #10
Peter Bowey CreditAttribution: Peter Bowey commentedRefer #7
Quote: "Oh here's a hint: Turn off E_STRICT warnings. That's the only solution that works for both PHP4 and PHP5"
Answer:
'No': To "Turn off E_STRICT warnings"; that is for 'users' - not PHP code developers.
I need to know what code to change! ;-)
Anyway, I am soon to work some *new* D6 / D7 / D8 sites that can use the new & awesome Views.
I appreciate all the work of the teams that make Views work. It is awesome code!
Many thanks to all the Views code team.
Comment #11
Peter Bowey CreditAttribution: Peter Bowey commentedRefer #9
Thanks, the point is fully noted!
I trust this will http://drupal.org/node/1543434 will reach *only* those fully understanding the PHP issue!
I will be happy if the Views Team leave it all 'hidden' in a back section, but not removed -please!
Comment #12
Peter Bowey CreditAttribution: Peter Bowey commentedChecking on the Views Module page, I see this:
The version 2.x of views was released quite some time ago, and works fine for many people.
It got new features from time to time.
Then the development of views 3.x started, the port of views to drupal7 was created and a lot of new features/bug fixes/really tiny bug fixes got committed. So the development is primarily focused on views3.
Based on this views2 doesn't get new features and only critical bug fixes.
At this time, I have not seen a mention of a 'PHP x.xx warning' for D6 people.
Would it be good to document one at http://drupal.org/project/views?
Comment #13
merlinofchaos CreditAttribution: merlinofchaos commentedBy default, released versions of Drupal 6 do not display E_STRICT errors. This only happens if you have enabled this in your php.ini I believe. (Potentially you even have to patch core, but I forget exactly the process). It hasn't been a problem for most users, at least.
You'll need to search to see how E_STRICT warnings are enabled/disabled. I honestly don't remember. :)
Comment #14
Peter Bowey CreditAttribution: Peter Bowey commentedI suggest that it would be good to document on the Views Module
page that Views for Drupal 6 (both 2.x and 3.x branches) is *bound by* PHP4
compatibility requirements and therefore does not [cannot] support PHP 5.4.x.
And in some cases (see: http://drupal.org/node/1537698 ), incorrect results may/will
occur if D6 Views is used under PHP 5.4.x. My case was for a solution to an error status.
Comment #15
claar CreditAttribution: claar commentedmerlinofchaos said in #13, "By default, released versions of Drupal 6 do not display E_STRICT errors."
This is no longer true, unfortunately. In PHP 5.4, E_STRICT became part of E_ALL, so these errors ARE displayed by default after upgrading to PHP 5.4.
This issue is going to continue to cause a lot of traffic as sites are upgraded to PHP 5.4 and above, as views 2.x is the worst offender for STRICT warnings of common modules -- it may very well be worth the hassle of finding a workaround for 6.x-2.x (would it be possible to temporarily disable STRICT warnings when including the views module, or some such workaround?).
Comment #16
crystaldawn CreditAttribution: crystaldawn commentedYou cannot disable E_STRICT in php 5.4.x All you can do is turn off display_errors completely and rely on the apache log file. E_STRICT is going to become part of your life if you opt to continue to use PHP for any amount of time in the near future. The OP is on the right track with the suggested patches. It IS indeed a better idea to throw fatal errors for PHP versions that are no longer supported. Especially after the latest PHP critical security flaw uncovered just this past month (http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/#comment-3071) in which it affects ALL PHP versions. Yet the only versions that will get updated are 5.3 and 5.4 (not even 5.2 will get updated!!!). I agree with the OP that patching these is the proper course of action, regardless of what it does to older PHP Versions.
Now had the versions that would be affected had been SUPPORTED versions (IE: PHP 5.3 and 5.4), then indeed Merlin would be correct. But I have to respectfully disagree that supporting now completely vulnerable PHP versions is a good course, because it's NOT. Since PHP hasnt been supporting PHP 4.x for years now, it makes absolutely NO sense to support it here since it's going to be riddled with security holes such as the one I just described which is going to be absolutely catostrophic in the coming months to MANY websites and servers. Mark my word, this security issue is going to become front page news sometime soon, if it hasnt already. And that is why it's a bad idea to support unsupported PHP versions in the first place. It was just a matter of time before something like this came along, and its here now. Stop supporting rubbish PHP versions.
Hmm front page news sooner than I thought heh.
http://arstechnica.com/business/2012/05/attackers-target-unpatched-php-b...
"I wouldn't be surprised if we continue to see this bug exploited in the wild for two or three years because it will take a while for people to patch their systems," he told Ars. "There are a lot crusty old boxes out there running old versions of PHP, and if those are configured as CGI it's going to affect it."
Have to admit, until today I was running 4.1.4, 5.1.4, 5.2.14, and 5.3.3 in CGI mode all on the same server. I do this because it's easy to support multiple versions of PHP without having to do anything other than symlink to different binaries for different clients. The reason I'm even on this thread is because I've been forced to upgrade to 5.4 because of this very vulnerability. The attached patches helped me in my case, and I'm sure more like me are going to show up here looking for the same solution. I have changed my CGI versions to 5.3.4 and 5.4.3. My own servers no longer support the older PHP versions because of this 1 vuln that wont be patched for the older PHP versions.
Props to Claar and peter bowey for realizing this, nice job.
Comment #17
merlinofchaos CreditAttribution: merlinofchaos commentedHey crystaldawn, here's a hint: drupal.org sends emails as soon as you hit submit. You went back and edited your reply, but I got the original. You know what you wrote, so I won't repeat it here, but I hope you're embarrassed that I got that.
You can argue until you're blue in the face about whether or not we should continue to support PHP4, but it says on http://drupal.org/requirements that Drupal 6 supports php 4.4 or higher.
I will not break this requirement because you're getting E_STRICT errors. You can call me whatever names you like; all it means is that I will not actually read anything else you have to say.
Comment #18
crystaldawn CreditAttribution: crystaldawn commentedI decided to remove it because I thought it hypocritical to dis you like you did the OP with your first very rude reply. I could embarrass you publicly if you like though by pointing out why your suggestion of "Disabling E_STRICT" wont work for PHP 5.4, 5.5, 5.6, 5.7 and every PHP thereafter. Is that the course we should pursue? The bottom line is that these 2 fellows are on to something that you need to realize. The days of supporting the older PHP versions has come to an end. It's time to pony up and adhere to the PHP Coding standards of the future. Much like what is going to happen to D6 and has already happened to D4 and D5. Is there a version of Views 2 for D4? No? Why is that? Because it's no longer supported, thats why. Do you see where I could take this?
Comment #19
merlinofchaos CreditAttribution: merlinofchaos commentedOne addendum: If Gábor Hojtsy commits a patch to Drupal 6 that officially ups the requirements to PHP 5.x, then I will rip PHP4 support out of Views for Drupal 6.
Until that day, there is no argument you can make that will make me intentionally provide a fatal error on PHP4. There is no discussion here. Take it up with Drupal core if you still feel the need to argue.
Comment #20
xjmFor these reasons, it is also not appropriate for a contributed module to support 5.4 at the expense of 4.4. Users who need support for 5.4 are able to patch their own codebases and manage the patches with drush or the like.
Comment #21
crystaldawn CreditAttribution: crystaldawn commentedXJM is correct, patches are required. But as per Merlin's suggestion, the patch shouldnt even exist and he asked to not post more when the OP mentioned that there may need to be more to get all the errors (which I dont currently see any as yet). Perhaps its time to discontinue D6 all together if it's not going to adhere to the PHP support lifecycle. Since it's supported PHP version has been discontinued, maybe D6 should be discontinued as well, even though it's not really necessary since it could easily be set to use at least 5.3 without much issue. The lifecyle of 5.3 is shorter than that of 5.4, but it's way better than 4.x which is now in a coffin.
Comment #22
merlinofchaos CreditAttribution: merlinofchaos commentedPersonal attacks are a violation of the Drupal Code of Conduct and are not appropriate here. I am locking this thread to prevent further attacks.
Notes on the actual discussion:
According to a stack overflow thread, it is possible to disable E_STRICT. You have to do it very early, however, as the errors are compile time, not run time, so it must happen before modules are loaded. You can do this in your settings.php, I guess. But it IS possible to disable E_STRICT.
Comment #23
gregglesI ran into this bug the other day.
In comment #19 Earl commented that if Drupal 6 drops support for php4 then it would be reasonable for Views to do the same. I agree wholeheartedly with that perspective. In #2140113-25: [Policy] Stop supporting PHP 4 Dries agrees to drop support for PHP4 in Drupal 6 and then in comment #26 Gábor Hojtsy agrees and takes the steps necessary to advertise that support will be dropped on March 1 of 2014 (i.e. in 2.5 weeks from this comment).
So, if we can set aside some of the early mis-steps in this issue and focus on the technical issues....
I've updated the patch from the original post.
1. Rerolled it to apply with git apply (I had to use "patch -p2 < view*.patch" to get it to apply)
2. Removed all comments/code attribution - that's what the revision control system is for
3. I removed a change to a trailing comment to remove punctuation - code style says that comments get punctuation and things like that should be saved for a style cleanup issue instead of a php compatability issue.
4. I left in the css change to view.css, but I'm not sure where the motivation for that change originated - it seems odd to me do do that in a patch related to php. @Peter Bowey - can you explain it?
I didn't test this out to see if it actually fixes the problems.
Comment #24
gregglesp.s. I didn't unlock the thread, commenting is closed but #2193793: New issue comment/edit form should not be available when comments are closed for the issue
Comment #26
charleyramm CreditAttribution: charleyramm commentedI applied this patch to my existing Drupal 6 Views module -- it corrects some errors but the module is still non-functional.
I have gathered the errors from before and after applying the patch here: http://pastebin.com/KB6VdnzT
Comment #27
gnassar CreditAttribution: gnassar commentedThese errors occur with 6.x-3.x as well, of course -- should we be rolling for that instead of 2.x? And/or should patches for 3.x be under a different ticket, or included here? I ask because 2.x no longer has a dev version, and it seems that 3.x-dev has fixed the upgrade problems (as far as I can tell; I just upgraded an older site I administer earlier today, and it went without a hitch).
Comment #28
nitishchopra CreditAttribution: nitishchopra commentedHi, please find a patch file to get rid of the warnings related to the views while using php5.4.
Comment #29
vegantriathleteSetting aside the PHP4.x vs. PHP5.x issues (like public static) could we at least get the function signatures consistent with regards to call-by-reference vs. call-by-value? I realize that D6 is very old and likely reaching EOL very soon, and I totally understand that it is not at all appealing to have to expend resources to deal with something like this. However, it is no easy matter to convert from the Views 2.x branch to the Views 3.x branch on account of the fact that there may be contributed modules in use that specify the Views 2 API. So, I don't believe this is simply a matter of the Views creating an upgrade from the 2.x branch to the 3.x branch.
I don't have anywhere near the level of understanding of Views to be able to decide whether a function should be using call-by-reference vs. call-by-value. I'm concerned that if I just take the approach of making everything call-by-reference I will overlook those functions that do modify what would otherwise have been a local version of a variable producing unintended consequences that could become extremely hard to debug.
Comment #30
gregglesI'm not sure if there's tests for D6, but at a minimum this does "Need review" based on #28.
Comment #32
suryanto28: views-php5.4-1543434-28.patch queued for re-testing.
Comment #34
vegantriathleteEven if that patch passes testing, it definitely needs rework. It suffers from the comments / code attribution issue just like the original patch.
Comment #35
mvwensen CreditAttribution: mvwensen commentedCreated a new patch fixin the errors, used the patch from comment #28 as base.
This patch fixes several errors thrown in PHP 5.4.x
It is tested with Drupal 6.31 and Views 6.x-2.16 on PHP 5.4.4(LAMP) and PHP 5.4.8(WAMP)
Attention: This patch probably breaks views on PHP 4.x
Comment #36
mvwensen CreditAttribution: mvwensen commentedSet to needs review...
Comment #38
mvwensen CreditAttribution: mvwensen commentedSame as #35, typo fixed!
Comment #39
realgiucas CreditAttribution: realgiucas commented#38 patch solved all strict warning exept 2:
Tryed on two different sites with same effect
Comment #41
dawehnerI would rather fix all the other instances ... &$options might be manipulated somewhere? $options has a reference in D8, so I would suggest to orientate there.
Thats indeed fine.
Comment #42
theohawse CreditAttribution: theohawse commentedThe patch in #38 works excellent, however the following warning still comes up whenever a list view is used:
Warning: Invalid argument supplied for foreach() in require_once() (line 16 of /sites/all/modules/views/theme/views-view-list.tpl.php)
Unfortunately I lack the skills to fix it, is anyone able to help? Even if the error reporting is sent to log only, I'm still seeing "<>" in the top-left corner of my sites, just after the body tag.
Comment #43
pwolanin CreditAttribution: pwolanin commentedfix the 2 mentioned in #39
Comment #44
pwolanin CreditAttribution: pwolanin commentedI'm not sure the tpl one is generic? Are you sure that's not a site bug? setting to needs review for further feedback
Comment #46
dawehnerCommitted and pushed...
Comment #47
hansfn CreditAttribution: hansfn commentedIs it just me, or did you overlook the init functions in
views/handlers/views_handler_argument_many_to_one.inc
views/modules/user/views_handler_field_user_name.inc
I'm using Open Atrium and got strict warnings about incompatible init functions for these two files/classes after using the latest 6.x-2.x-dev release (which contains the patch in this issue).
Nice work, by the way - thanks!
PS! I also got this warning: "Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in .../sites/all/modules/views/plugins/views_plugin_style_default.inc on line 24." Not sure if it's just to update the definition in views/includes/base.inc
Comment #48
dbourrion CreditAttribution: dbourrion commentedHi
Many thanks fort that but (sorry for my silly question), where is Views 6.x-2.x-dev release ?
Can't find it on the views project page
Best
D
Comment #49
gregglesIt's at https://www.drupal.org/node/95897
I found it by going to the views project page, clicking "view all releases," then filtering for 6.x and going back through the pager.
Comment #50
dbourrion CreditAttribution: dbourrion commentedOk, got it - many thanks
Comment #51
greggles@hansfn - can you post the specific error messages that you get?
Comment #52
hansfn CreditAttribution: hansfn commentedThe init error message is the standard one:
I thought my message was so clear and the problem was so simple that no patch was necessary. Anyway, patch for the two leftovers is attached.
Comment #53
simone960 CreditAttribution: simone960 commentedThere are so many patches here. I wonder which one is the complete one ? I need to patch my production site.
Comment #54
bstrange CreditAttribution: bstrange commentedI hear you simone960! I applied the patch from #11 0n (https://www.drupal.org/node/465332#comment-9469777) and then (#26) linked patch from https://www.drupal.org/node/893128#comment-5680104 (#28) and still had 2 warnings & none of my views would render... then I came here and applied #43 and the increment, and then #52 and still no joy on my production site! Still getting the following error:
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
crac CreditAttribution: crac commented@bstrange As far as I could understand the patch https://www.drupal.org/files/issues/PHP5.4-1543434-43.patch is a cumulative patch which includes everything you need, except for the one mentioned in #52: https://www.drupal.org/files/issues/views-php5.4-1543434-52.patch. But for me it was enough to apply it without that last patch.
Comment #56
bstrange CreditAttribution: bstrange commentedThanks crac,
I think I will restore all of the original files (i backed them all up before applying patches) and try just 43... seems like a ood place to resume troubleshooting :)
Comment #57
steinmb CreditAttribution: steinmb commentedComment #58
simone960 CreditAttribution: simone960 commentedWill the latest version 6.x-3.0 solve the STRICT issue completely ?
Comment #59
joachim CreditAttribution: joachim commentedI presume there'll be a new release on the 6.x-2.x branch once the remaining problem is fixed?
Comment #60
joachim CreditAttribution: joachim commentedFYI: I found another strict warning, that only comes up with the default display plugin or if using Semantic Views. Patch at #2411541: strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options. (I figure it's maybe better to tackle new ones that come up in follow-on issues?)
Comment #61
joachim CreditAttribution: joachim commentedLet's call this fixed since a patch was committed, and let's say #893128: Fix E_STRICT notices - method declaration compatibility with init(), pre_render(), _validate() and _submit() with PHP 5.4.x is a follow-up, since there's a patch there.
Comment #63
dawehnerCommitted the patch to 6.x-3.x as well.
Comment #64
IFL Todd CreditAttribution: IFL Todd commentedMarked
PHP 5.4.x + compatibilityas a duplicate and closed.Comment #65
DamienMcKennaFYI, for anyone coming across this, there are many related issues tagged "PHP 5.4".
Comment #66
DamienMcKenna