Not sure if E_STRICT compliance is a goal, but in case it is the following four messages appear on enabling the module and one or other of them appears on other views using pages.

Couldn't find any sign this had previously been submitted but sorry if it has.

# strict warning: Non-static method view::load() should not be called statically in /var/www/stats/htdocs/sites/all/modules/views/views.module on line 843.
# strict warning: Non-static method view::load_views() should not be called statically in /var/www/stats/htdocs/sites/all/modules/views/views.module on line 801.
# strict warning: Non-static method view::load_views() should not be called statically in /var/www/stats/htdocs/sites/all/modules/views/views.module on line 801.
# strict warning: Non-static method view::load() should not be called statically in /var/www/stats/htdocs/sites/all/modules/views/views.module on line 843.

Files: 
CommentFileSizeAuthor
#30 views-465332-30.patch596 byteschrishks
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#11 views-465332-11-d6-2x.patch1.5 KBhyrcan
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]
#6 views-465332-6.patch1.64 KBmikeytown2
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-465332-6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#5 views-465332-5.patch1.25 KBmikeytown2
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-465332-5.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#3 views-465332-1.patch667 bytesmikeytown2
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-465332-1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Status:Active» Closed (won't fix)

Because the goal is PHP4 + PHP5 compatibility, E_STRICT compliance does not work, because PHP5 STRICT is not PHP4 compatible. =(

Can you make a patch for this issue? I will patch this manually in our views installation.

Priority:Normal» Minor
StatusFileSize
new667 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-465332-1.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Patch for this

Title:Stricting warning: non-static method view::load() should not be called staticallyStrict warning: non-static method view::load() should not be called statically

StatusFileSize
new1.25 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-465332-5.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

StatusFileSize
new1.64 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch views-465332-6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Mikey,

I am currently having this issue. Is the last patch the last one that needs to be done to fix the problem or start from #3 and go down?

Help is appreciated.

David

The only patch you need is #6

Aplly this patchs to the dev branch, could be nice ;D

Because the goal is PHP4 + PHP5 compatibility, E_STRICT compliance does not work, because PHP5 STRICT is not PHP4 compatible. =(

Granted, the notion of strict is different between php4 and php5, but it still seems to me that we would want our code to not call a non-static method statically.

non-static method view::load() should not be called statically

It's impossible to *enforce* static in PHP 4, but that doesn't mean we can't write our code correctly. If we're calling a method that was not defined statically, we should not call it as if it were a static method. Or vice-a-versa.

I'm not going to re-open this ticket, but I think we're just inviting bugginess by not following best coding practices in the name of PHP-4 compliance, when I don't think it's an exclusive OR.

StatusFileSize
new1.5 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Updated the #6 patch, this includes additional non-static strict fixes.

What is the reason of the PHP4 support? Are there so many installations using it? It is very annoying seeing these warnings and turning off the STRICT only hides the issue.

juampy, the reason is 6.x-2.x is a stable release series. We do not break compatibility in minor releases. That'd be horrid to anyone who runs a Drupal site on a server (s)he has no control over it. Also, E_STRICT is a truly asinine move from PHP I have ranted against it in another issue. So: you do not gain anything by going strict but screw people. No point.

As for bugginess, show me an issue here on Drupal.org where the switching on E_STRICT actually caught a bug. E_ALL did! E_STRICT doesn't catch bugs, it causes headaches and nothing else.

Priority:Minor» Major
Status:Closed (won't fix)» Active

I am getting this error as soon as I enable the latest views in a new drupal I just instaled on a windows server that has php 5.4.4 and apache
Is there a version that doesnt give this error available ?
Non-static method view::load_views() should not be called statically in C:\xampp\htdocs\drupal\sites\all\modules\views\views.module on line 1071.

Status:Active» Fixed

@dianacastillo

The reason: http://drupal.org/node/465332#comment-1600034 and many other comments here, please be fair and first read an issue. There is even a patch available if you really can't switch of strict notices.

Status:Fixed» Closed (won't fix)

moving issue back to original status

Status:Closed (won't fix)» Active

Its not just a question of switching of notices, I tried that and dont get the warnings, but then the views module doesnt work.

I also tried the patch but when I tried to run it with a patch utility it just hung up. so I did the patches manually and that didnt solve the problem either.

Status:Active» Needs work

I did it again, I made all of the changes in this patch on my module http://drupal.org/files/views-465332-11-d6-2x.patch

but I still get this message :
strict_warning: Non-static method view::load_views() should not be called statically in C:\xampp\htdocs\drupal\sites\all\modules\views\views.module on line 864.

That's why I reopened this issue. Sorry I didnt make it clear before that I had read and tried all of the solutions before.

this is on a windows server , could that have to do with it? but it's working fine on another windows server we have.

Status:Needs work» Closed (works as designed)

@diana, please have a look at comment #13. @chx explains pretty well the reasons why having E_STRICT mode for error reporting does not help at all. E_ALL does.

Status:Closed (works as designed)» Needs work

hi, I have read over this page several times and it doesnt say where to change the E_STRICT to E_ALL

where should you change this?

Status:Needs work» Closed (won't fix)

okay i found it, its in the php.ini file I will change it and report if i still have problems

@dianacastillo, @chx, et. al. -

Important to note that in PHP 5.4, they changed E_ALL to include E_STRICT. (http://us.php.net/ChangeLog-5.php#5.4.0)

Still closed/wontfix?

FYI for others running into this problem: you may be able to adjust their error_reporting value in php.ini. Here's the documentation for that variable that comes with Ubuntu 12.10:

; error_reporting
; Development Value: E_ALL
; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT

(Note that in a production environment, error_reporting should turn off the E_STRICT bit as is done in this example, using "& ~E_STRICT" .)

even after disabling E_STRICT in php.ini, the issue is still here.
here is a quick fix for that : http://groups.drupal.org/node/217529#comment-826138

Instead of trying #24, you can use the patch in #11 instead. Works for me. The patch is simple enough to apply manually (the format of a patch file isn't too hard to figure out).

Priority:Major» Normal

A patch that fixes additional PHP 5.4 warnings in Views: http://drupal.org/node/893128#comment-5680104

And a fix for one that crops up in CCK: #1962718: Strict warning: Declaration should be compatible.

I'v applied the #11 patch, then both patch which was written at #26 comment, but I still have one error message:

strict warning: Declaration of views_handler_field_term_node_tid::pre_render() should be compatible with views_handler_field::pre_render(&$values) in [path-of-the-site]/sites/all/modules/views/modules/taxonomy/views_handler_field_term_node_tid.inc on line 6.

For me the "filter out strict warnings" solution is not enough. I don't want just to hide these messages, I'd like to solve the problem.

I didn't find solution for this message. Is there anybody who knows a patch for this one?
Thank you in advance.

drupal-6.28
views-6.x-2.16
PHP 5.4.4-14+deb7u3 (cli)

Works for me:
I'v applied the #11 patch from this issue, then the #27 patch from here: https://drupal.org/node/893128#comment-5677048
In this case I do not need the cck fix: https://drupal.org/node/1962718

All error messages dissapeard from the homepage.

Status:Closed (won't fix)» Needs review

I was faced with the same issue. After applying suggested patches, all warnings disappeared except for this one (comment #27). Based on the information in the warning, I opened the /sites/all/modules/views/modules/taxonomy/views_handler_field_term_node_tid.inc file and changed the declaration of the pre_render function from "function pre_render($values) {" to "function pre_render(&$values) {" and it fixed the problem.
It would be nice if this fix were added to the views patch: https://drupal.org/files/views-893128-28-d6-2x.patch

StatusFileSize
new596 bytes
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es).
[ View ]

Created a small patch for the issue described in #27 and #29 - could be added to the other views patch as suggested.

FYI - I started getting these errors on my shared hosting (Bluehost) when they automatically upgraded the version of PHP. They forced a change from 5.2 to 5.4 without any notification and that's when the errors started appearing. I just reverted back to 5.2 and the errors went away.

I'm having these errors on my HostMonster shared hosting (maintained by Bluehost) which switched the PHP version to 5.4. I can only switch back to 5.2 for a week, in order to try fix the errors.

Upgraded the Views module to 6.x-3.0 and still get these messages when switching to PHP 5.4. The errors don't show when using PHP 5.2 with this latest version of Views. I did have to reassign my paging options however, as the upgrade did not take care of that. Does this mean that I have to upgrade mu drupal 6 to D7 as well?

Issue summary:View changes

I'm not sure why making the methods static is going to break backwards compatibility.

I think @apotek said everything that needs being said about that in #10 but if there's anything I'm missing, I'm always willing to learn.

Issue has to do with PHP 4 (#10).
PHP 4 is getting dropped from D6 support soon https://drupal.org/node/2159315

I don't see an issue with committing PHP 5 only code to 6.x modules after March 1.

I'm also getting this exact error, using PHP 5.4.24.
Surprised to see that this is an issue from way back in 2009 and still pending.
Hope there will be a new release to address this issue.

i applied the patch mentioned at #11 and the warning view::load() should not be called staticall warning vanished for me.

Given that the support for php 4 is removed since March 1st we could actually apply the patch. On the other hand I really don't want to make a release
now, just to fix some issues for a small group of people running an old version of Drupal on a more or less recent server enviroment.

@dawehner, may I ask why not? I mean, is there a downside? Even if the number of affected people is small (is it?), why is it not worth fixing?

The downside is that half a million sites potentially want to update to the recent release. This is a huge effort,
especially given that the release would have to be supported.

But a new release has release notes detailing the changes and people (should) read them before updating their software. If the changes in the new release are not something they want and updating the software is a huge effort, they can simply choose not to update, at least until they have to for other reasons.

Besides, updating a Drupal module isn't that much effort, I think.

Not sure what you mean about the release having to be supported. If you mean support from the package maintainers, isn't the current version supported as well? I think I'm missing something here.

But a new release has release notes detailing the changes and people (should) read them before updating their software. If the changes in the new release are not something they want and updating the software is a huge effort, they can simply choose not to update, at least until they have to for other reasons.

HAHAHAHA, you made my day. Users are so into reading.

Not sure what you mean about the release having to be supported. If you mean support from the package maintainers, isn't the current version supported as well? I think I'm missing something here.

Everytime a module gets updated people fuck up their drupal sites, even if just 0.001% percent of all sites fuck it up, there is still a non-neglectical amount of issues coming up.

If they don't read and they fuck up their sites like you said, it's their fault. Any serious developer or website maintainer worth their salt will verify things before updating a live site. If others don't do it, it's their problem. And this kind of thing is why I am in favour of a mandatory "computer driving license", especially for people with serious jobs.

What I don't understand is why some people will have to be harmed because others don't know what they're doing. That's not being "user friendly", that's being accomplice to mass stupidification. I am going to enjoy leaning back and watch the show when Drupal 8 is released. Or maybe we shouldn't release Drupal 8 either, since it will fuck up users in so many ways that this issue here will look like a walk in the park.
(I'll love it, by the way, since it will finally do away with some of the insanity in Drupal's codebase)

But I digress. I guess we'll just have to agree to disagree on this.

Yeah, feel free to help once people freak out. I am pretty convinced that you won't help at all in that case.

I already do, it's part of what I chose to be my job. Apparently my irony was lost along the way. But I don't want to fuel this anymore, since it is clear it won't lead anywhere, so I'm going to unsubscribe from this topic.

Status:Needs review» Reviewed & tested by the community

Moving this to RTBC since there are no technical reasons to not commit it now.