Views: Separate row per webform field

#49 works as expected, thank you very much!

I'm using #48 (MR 11). This doesn't work quite right when using a composite field as both a field (display on multiple rows) and a filter on that field.

1. Webform: Add a multi-value composite field with a textfield and a number field
2. Create a submission with 2 or more composite items with different text and numbers. I did 3. Call them x.1, y.2, and z.3.
3. View: add the composite element's textfield to the fields of the view (select "display on multiple rows")
4. View: add the composite element's number field to the filters of the view as an exposed filter
5. Instead of getting each composite element in a different row, I get the delta 0 composite element in each row, so that each row per webform submission is the same. (instead of x.1, y.2, z.3; I get x.1, x.1, x.1)
6. Also, the exposed filter doesn't actually filter anything from those rows. If my exposed filter is "2", I would expect to only see the y.2 row, but I still just see three duplicate rows with x.1

In addition to the above issue, if I make the exposed filter required, I see errors at times.

Error: Call to a member function get() on null in Drupal\views\Plugin\views\filter\FilterPluginBase->storeExposedInput() (line 1579 of /var/www/html/web/core/modules/views/src/Plugin/views/filter/FilterPluginBase.php)
#0 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1375): Drupal\views\Plugin\views\filter\FilterPluginBase->storeExposedInput(Array, true)
#1 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1270): Drupal\views\ViewExecutable->_build('filter')
#2 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1399): Drupal\views\ViewExecutable->build(NULL)
#3 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1462): Drupal\views\ViewExecutable->execute(NULL)

I'm having a hard time figuring out how I'm going to solve this problem of the filtering not working, if I try to workaround it. You can't even preprocess the view results, because composite fields don't show properly in the preprocess hook implementation.

I also sometimes get this PHP warning:

Warning: Undefined array key "webform_submission_property" in Drupal\webform_views\Plugin\views\field\WebformSubmissionField->query() (line 164 of /var/www/html/web/modules/contrib/webform_views/src/Plugin/views/field/WebformSubmissionField.php)
#0 /var/www/html/web/core/includes/bootstrap.inc(347): _drupal_error_handler_real(2, 'Undefined array...', '/var/www/html/w...', 164)
#1 /var/www/html/web/modules/contrib/webform_views/src/Plugin/views/field/WebformSubmissionField.php(164): _drupal_error_handler(2, 'Undefined array...', '/var/www/html/w...', 164)
#2 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1381): Drupal\webform_views\Plugin\views\field\WebformSubmissionField->query(false)
#3 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1290): Drupal\views\ViewExecutable->_build('field')
#4 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1399): Drupal\views\ViewExecutable->build(NULL)
#5 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1462): Drupal\views\ViewExecutable->execute(NULL)

@solideogloria Is this somehow related to https://www.drupal.org/project/webform_views/issues/3068861 🐛 Webform submission view filter for multivalues Needs work ?

Just as a note: The failing export from #52 is caused because the count query never finishes. This is also the case if you use the Full Pager for the view. I am just gettings timeouts if the count query is executed.

It looks like it might be. However, I decided that going forward it would just be easier to use a separate webform instead of composite fields. The way composite fields work (or don't) in views right now is not sufficient for my use case.

The issues with display, filters, and sorts all would need to be fixed before I could consider using them again, in views at least.

stefan.korn → made their first commit to this issue’s fork.

I was wondering why this part

        $this->query->getTableInfo($this->tableAlias)['join']->extra[] = [
          'field' => 'property',
          'value' => '',
        ];

was removed for the non-multiple case. Shouldn't non-multiple case be handled just as before?

That said: without this code part I had issues with duplicate rows in views of webform submissions where I did not even use a multi value field.

So I have added this again to the merge request.

Uploading the patch file from (current state) of merge request here, if someone likes the old way of providing patches and because directly using merge request diff as composer patch bears some risks (see https://drupal.stackexchange.com/questions/298567/patch-drupal-org-proje...).

This merge request thing is kind of nasty ...

There is a diff in code between
https://git.drupalcode.org/project/webform_views/-/merge_requests/11.diff
and
https://git.drupalcode.org/project/webform_views/-/merge_requests/11.patch

at least on my end (maybe cache somewhere inbetween?).

So the patch I provided did not contain the latest code of the merge request. Therefore providing new one based on .diff from merge request.

Off-Topic: Asking myself if that merge request thing as really that good, does at least seem not that stable from a point of using the patches, maybe it's easier to handle for maintainer, new committers that maybe want to do it in web ide. But if you're used to old way, it does not seem easier and has this risk of getting unreliable patches ... hmm, feels like I will stick to the old way for my own projects.

You're not supposed to paste the MR patch URL into your composer file. You're supposed to download the patch file, and put it in your project, such as /var/www/html/patches/file.patch. Then put that file path in your composer file.

Also, though the files are different, the result is the same. The patch file contains every individual commit's changes, while the diff is a single diff of it all.

Ah yes okay understand how: .patch file splits in different commits. Sorry for the noise.

Still the MR workflow is not my favorite.

Understandable, however it makes things much easier for module maintainers, so that's the way Drupal is going.