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.

Patch for this

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.

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.

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.

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

moving issue back to original status

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.

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.

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

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?

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

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.

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

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?

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.

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

Thanks for the patch. Here also using PHP 5.4. I've applied the patch in #30 and most of the warnings went away. However, this warning remains active:
strict warning: Non-static method view::load() should not be called statically in /.../sites/all/modules/views/views.module on line 906.

And, also this one
strict warning: Declaration of content_handler_field_multiple::pre_render() should be compatible with views_handler_field::pre_render(&$values) in /.../sites/all/modules/cck/includes/views/handlers/content_handler_field_multiple.inc on line 0.

Right now I don't have time to invest looking at it now to fix it, just wanted you all to be informed. HTH, thank you.

Well, I wasn't using the -dev version (but the latest stable version), maybe that explains the difference, so please disregard my last comment. Thanks.

Hi

I am running php 5.4 with drupal 6.31 , I applied the patch in # 30 as marino

to disable such warning, I opened /includes/common.inc and replaced the following (line 668)

if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE)) {

with

if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE ^ E_STRICT)) {

Reason for this error message : In php 5.4 , they decided to include E_STRICT error message as part of E_ALL error message and even if you edit php.ini to exclude E_STRICT , drupal6 will overwrite the file .

Hope this helps anyone struggling

to my complete my earlier sentence,

I applied the patch in #30 and continued to receive the same message as marino-barcia gets in #47

I was forced to modify the core per comment #49 because the Drupal log was being spammed with these pointless warnings, not just from the Drupal core.

(Fedora Core 20, Drupal 6. Gallery integration and some other local ones prevent upgrade to later Drupal releases).

followed #49 to remove the error. hoping this will get rolled into future core?

Hi folks.

In PHP 5.4 E_STRICT became part of E_ALL, see more there, but D6 and many D6 modules isn't absolutely ready for this (for example: views-6.x-2.x module).
As amedjones suggest please insert my patch to the future 6.x core (there is a lot of strict warnings on the PHP >= 5.4).

Patch is for file: includes/common.inc
Thanks a lot.

Hi again.

I prepared better patch that is compatible with all versions of PHP (5.3 and also >=5.4).

Patch is for the D6.33 file: includes/common.inc.
Bye.

The original issue here is about Views. If you believe that core needs to be patched to handle this more generically, please open a separate issue and cross-link it rather than hijacking this issue.

#11 solve all my problem !

#54 working. thanks

Another option is to install "disable_messages" module. And disable all messages related to strict .*.
Read more here, under "How to hide only specific error messages to specific users" section.

Updated patch for 6.34.

Hi karnakitab,
Your patch files seems to be empty. However, I do not think this issue should be altering core files anyway. This issue is for Views, so the patches should be on views-related files like in #11 and #30. It was marked RTBC in #46. Maybe we should re-roll the changes from #11 and #30 as those are actually fixing the code. I might check them and do that.
Jonathan

Here is the new patch.
The patch is for common.inc core file.
@Jonathan It was dropbox error to nullify my previous patch file. Sorry for that

@karnakitab
Patching common.inc like what you did in #62 is not the correct fix. #30 fixes this properly by patching views; this issue is inside of the views module.

Sorry to be pedantic, but actually the patch in #11 is the one which fixes the issues reported in this thread, by adding 'public static' to the definitions of four functions. I know I mentioned the patch in #30 but that was a distraction. That change belongs to the patches in #893128: Fix E_STRICT notices - method declaration compatibility with init(), pre_render(), _validate() and _submit() with PHP 5.4.x (which I may re-roll to add it in) so this thread can ignore it.

The patch in #11 still applies cleanly to both the 6.x-2.16 release and the latest 2.16+6 dev release dated 2013-10-19.

Setting this back to RTBC as per the comments above (#46 in particular)

Merged #30 & #11

Thanks mikeytown2, but that single fix to pre_render() does not belong in this issue or patch. The original change to pre_render plus other fixes for the function extensions are all in #893128: Fix E_STRICT notices - method declaration compatibility with init(), pre_render(), _validate() and _submit() with PHP 5.4.x in comment #50. We don't need to merge just one of them here - the comment in #30 was off issue. So the patch in #11 is still the one we want, to keep on topic :-)

Jonathan

I' d post a similar issue about a year ago, and close it because it seems duplicate this.
But Not really. We have a bigger problem here. Not a simple method declaration replacement.

There are several views classes wich do not match parents' methods signatures. I reviewed all views classes and found methods non static wich their parent's method is. I found parent's methods declaring &$var reference, and extending classes declaring that argument by value. That because in Php5.4+ an array is not passed by reference if function's signature does not declares the variable as a reference. So in general function(&$var) !== function($var). As example see: comment on signatures

I promess i'll publish a full list of not matching declarations views objects that needs work.

hope this message helps to work around

I'm moving my drupal 6 sites to a new server & I'm getting these errors...

Declaration of views_plugin_row::options_submit() should be compatible with views_plugin
and
Non-static method view::load() should not be called statically

I am going to have to patch views with the patch on #11?
I've never really patched a module before is there a good tutorial on how to do it?

This seems a big hassle. Does this mean my site is broken?

Hi Vayira. Applying a patch is pretty simple. See for example https://www.drupal.org/patch/apply
You can reverse the patch (see https://www.drupal.org/patch/reverse)
And to be sure, you should think of backing up everything before doing something, of course ;)

I don't think your site is broken. We've that sort of message on some site in (relative) heavy production, everything is still working, don't worry.

Best
D

FYI: See #1543434: strict warnings with PHP 5.4.x.

PS! There is an unannounced dev release that you can download from https://www.drupal.org/node/95897

Thanks for your replies.

dbourrion - it's good to know you don't have problems in spite of the errors. Any idea what kind of problems could I expect from the those errors? If the functionality of my sites isn't effected I could live with the error messages I guess.

hansfn - thanks for those links, but I must confess they don't inspire confidence. I'd like to feel I've made changes that I can rely on for a production site.

Same "strict warning" encountered too, server is running on PHP 5.5.9. Any reliable patch can be used for production site so far?

I applied the patch from #11 and the (#26) linked patch from https://www.drupal.org/node/893128#comment-5680104 (#28) but still have 2 warnings:

strict warning: Declaration of content_handler_field_multiple::pre_render() should be compatible with views_handler_field::pre_render(&$values) in Unknown on line 0.

strict warning: Declaration of date_handler_field_multiple::pre_render() should be compatible with content_handler_field_multiple::pre_render($values) in Unknown on line 0.

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!

Edit to add: Tried the Dev release 2 posts above but no luck. Nothing rendered with Views loads on my site :(

I do think there should be a core solution for these problems, that not only affect Views. That said, the best and easier solution I've found for this is to apply the module disable_messages, as explained in this article Selectively hide "strict warning" errors with PHP 5.4, Drupal 6.x with Disable Messages module.

That's like using band-aid instead of fixing the root of the issue. :(
...and this issue still exists since 2009....seriously?!!

I think this issue covered by the patch that's been committed at #1543434: strict warnings with PHP 5.4.x.

Thanks so much for the update on this! I am still experiencing one warning, in views_attach. I don't know if it is the views module or not. Here's a link to the issue:

Views_Attach strict warnings with PHP 5.4.x

FOLLOWUP:

Actually, the current release, 6.x-2.18 2015-Feb-11, still produces strict warnings on PHP 5.4x:

strict warning: Declaration of views_handler_filter_node_status::operator_form() should be compatible with views_handler_filter::operator_form(&$form, &$form_state) in sites/all/modules/views/modules/node/views_handler_filter_node_status.inc on line 13.

strict warning: Declaration of date_handler_field_multiple::pre_render() should be compatible with content_handler_field_multiple::pre_render($values) in sites/all/modules/date/date/date_handler_field_multiple.inc on line 185.

strict warning: Declaration of uc_views_handler_field_money_amount::options() should be compatible with views_object::options() in sites/all/modules/uc_views/views/uc_views_handler_field_money_amount.inc on line 36.

strict warning: Declaration of uc_views_handler_field_cart_user::init() should be compatible with views_handler_field::init(&$view, $options) in sites/all/modules/uc_views/views/uc_views_handler_field_cart_user.inc on line 78.

strict warning: Declaration of views_handler_field_user_name::init() should be compatible with views_handler_field_user::init(&$view, $data) in sites/all/modules/views/modules/user/views_handler_field_user_name.inc on line 61.

strict warning: Declaration of semanticviews_plugin_style_default::options() should be compatible with views_object::options() in sites/all/modules/semanticviews/semanticviews_plugin_style_default.inc on line 232.

strict warning: Declaration of views_attach_plugin_display_node_content::options_submit() should be compatible with views_plugin_display::options_submit(&$form, &$form_state) in sites/all/modules/views_attach/views_attach_plugin_display_node_content.inc on line 248.