Problem/Motivation
TypeError: Argument 1 passed to Drupal\ui_patterns_views\Plugin\views\row\Pattern::isFieldVisible() must be an instance of Drupal\views\Plugin\views\field\FieldPluginBase, null given, called in /var/www/html/docroot/modules/contrib/ui_patterns/modules/ui_patterns_views/ui_patterns_views.module on line 42 in Drupal\ui_patterns_views\Plugin\views\row\Pattern->isFieldVisible() (line 145 of /var/www/html/docroot/modules/contrib/ui_patterns/modules/ui_patterns_views/src/Plugin/views/row/Pattern.php)
Steps to reproduce
1. Enable "UI Patterns Views" module.
2. Select pattern in existing View.
3. Configure field mapping.
Proposed resolution
1. Add validation to check if $field and $field_output are not empty.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | interdiff_334405-2-3344405-7.txt | 758 bytes | riyadongre |
| #7 | 3344405-7.patch | 1.23 KB | riyadongre |
| #2 | 3344405-2.patch | 997 bytes | shashwat purav |
Issue fork ui_patterns-3344405
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
shashwat purav commentedAdded patch to add validation to check if $field and $field_output are not empty.
Comment #3
grimreaperHello,
To understand the condition of the error, can you share your pattern YAML and Twig template please?
Comment #4
steven.d commentedWe had this same issue, and after quite a bit of detective work I've figured out what caused it (in our case).
Our situation:
We have a "Content select" view (which is used by an entity browser to add page teasers in a layout builder block via entity reference field). This view has a display, lets call it "Display A", that uses a 'Card' pattern for it's row display, and has the following fields, mapped to the pattern.
After a colleague recently added a new display "Display B" to this view, our initial Display A no longer worked. When the entity browser modal was opened, the above error would be shown in the modal.
Display B is a copy of Display A, but includes a new field, Content: Image (field_image) which was specifically added only to this display, because it lists a content type that doesn't use field_featured_image.
When checking with xdebug, if found out that when Display A was displayed, the foreach at line 42 of ui_patterns/modules/ui_patterns_views/ui_patterns_views.module also included field_image as one of the fields. Since that field does not exist on this display, it results in the error.
However, reviewing the pattern mapping of the row display via the Views UI showed nothing wrong. There was no mention of field_image, or any mapping for it. And it wasn't mentioned in the Default display either.
So what was wrong? It took a while to figure out, but this is where the problem lies:
When the new display was created, and the new field was added to it, my colleague mapped field_image to a region in the pattern in the settings of the Pattern row style for Display B. However, he did not set the row display itself to the "this display override", so the mapping of field_image to the pattern region was saved for "All displays".
Visually, in views UI, each display's row settings seem fine (because in Display A, field_image is not show as an option to map to the pattern), but the mapping still exists for that display because it was saved to the defaults for the whole view.
So to reproduce:
The patch in #2 fixes the error preventing the view from being displayed, but will still throw the following warning:
Warning: Undefined array key "field_image" in template_preprocess_pattern_views_row() (line 44 of modules/contrib/ui_patterns/modules/ui_patterns_views/ui_patterns_views.module).
Comment #5
steven.d commentedI think
$field = $view->field[$field_name];should have a check to see if that field is actually available in the current display, before continuing.Comment #7
riyadongre commentedModified the patch and added a condition to see if the field is available in the current display. Please review.
Comment #8
riyadongre commentedHere's adding an interdiff for your reference, that contains the condition applied in the patch.
Comment #9
pdureau commentedComment #11
grimreaper@steven.d thanks a lot for the detailed steps to reproduce.
Confirming I am able to reproduce and that the proposed fix avoid the fatal error but a warning remains so I have simplified the check and made a PR.
Comment #13
grimreaper