Problem/Motivation

We have a view of nodes in a customer project that gives PHP fatal errors if we view it in Finnish, it works fine in English.

When using XDEBUG to haver a looking at the line in question, I notice that the only variables available in $options are label, id and exclude (which is ""). I added a !empty check (dumb patch attached) and now I don't get a white screen. YMMV.

2016/02/15 15:17:35 [error] 1090#1090: *11450 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Unsupported operand types in /vagrant/drupal/web/core/modules/views/src/Plugin/views/field/FieldPluginBase.php on line 1168
PHP message: PHP Stack trace:
PHP message: PHP   1. {main}() /vagrant/drupal/web/index.php:0
PHP message: PHP   2. Drupal\Core\DrupalKernel->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/index.php:19
PHP message: PHP   3. Stack\StackedHttpKernel->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/Core/DrupalKernel.php:637
PHP message: PHP   4. Drupal\Core\StackMiddleware\NegotiationMiddleware->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/vendor/stack/builder/src/Stack/StackedHttpKernel.php:23
PHP message: PHP   5. Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php:55
PHP message: PHP   6. Drupal\page_cache\StackMiddleware\PageCache->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:51
PHP message: PHP   7. Drupal\page_cache\StackMiddleware\PageCache->pass($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:82
PHP message: PHP   8. Drupal\Core\StackMiddleware\KernelPreHandle->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:103
PHP message: PHP   9. Drupal\Core\StackMiddleware\Session->handle($request = *uninitialized*, $type = *uninitialized*, $catch = *uninitialized*) /vagrant/drupal/web/core/lib/Drupal/C

Comments

badrange created an issue. See original summary.

badrange’s picture

badrange’s picture

StatusFileSize
new29.23 KB

Attaching the exported view in question

dawehner’s picture

Status: Active » Needs review

Status: Needs review » Needs work
badrange’s picture

Status: Needs work » Active
StatusFileSize
new655 bytes

This patch will hopefully apply, made from Drupal's root directory and not core.

badrange’s picture

Status: Active » Needs review

Trying again with new patch

cilefen’s picture

Priority: Normal » Major

This should be Major priority.

dawehner’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

I fear when we have a fatal we should add a test to ensure we don't reintroduce this problem.

badrange’s picture

That is very understandable. Now the question is, how in the world can we reproduce this error with test code - I don't even know *exactly* how it is caused.

Quick background info: The product content type only has Finnish products, and the fatal happens when looking at the view in English which is the default language of the site. I'll add this bit to the issue summary.

badrange’s picture

Hang on, it is more complicated than that; the product can be translated, but it references nodes of untranslatable content types (which have authors preferred language as language) that are also listed on the view.

And now that the project has moved a bit forward, this has changed, fantastic. We are in a bit of a rush, I hope someone beats me to creating a test case for this before I can find the time :)

dawehner’s picture

We are in a bit of a rush

Yeah no worries, I'm just always a bit reluctant to such changes, as checking stuff like that, often hides bugs somewhere more up the stack.

badrange’s picture

I agree 100% with that, that is why I called my patch a dumb patch, because it did feel like glossing over an underlying problem. Crossing my fingers that someone encounters the same problem, googles the error message, finds this issue and solves it by the time I get my head above water.

alexpott’s picture

Issue tags: +Triaged core major

Discussed with @xjm and @catch. We agree that this is major because this results in an exception through normal usage of views.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sebcorbin’s picture

Tested patch manually on the same problem (with an admin/people/list view), works fine.

FrenchBarbu’s picture

Got the same issue on /admin/content
Patch works fine. Thx !

alexpott’s picture

@FrenchBarbu so do you have any idea how to reproduce the error so we can add a test?

dawehner’s picture

Status: Needs work » Postponed (maintainer needs more info)

So let's make that clear with a different status of the issue

Anonymous’s picture

Having the same problem as #17 I applied the patch manually on Drupal version 8.1.3 with migrated content from Drupal 7. Had success. Thanks.!

badrange’s picture

I think the issue with this bug is that it is difficult to find out how to reproduce. What kind of logging could we add to the patch (for development sites etc), helping us to figure out the cause?

willwh’s picture

StatusFileSize
new30.12 KB

Hi Guys,

I'm running in to an issue with this. I have a view that displays correctly in English. Prior to applying the patch, Japanese and Chinese translations of this view throw the error reported in this issue.

With the patch applied, the table has an additional column header with no data in any of the rows, when viewed in Japanese or Chinese.

The site's default language is English.

I've attached the view, and if anyone has an advice on how to debug this, I'm all ears. xdebug is ready and waiting ;)

willwh’s picture

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

I need to confirm I can reproduce this.... but I tracked down my additional column in the view problem.

The view in question had a field, that had been translated, and then deleted. The translation itself was not deleted and still in the config table.

I did a quick and dirty update of the config table in question with a query, and everything seems to be working well, with the patch above applied, so I think the problem I was running in to, may be a different issue.

lendude’s picture

dawehner’s picture

It actually is indeed. I had the same issue when I opened up this, now critical, issue, but rather tried to track it down properly

willwh’s picture

Yep - I opened this; https://www.drupal.org/node/2750167 and it's been closed as a duplicate. Thanks for your input guys, and apologies I didn't get back to update this until now.

alexpott’s picture

Status: Active » Closed (duplicate)
cparrish817’s picture

Just wanted to add a "me too" that this patch allows my /admin/content page to work again.