It's not a good idea to turn the warnings off. There are just a bunch of dicky little code problems in Views that need to be fixed. Here are the ones I'm seeing:

strict warning: Declaration of views_handler_field::query()
should be compatible with views_handler::query($group_by = false)
in handlers/views_handler_field.inc on line 1148

strict warning: Declaration of views_handler_field_broken::query()
should be compatible with views_handler_field::query($group_by = false)
in handlers/views_handler_field.inc on line 1173

strict warning: Declaration of views_handler_sort::options_validate()
should be compatible with views_handler::options_validate($form, &$form_state)
in handlers/views_handler_sort.inc on line 165

strict warning: Declaration of views_handler_sort::options_submit()
should be compatible with views_handler::options_submit($form, &$form_state)
in handlers/views_handler_sort.inc on line 165

strict warning: Declaration of views_handler_sort::query()
should be compatible with views_handler::query($group_by = false)
in handlers/views_handler_sort.inc on line 165

strict warning: Declaration of views_handler_filter::query()
should be compatible with views_handler::query($group_by = false)
in handlers/views_handler_filter.inc on line 599

strict warning: Declaration of views_plugin_query::options_submit()
should be compatible with views_plugin::options_submit($form, &$form_state)
in plugins/views_plugin_query.inc on line 181

strict warning: Declaration of views_plugin_row::options_submit()
should be compatible with views_plugin::options_submit($form, &$form_state)
in plugins/views_plugin_row.inc on line 136

strict warning: Declaration of views_plugin_pager_none::post_execute()
should be compatible with views_plugin_pager::post_execute(&$result)
in plugins/views_plugin_pager_none.inc on line 69

There are probably other declarations that need fixed that aren't causing errors to pop up right now because I'm not using those handlers in my current project. Working on a patch, but first I'm gonna take the dog for walk. Back soon.

Attaching a patch which clears up all of the warnings for me. Please test and make sure it takes care of all the warnings you are seeing!

I used find and sed to automatically make the following replacements in all files:

-  function query() {
+  function query($group_by = FALSE) {
-  function options_submit(&$form, &$form_state) {
+  function options_submit($form, &$form_state) {
-  function options_validate(&$form, &$form_state) {
+  function options_validate($form, &$form_state) {
-  function post_execute($result) {
+  function post_execute(&$result) {

Related issue in CCK.

You beat me to it! After some diff'ing and much double-checking, here are some more changes on top, from my unreleased patch.

Great job and would RTBC, but it's got to stay "needs review" until you check my work back. I've been using this for a while, so I trust it with my life, and many common modules.

I have some patches for other modules, against views-6-.x-3.x with these patches, which I will try to get together and in shape (see related issue)

[prefix]-5.patch is freshly against 6.x-3.x (see next comment, do not use [prefix]-4.patch)
[prefix]-1-hotfix.patch is against your patch... for convenience and reference

Additions:

• post_execute() given a default value for the $result argument, since it's called without one twice in includes/views.inc
• post_execute() now declared with $result argument in includes/views.inc
• 4 more pre_render () $results arguments renamed to $values
• 2 more options_submit() $form arguments changed to byval
• option_definition() had a space before paren; removed

Sorry another patch got mixed in... I was having an glitch in git diff, "refname 6.x-3.x ambiguous" when running diff against a local clone of the 6.x-3.x branch.

Anyway worked around it for now by cloning it and made a clean patch. Do not use the main patch in comment #4! (The hotfix will still work)

Okay, I looked thru your final patch and eveything looks fine. I applied the "hotfix" patch on top of my patch and tested, nothing broke. Good to go I'd say.

This needs to be added to 6.x-2.x too.

Backported to 6.x-2.x.

The patch in #5 didn't update two of the local variables after the arguments were renamed, here's an improved patch.

Closed a duplicate: #2144749: fix notices and missing empty text

@Steve: I'm currently using this patch on the current 6.x-3.x-dev release, along with several other patches that are indicated in the "3.3 release" issue. If you're at all uncertain as to what you're doing you should wait until we can get some of them committed.

Closed a duplicate: #2019795: Multiple php errors "Declaration of views..."

Here's an RTBC for #10 (and a hotfix for anyone that was using #5)

Talked with @damiankloip about it and we came to the conclusion that adding $group_by = FALSE
is the wrong approach for multiple reasons:

• Its not how D8 looks like, you can always use $this->view->display_handler->use_group_by() if you need the information.
• The more we add it, the more strict notices we potentially get from custom / other contrib code
• Even we pass in $group_by we don't necessarily need it to be part of views_handler::query() by default, this allows to get rid of the strict notices while still allowing people
  to deal with it, see patch

FYI, I applied the patch from #18 in a test environment, but I'm still seeing the following errors:

Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in /home/****/test/sites/all/modules/views/plugins/views_plugin_style_default.inc on line 24.

Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/****/test/sites/all/modules/views/handlers/views_handler_filter.inc on line 599.

Declaration of content_handler_field::element_type() should be compatible with views_handler_field::element_type($none_supported = false, $default_empty = false, $inline = false) in /home/****/test/sites/all/modules/cck/includes/views/handlers/content_handler_field.inc on line 228.

Non-static method view::load() should not be called statically in /home/****/test/sites/all/modules/views/views.module on line 1118.

The main objection to using $group_by = FALSE seems to be that it may generate php warnings in custom code or contrib modules. So what? They can fix their code too! With small, easy patches.

The other objections don't make sense. It doesn't look like what's done in D8? Who cares? And the last one, what does it even mean? Doesn't matter! The previous patch here fix the problems and was reviewed. I suggest: apply it and close this issue.

Reviewed & tested by the community:
#11: views-n2411093-10.patch

Additional info re: my #20 comment - I applied the #18 patch to Views 6.x-3.2. Looking at the #11 patch, I see that it also does not handle most if not all of the problems I still saw after applying the #18 patch.

@LNakamura always apply the patch to latest dev

You mean I got all flustered for no good reason? I apologize. I took the report from LNakamura as an indication that the new patch here was broken. Will test it myself when I get a chance. (-_-)

@steinmb - you're right, my bad!

@SeanA - sorry for the roller coaster ride here, but: after deleting my test environment, restoring my backup and bringing core and contrib modules up-to-date as I had previously, I also updated Views to 6.x-3.x-dev, then applied the patch from #18, flushed the cache, and truncated the watchdog table. I then cleared the cache again, but still subsequently found the 4 errors I reported above. They get repeated for what seems like any interaction with the site.

Additionally, I discovered 2 errors which I either didn't notice before, or which are new (they are the first entries in the new log, and only appear once - so far):

Non-static method view::db_objects() should not be called statically in /home/****/test/sites/all/modules/views/includes/view.inc on line 1641.

Non-static method view::load_views() should not be called statically in /home/****/test/sites/all/modules/views/views.module on line 1076.

im getting the same problem in php 5.5 and the patches are not working. or maybe im lost.

I' ve created this patch to fix these PHP strict warnings

Ignoring patch at #28.

LNakamura, it seems like you were still using an older version of Views-6.x-3.x. Those problems have already been fixed.

OK! Reviewed patch at #18 (2411093-18.patch). Getting rid of $group_by = FALSE in the base handler declaration totally makes sense. Everything else checks out; all of the other fixes from the previous patches are included.

Use patch at #18. It works. =)

@Steve -cc thanks for testing. Can you verify that this is on a clean D6 installation with only views 6.x-3.x-dev + #18 installed and no other modules extending views?

Just applied patch #18 on latest 6.x-3.x-dev (PHP 5.6.13RC1) and it cleared up all views-related warnings. Thanks!

Steve, I believe if you clear the site's caches, including the Views' cache, the first error should go away. The other 2 warnings are generated by the CCK module, see #2327005: E_STRICT compliance. The fixes in the patch there (#15) are small and simple enough that you can do them by hand.

New patch based on #18 which fixes that final Views warning encountered by Steve-cc, and the same fix in a couple other places. If you've already applied #18, you can use the interdiff patch to apply these additional fixes.

Steve, yep, those files contain the extra fixes in the interdiff patch. So it works for you, thanks for testing.

For the warnings in CCK, see #2327005: E_STRICT compliance. The warning that appears to be in Date will also be fixed if you make the changes there. (Date module is already doing it right, CCK needs to catch up.)

To just make these sorts of warnings go away, in all cases, with one simple fix, see #1954296: Restore original D6 behaviour to prevent logging E_STRICT warnings.

I inherited an out of date drupal 6 site;
encountered these issues with views and drupal 6.37.

Updated to the dev version of views: 6.x-3.x-dev
Read through steve's postings #42.
Ran SeanA's patch in #41.

These cleared my strict / static error messages.
Thank you very much.

Tested #41 and it looks good to me. All that's left is CCK and the date module.

Yes, steinmb, I have three remaining errors relating to "strict warning"

Two errors concern cck:
1. sites/all/modules/cckincludes/views/handlers/content_handler_field.inc line 228 ( at the very end)
and
2. sites/all/modules/cckincludes/views/handlers/content_handler_field_multiple.inc line 321 (at the very end )

the third strict warning relates to the date module
3. sites/all/modules/date/date/date_handler_field_multiple.inc on line 185 (at the very end).

I have a slideshow and a calendar that are not rendering.
thanks for the eyeball here.

installed:
Drupal core 6.37
CCK 6.x-3.0-alpha4
Date 6.x-2.10+2-dev (2015-May-09)
FileField 6.x-3.13
ImageField 6.x-3.11
Slideshow 6.x-2.1
Views 6.x-3.2+7-dev (2015-Oct-23)
Views Slideshow 6.x-3.0+21-dev (2013-Oct-18)

Full error message:

• strict warning: Declaration of content_handler_field::element_type() should be compatible with views_handler_field::element_type($none_supported = false, $default_empty = false, $inline = false) in /sites/all/modules/cck/includes/views/handlers/content_handler_field.inc on line 229.
• 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 322.
• 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.

Thanks for testing. For the warnings in CCK, see #2327005: E_STRICT compliance. There is a patch ready to go. The warning which appears to be in Date is actually in CCK and will also be fixed if you apply that patch.

SeanA - it's possible I was using an older version of Views-6.x-3.x, though I have no way of verifying that at this point since I had restored the system to its prior state after my previous attempt at applying patch #18. At any rate, I just updated to the very latest version of Views-6.x-3.x (as well as other contrib modules and core, like before), and still saw declaration incompatibility warnings proliferating. So I installed the CCK patch you describe here in #43, and that got rid of everything but this:

Declaration of views_slideshow_plugin_style_slideshow::options_validate() should be compatible with views_plugin::options_validate($form, &$form_state) in /home/rureadyca/public_html/sites/all/modules/views_slideshow/views_slideshow_plugin_style_slideshow.inc on line 292.

Did I miss something else, or is this one not covered yet?

Thanks!!
Lee

LNakamura, that's a Views Slideshow issue: #2512896: PHP 5.4+ compatibility. Just a matter of removing an ampersand.

SeanA - thanks for the pointer!

Lee

Marked #653628: Declaration of views_handler_filter_many_to_one::init() should be compatible with that of views_handler_filter::init() as duplicate of this one. Initially that issue dealt with a different problem but the PHP strict warnings where discussed there too.

I am preparing a site with views 6.x-2.x to be updated to php 5.6. The 6.x-2.x patches here and in the other view issue are outdated. So I started to apply them manually. But I realized they change far to much, also the ones for views 6.x-3.x.

The changes in question are related to the following functions:

// case 1: $form passed by reference:
options_submit(&$form, &$form_state)
options_validate(&$form, &$form_state)
// case 2: $form passed by value (not by reference):
options_submit($form, &$form_state)
options_validate($form, &$form_state)

Looking at Drupal 7 version of these functions would suggest to change the $form argument to a reference ($form => &$form), as there $form is always passed by reference. But if we do that, we (unnecessarily) need to change a lot of other modules where $form is not passed by value (which currently are working fine with php 5.4 and above).

So when do we need to pass $form by reference?

In views 6.x-2.x-dev it's only necessary for views-plugins, as in views_plugin (views/includes/plugins.inc) $form is passed by reference, hence it needs to be passed by reference in all child classes:

function options_validate(&$form, &$form_state) { }
function options_submit(&$form, &$form_state) { }

Everywhere else, pass by value would be just fine.

In views 6.x-3.x-dev should be the same, but it's not, it's even worse and more confusing. There are some handler classes where $form is pass by reference and others not, same for plugins, but views_plugin (views/includes/plugins.inc) defines the option_submit and option_validate functions differently:

function options_validate(&$form, &$form_state) { }
function options_submit($form, &$form_state) { }

I suggest that both version of views in drupal 6 should work the same way and in this case 3.x should follow 2.x, so other modules could be compatible with both versions of views (usage of 6.x-2.x is much wider than 6.x-3.x).

This patch is for views 6.x-2.x-dev.

The patches here fix the problems in 6.x-3.x, and all of the changes are needed to make all of the warnings go away in this version.

Is 6.x-2.x still generating warnings? I'm not seeing any using the latest 6.x-2.x-dev. Looking through the issues, it seems that many if not all of the php compatibility problems have already been fixed there.

edit: It looks like the options_submit and options_validate declarations in 2.x do indeed need to be fixed in the same way as in the patches here for 3.x. To me it seems that the full range of fixes for 3.x need to be backported to 2.x, just like the patch in #9 does above. So, because #9 is outdated by the refinements in #18, #41 needs to be backported to 2.x-dev.

In views/includes/plugins.inc and in views/includes/handlers.inc, the declarations should look like this:

function options_validate($form, &$form_state)
function options_submit($form, &$form_state)

In 3.x, this is already how they are, for both plugins and handlers. But in 2.x, they need to be corrected in views/includes/plugins.inc (as in #9). Then both versions will be consistent.

@SeanA: Thanks for your comment. Indeed, the references in the patch of #52 aren't necessary. I can not reproduce how it came to this. So we do not need a patch for 6.x-2.x. Comparing to the patches there are just two little things left, see attached patch.

Do modules that worked with views 6.x-2.x also work with 6.x-3.x? If so than #52 would be true for 6.x-3.x and the patch needs to bee adapted to that. For example the calendar module, if it also compatible with views 6.x-3.x all declarations in common with views 6.x-2.x should be compatible.

Actually, the function options_validate declaration in plugins.inc was not already fixed in 3.x and is corrected in the patches here, making it consistent with what appears in handlers.inc as shown in #54.

The Calendar module doesn't have any issues related to this. Patches are already available for CCK and Views Slideshow (links to those issues are found in this thread). The patch for CCK fixes the one problem found in Date. Basically, other modules will have to fix their own problems after applying the Views fixes found here-- but that's not going to be necessary in most cases!

Bottom line: the full range of fixes in #41 need to be backported for 2.x. Restoring status.

@SeanA: I do not agree to change views 6.x-2.x, as you convinced me before that for that version everything is working well.

In #52 I had done some investigations, comparing also to views in D7. IMHO 6.x-3.x is not well, especially the views_plugin (views/includes/plugins.inc):

function options_validate(&$form, &$form_state) { }
function options_submit($form, &$form_state) { }

I don't see why the following change in #41 would be necessary. @SeanA: Why do you think it should be that way?:

-  function options_validate(&$form, &$form_state) { }
+  function options_validate($form, &$form_state) { }

This would be also valid, and much closer to views 6.x-2.x.

-  function options_submit($form, &$form_state) { }
+  function options_submit(&$form, &$form_state) { }

The issue in calendar module is #999514: Strict warning errors for views plugins. Declaration of calendar_plugin_display_page::options_submit() etc with the changes:

-  function options_submit($form, &$form_state) {
+  function options_submit(&$form, &$form_state) {

This seems confusing and was fixed in D7 by passing $form always by reference. Normally the lower version should follow the higher one by back-porting changes, but in this case I think it would be just fine to do it the other way around which may result in less problems and less changes in other modules, wouldn't it? I had a look at all options_validate and options_submit functions in views and my local installation, $form is not manipulated there, so passing it with or without reference, both would be fine.

D6 is now unsupported and it's quite possible none of these patches will ever be committed. But at least the fixes will be here to help people who want to take care of these php warnings on their own.

I applied the patch "#41 views-2411093-41.patch", it has solved most of the errors I was getting in dblog messages. But I am still getting following error in log messages. Can someone help me to resolve these errors?

Drupal: 6.38
PHP: 5.4

1)
Declaration of views_handler_field_user::init() should be compatible with views_handler_field::init(&$view, $options) in ...modules/views/modules/user/views_handler_field_user.inc on line 50.

2)
Non-static method view::load() should not be called statically in ...modules/views/views.module on line 1118.