Hi,

After updating to Views 6.x-2.7 - I suddenly got Fatal Error messages on the site - "Fatal Error - Unsupported Operand Type ... handlers/views_handler_field.inc on line 460"

the following is the code in views_handler_field.inc - in function advanced_render:

...
function advanced_render($values) {
...
          $alter = $item + $this->options['alter'];
          $items[] = $this->render_text($alter);       
        }
...

I tried running the update.php script and then rechecked that the files were properly copied into the correct folders. Not sure what the problem is.

I had a backup copy of the file from the previous version and copied just that file into the handlers directory - and the error went away. Although I am thinking this would result in problems elsewhere.

I have searched the site for similar problems but other issues with this error are older threads and seem to be marked as fixed.

Anyone else with a similar experience?

Thanks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dagmar’s picture

Status: Active » Postponed (maintainer needs more info)

Can you export your view?

Probably it is related to the last changes made into views_handler_field.inc since 2.6 but I cannot replicate. So maybe is an special case.

dagmar’s picture

Note: Views 2.7 contains some rearrangment of the order of field rendering. While I didn't see any errors or hear of any errors due to this, it may affect some external style plugins. If you have a problem with how fields render and are using a non Views-core style, please doublecheck with the 'table' or 'unformatted' styles and see if the problem persists. If it does not, it may well be the style provided by a module.

Are you using an external views plugin?

h3000’s picture

FileSize
124.67 KB

Hi,

I have attached the view export - this view appears on the front page of the site. When navigating to pages with no views, the error does not appear. On pages with views, its just a white screen and the error message that appears.

Some views modules that are used are:
Filefield Podcast
Insert View
Views Bulk Operations
Views Exporter

Not sure if it was related but the database ended up having locked innodb tables - I had to reboot the server to recover the locked tables - then reverted back to last working views version.

Thanks for the speedy response.

dawehner’s picture

Status: Postponed (maintainer needs more info) » Active

Update status

oceanos’s picture

I get the same error when using i18ntaxonomyviews in order to get taxonomy terms translated in views...

see http://drupal.org/node/346028#comment-1784958

oceanos’s picture

Solved for i18taxonomyviews module - see http://drupal.org/node/346028#comment-2257386

VTM’s picture

Assigned: Unassigned » VTM

I got similar error msg.
I had a global field in the display: "View result counter".
When I removed it- the err msg gone, and the display is now OK, but without counting.

Anyone else had the same situation?

If so, a new issue should be opened.

weseze’s picture

I got the same error message.

I'm not using i18ntaxonomyviews and not using the View result counter. I've just commented out line 460 and set $alter = 0 and everything works fine again... What does this line of code actually do, if just hardcoding it to 0 works just fine?

I don't really have time to look into this atm, will report back if I've had some more time with this issue.

weseze’s picture

small correction on my above comment. Simply setting $alter=0 makes the fatal error go away, but some things don't work as expected anymore. For example outputtin taxonomy terms as links in a view, outputs them without links.

I've now changed line 460:
$alter = $item + $this->options['alter'];
to:
$alter = (array)$item + (array)$this->options['alter'];
and all is well now.

I don't know why any of those 2 variables are not arrays. My debugs show that sometimes one of the two was empty

h3000’s picture

Version: 6.x-2.7 » 6.x-2.8

Hi,

This error came up with the upgrade to 6.x-2.8 version of views.

the suggested fix in comment #9 worked though.

h3000’s picture

ok - I am not sure if this is related but I just went thru the views to check if there were other problems and I found that if you have views that have Taxonomy: All terms fields, these fields were just showing 1 character.

h3000’s picture

these are the values of $item and $alter variables in views where the Taxonomy:All Terms field is used:

$item = "Live Music" (one of the taxonomy terms used) - seems to be a string

$this->options['alter'] =

 Array
(
    [alter_text] => 0
    [text] => 
    [make_link] => 0
    [path] => 
    [alt] => 
    [link_class] => 
    [prefix] => 
    [suffix] => 
    [target] => 
    [trim] => 0
    [max_length] => 
    [word_boundary] => 1
    [ellipsis] => 1
    [strip_tags] => 0
    [html] => 0
    [help] => 
)
dagmar’s picture

Assigned: VTM » Unassigned
Status: Active » Postponed (maintainer needs more info)

@h3000: Thereis no relationship between this issue and posted in #11: Also you have created this one: #649822: Taxonomy:All Terms field only showing 1 character

@VTM: Can you please give us more information about how replicate this issue? If it is possible, describe an step by step situation and when errors occurs. Thanks!

VTM’s picture

Sorry pal.
I could not re-create this.
I'm using now ver 2.8.
Adding back the "views results counter" do not make any errors.
All good now.
I'll report if it comes again.

MANY THANKS !!!

merlinofchaos’s picture

Status: Postponed (maintainer needs more info) » Fixed

Status: Fixed » Closed (fixed)

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

mr.baileys’s picture

Status: Closed (fixed) » Closed (duplicate)

Actually, I think this is yet unresolved but also has the same cause as #649822: Taxonomy:All Terms field only showing 1 character so marking this duplicate as I think resolving that issue will also fix this one. (See my reasoning in the other issue on why I think these are related)

weseze’s picture

mr.baileys: the fix that I recommended in #9 is the cause of the problem with the Taxonomy:All Terms fields in Views.
I've made a quickfix that seems to be working correctly for me:

          if (!is_array($item))
          {
              $item = array(
                'alter_text' => $item,
                'text' => $item,
              );
          }
          $alter = $item + $this->options['alter'];
          $items[] = $this->render_text($alter);

This fix should work for now, but is not very clean :)

merlinofchaos’s picture

Status: Closed (duplicate) » Active

Ok so I don't think $item should never NOT be an array. If it is not an array, we need to discern what circumstances are causing this. It may be a bug in a module that's not correctly setting data; this seems likely since this is only reproducible on a small set of systems. All related to i18ntaxonomy?

merlinofchaos’s picture

Status: Active » Postponed (maintainer needs more info)

Hm. I made this active, but I really can't do anything without knowing if it's module related. My guess is that it is.

weseze’s picture

Could you provide some code to put at or arround line 460 so I can get some debugging information for you?

esmerel’s picture

Status: Postponed (maintainer needs more info) » Active
iamjon’s picture

Status: Active » Postponed (maintainer needs more info)

mr.baileys,
wesley_2mpact,
have you found any solutions to the issue? if so please post so others may benefit. otherwise please post more information so we can
I am marking this issue as postponed.

weseze’s picture

I have got this patch up and running on sites where the problem pops up.

iamjon’s picture

wesley_2mpact,
Thank you very much for your patch. I talked to merlinofchaos about it on irc, it seems the patch is effectively covering up the underlying error.
if possible could you export your view and provide step by step instructions how we can recreate the bug so we can try get to the bottom of it.

dawehner’s picture

So to find an issue goto the line in the handlers/views_handler_field.inc file and use something like this

if (!is_array($item)) {
  dsm(views_trace());
}

Once you have this you will get a backtrace, which allows to find out which module provides this bad variable.

iamjon’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

I'm marking this as closed from lack of activity. Please feel free to reopen with more information.

sja1’s picture

Title: Fatal Error - Unsupported Operand Type - ...handlers/views_handler_field.inc - line 460 » Fatal Error - Unsupported Operand Type - ...handlers/views_handler_field.inc - line 1061
Version: 6.x-2.8 » 7.x-3.7
Priority: Critical » Normal
Issue summary: View changes
Status: Closed (cannot reproduce) » Active
FileSize
13.96 KB

I'm getting this same error on a new D7 site I am building. Adding the following lines just before line 1061 seems to fix the problem.

			<?php
if (!is_array($item)) {
			  print_r(views_trace());
			  $item=array();
			}
?>

I've uploaded a views_trace as per dawehner's request in comment #26.

sja1’s picture

I was able to track the problem down to a custom module I wrote that implements hook_views_post_execute. Within the hook I was modifying the value of one of the fields returned by a specific view. I found an error in the hook code that was causing an array to be replaced with a non-array value. Once I fixed the code to replace the array with another array with the same structure, the problem went away.