For those that prefer to see the views-2.x-dev.php_.5.4.x.patch live:

diff -Naur old/views/css/views.css new/views/css/views.css
--- old/views/css/views.css	2012-04-18 22:52:59.000000000 +0930
+++ new/views/css/views.css	2012-04-16 02:51:22.000000000 +0930
@@ -4,7 +4,7 @@
 }
 
 .views-exposed-form .views-exposed-widget .form-submit {
-  margin-top: 1.6em;
+/*  margin-top: 1.6em;  Peter: 2012 */
 }
 
 .views-exposed-form .form-item,
diff -Naur old/views/handlers/views_handler_filter_boolean_operator.inc new/views/handlers/views_handler_filter_boolean_operator.inc
--- old/views/handlers/views_handler_filter_boolean_operator.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/handlers/views_handler_filter_boolean_operator.inc	2012-04-23 18:24:10.000000000 +0930
@@ -108,7 +108,7 @@
     }
   }
 
-  function value_validate(&$form, &$form_state) {
+  function value_validate($form, &$form_state) {              // Peter PHP 5.4.x: change '&$form' to '$form'
     if ($form_state['values']['options']['value'] == 'All' && empty($form_state['values']['options']['expose']['optional'])) {
       form_set_error('value', t('You must select a value unless this is an optional exposed filter.'));
     }
diff -Naur old/views/handlers/views_handler_filter.inc new/views/handlers/views_handler_filter.inc
--- old/views/handlers/views_handler_filter.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/handlers/views_handler_filter.inc	2012-04-23 18:21:52.000000000 +0930
@@ -101,7 +101,7 @@
   /**
    * Simple validate handler
    */
-  function options_validate(&$form, &$form_state) {
+  function options_validate($form, &$form_state) {   // Peter PHP 5.4.x: changed '&$form' to '$form'
     $this->operator_validate($form, $form_state);
     $this->value_validate($form, $form_state);
     if (!empty($this->options['exposed'])) {
@@ -113,8 +113,8 @@
   /**
    * Simple submit handler
    */
-  function options_submit(&$form, &$form_state) {
-    unset($form_state['values']['expose_button']); // don't store this.
+  function options_submit($form, &$form_state) {     // Peter PHP 5.4.x: changed '&$form' to '$form'
+    unset($form_state['values']['expose_button']);   // don't store this
     $this->operator_submit($form, $form_state);
     $this->value_submit($form, $form_state);
     if (!empty($this->options['exposed'])) {
diff -Naur old/views/handlers/views_handler_filter_numeric.inc new/views/handlers/views_handler_filter_numeric.inc
--- old/views/handlers/views_handler_filter_numeric.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/handlers/views_handler_filter_numeric.inc	2012-04-23 15:18:37.000000000 +0930
@@ -116,6 +116,7 @@
   }
   /**
    * Provide a simple textfield for equality
+   * Peter: 22/04/12 - Modifications for PHP 5.4.x
    */
   function value_form(&$form, &$form_state) {
     $form['value']['#tree'] = TRUE;
@@ -189,11 +190,13 @@
         $form['value']['min'] += $dependency;
         $form['value']['max'] += $dependency;
       }
-      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['min'])) {
-        $form_state['input'][$identifier]['min'] = $this->value['min'];
-      }
-      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['max'])) {
-        $form_state['input'][$identifier]['max'] = $this->value['max'];
+      // Peter: Updated for PHP 5.4.x = Illegal string offet 'min' - next line
+      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['min']) && isset($this->value['min']) && is_array($this->value['min'])) {
+          $form_state['input'][$identifier]['min'] = $this->value['min'];
+      }
+      // Peter: Updated for PHP 5.4.x = Illegal string offet 'max' - next line
+      if (!empty($form_state['exposed']) && !isset($form_state['input'][$identifier]['max']) && isset($this->value['max']) && is_array($this->value['max'])) {
+          $form_state['input'][$identifier]['max'] = $this->value['max'];
       }
 
       if (!isset($form['value'])) {
diff -Naur old/views/includes/view.inc new/views/includes/view.inc
--- old/views/includes/view.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/includes/view.inc	2012-04-23 21:24:04.000000000 +0930
@@ -91,7 +91,7 @@
    * Note: In PHP5 this should be static, but PHP4 doesn't support static
    * methods.
    */
-  function db_objects() {
+  public static function db_objects() {                      // Peter PHP 5.4.x: added 'public static'
     return array('display');
   }
 
@@ -1339,7 +1339,7 @@
    *  If TRUE, reset this entry in the load cache.
    * @return A view object or NULL if it was not available.
    */
-  function &load($arg, $reset = FALSE) {
+  public static function &load($arg, $reset = FALSE) {    // Peter PHP 5.4.x: changed 'function &load()' to 'public static function &load()'
     static $cache = array();
 
     // We want a NULL value to return TRUE here, so we can't use isset() or empty().
@@ -1392,7 +1392,7 @@
    * that would be very slow.  Buiding the views externally from unified queries is
    * much faster.
    */
-  function load_views() {
+  public static function load_views() {                                      // Peter PHP 5.4.x: Added 'public static'
     $result = db_query("SELECT DISTINCT v.* FROM {views_view} v");
     $views = array();
     $vids = array();
diff -Naur old/views/modules/taxonomy/views_handler_filter_term_node_tid_depth.inc new/views/modules/taxonomy/views_handler_filter_term_node_tid_depth.inc
--- old/views/modules/taxonomy/views_handler_filter_term_node_tid_depth.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/modules/taxonomy/views_handler_filter_term_node_tid_depth.inc	2012-04-23 18:29:18.000000000 +0930
@@ -6,7 +6,7 @@
  * because it uses a subquery to find nodes with
  */
 class views_handler_filter_term_node_tid_depth extends views_handler_filter_term_node_tid {
-  function operator_options() {
+  function operator_options($which = 'title') {        // Peter PHP 5.4.x: changed operator_options() to operator_options($which = 'title')
     return array(
       'or' => t('Is one of'),
     );
diff -Naur old/views/modules/taxonomy/views_handler_filter_term_node_tid.inc new/views/modules/taxonomy/views_handler_filter_term_node_tid.inc
--- old/views/modules/taxonomy/views_handler_filter_term_node_tid.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/modules/taxonomy/views_handler_filter_term_node_tid.inc	2012-04-23 18:27:43.000000000 +0930
@@ -173,7 +173,7 @@
     }
   }
 
-  function value_validate(&$form, &$form_state) {
+  function value_validate($form, &$form_state) {                     // Peter PHP 5.4.x: change '&$form' to '$form'
     // We only validate if they've chosen the text field style.
     if ($this->options['type'] != 'textfield') {
       return;
diff -Naur old/views/plugins/views_plugin_row_fields.inc new/views/plugins/views_plugin_row_fields.inc
--- old/views/plugins/views_plugin_row_fields.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/plugins/views_plugin_row_fields.inc	2012-04-23 18:34:07.000000000 +0930
@@ -60,8 +60,7 @@
    * Perform any necessary changes to the form values prior to storage.
    * There is no need for this function to actually store the data.
    */
-  function options_submit($form, &$form_state) {
+  function options_submit(&$form, &$form_state) {            // Peter PHP 5.4.x: changed '$form' to '&$form'
     $form_state['values']['row_options']['inline'] = array_filter($form_state['values']['row_options']['inline']);
   }
 }
-
diff -Naur old/views/plugins/views_plugin_row.inc new/views/plugins/views_plugin_row.inc
--- old/views/plugins/views_plugin_row.inc	2012-04-18 22:52:59.000000000 +0930
+++ new/views/plugins/views_plugin_row.inc	2012-04-23 18:32:42.000000000 +0930
@@ -98,13 +98,13 @@
   /**
    * Validate the options form.
    */
-  function options_validate($form, &$form_state) { }
+  function options_validate(&$form, &$form_state) { }      // Peter PHP 5.4.x: changed '$form' to '&$form'
 
   /**
    * Perform any necessary changes to the form values prior to storage.
    * There is no need for this function to actually store the data.
    */
-  function options_submit($form, &$form_state) { }
+  function options_submit(&$form, &$form_state) { }        // Peter PHP 5.4.x: changed '$form' to '&$form'
 
   function query() {
     if (isset($this->base_table) && isset($this->options['relationship']) && isset($this->view->relationship[$this->options['relationship']])) {
diff -Naur old/views/views.module new/views/views.module
--- old/views/views.module	2012-04-18 22:52:59.000000000 +0930
+++ new/views/views.module	2012-04-23 18:42:53.000000000 +0930
@@ -901,7 +901,7 @@
  *   A reference to the $view object. Use $reset if you're sure you want
  *   a fresh one.
  */
-function views_get_view($name, $reset = FALSE) {
+function views_get_view($name, $reset = FALSE) {     // Peter PHP 5.4.x: changed function 'views_get_view()' to 'public static function views_get_view()'
   views_include('view');
   $view = view::load($name, $reset);
   $default_view = views_get_default_view($name);

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

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

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

Okay, so you want to provide FATAL errors to people using PHP4 because you get E_STRICT warnings with PHP5?

This makes sense...how?

Oh and at the same time, you use derisive language when discussing my decision to disagree. That's awesome.

Oh here's a hint: Turn off E_STRICT warnings. That's the only solution that works for both PHP4 and PHP5.

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

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

Refer #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.

Refer #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!

Checking on the Views Module page, I see this:

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.

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

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

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

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

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

I 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?

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

1. Drupal 6 is a stable release of Drupal that requires PHP 4.4. We do not change the requirements of stable releases. We do not break peoples' existing sites for the sake of new ones.
2. PHP 5.4 did not exist when Drupal 6 was released, and so it is therefore unreasonable to expect 5.4 compatibility in D6.
3. Drupal 6 is over four years old.

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

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

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

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

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

The last submitted patch, 23: 1543434_views_6x2x_php54_compat.patch, failed testing.

I 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

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

Hi, please find a patch file to get rid of the warnings related to the views while using php5.4.

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

I'm not sure if there's tests for D6, but at a minimum this does "Need review" based on #28.

The last submitted patch, 28: views-php5.4-1543434-28.patch, failed testing.

28: views-php5.4-1543434-28.patch queued for re-testing.

The last submitted patch, 28: views-php5.4-1543434-28.patch, failed testing.

Even if that patch passes testing, it definitely needs rework. It suffers from the comments / code attribution issue just like the original patch.

Created 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

Set to needs review...

The last submitted patch, 35: views-make-it-work-in-PHP5.4-35-1543434-6.x-2.16.patch, failed testing.

Same as #35, typo fixed!

#38 patch solved all strict warning exept 2:

strict warning: Non-static method view::load_views() should not be called statically in /xxx/sites/all/modules/views/views.module on line 864.
strict warning: Non-static method view::db_objects() should not be called statically in xxx/sites/all/modules/views/includes/view.inc on line 1417.
warning: Creating default object from empty value in /xxx/sites/all/modules/views/includes/handlers.inc on line 652.

Tryed on two different sites with same effect

jbatista queued 38: views-make-it-work-in-PHP5.4-38-1543434-6.x-2.16.patch for re-testing.

1. +++ b/handlers/views_handler_argument.inc
   @@ -45,7 +45,7 @@ class views_handler_argument extends views_handler {
   -  function init(&$view, &$options) {
   +  function init(&$view, $options) {
   

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

2. +++ b/includes/handlers.inc
   @@ -514,7 +514,7 @@ class views_many_to_one_helper {
   -  function option_definition(&$options) {
   +  public static function option_definition(&$options) {
        $options['reduce_duplicates'] = array('default' => FALSE);
      }
    
   

   Thats indeed fine.

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

fix the 2 mentioned in #39

I'm not sure the tpl one is generic? Are you sure that's not a site bug? setting to needs review for further feedback

Committed and pushed...

Is 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

Hi
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

It'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.

Ok, got it - many thanks

@hansfn - can you post the specific error messages that you get?

The init error message is the standard one:

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.

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.

There are so many patches here. I wonder which one is the complete one ? I need to patch my production site.

I 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:

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!

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

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

Thanks 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 :)

Will the latest version 6.x-3.0 solve the STRICT issue completely ?

I presume there'll be a new release on the 6.x-2.x branch once the remaining problem is fixed?

FYI: 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?)

Let'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.

Automatically closed - issue fixed for 2 weeks with no activity.

Committed the patch to 6.x-3.x as well.

Marked PHP 5.4.x + compatibility as a duplicate and closed.

FYI, for anyone coming across this, there are many related issues tagged "PHP 5.4".