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
Comment #2
badrange commentedComment #3
badrange commentedAttaching the exported view in question
Comment #4
dawehnerComment #6
badrange commentedThis patch will hopefully apply, made from Drupal's root directory and not core.
Comment #7
badrange commentedTrying again with new patch
Comment #8
cilefen commentedThis should be Major priority.
Comment #9
dawehnerI fear when we have a fatal we should add a test to ensure we don't reintroduce this problem.
Comment #10
badrange commentedThat 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.
Comment #11
badrange commentedHang 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 :)
Comment #12
dawehnerYeah 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.
Comment #13
badrange commentedI 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.
Comment #14
alexpottDiscussed with @xjm and @catch. We agree that this is major because this results in an exception through normal usage of views.
Comment #16
sebcorbin commentedTested patch manually on the same problem (with an admin/people/list view), works fine.
Comment #17
FrenchBarbu commentedGot the same issue on /admin/content
Patch works fine. Thx !
Comment #18
alexpott@FrenchBarbu so do you have any idea how to reproduce the error so we can add a test?
Comment #19
dawehnerSo let's make that clear with a different status of the issue
Comment #20
Anonymous (not verified) commentedHaving 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.!
Comment #21
badrange commentedI 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?
Comment #22
willwh commentedHi 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 ;)
Comment #23
willwh commentedComment #24
willwh commentedI 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.
Comment #25
lendudeThis sounds like a duplicate of #2750167: Config translation synchronization fails
Comment #26
dawehnerIt actually is indeed. I had the same issue when I opened up this, now critical, issue, but rather tried to track it down properly
Comment #27
willwh commentedYep - 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.
Comment #28
alexpott#2750167: Config translation synchronization fails has been committed. See you all in #2776357: Upgrade path for Config translation synchronization failure to write the upgrade path and test for it.
Comment #29
cparrish817 commentedJust wanted to add a "me too" that this patch allows my /admin/content page to work again.