I'm not entirely sure what is happening here but I had a view that was working previously and after an update to one module or another (this, maybe webforms, unknown) it stopped working.
The error is TypeError: Drupal\views_aggregator\Plugin\views\style\Table::renderNewWebformValue(): Argument #2 ($row_num) must be of type int, null given. called in .../views_aggregator/src/Plugin/views/style/Table.php on line 902 which occurs inside the elseif ($this->isWebformNumeric($field_handler)) { branch.
Looking at the code, I can see that the second argument of renderNewValue is ?int $row_num and nothing changes $row_num before line 902 which means that $row_num is an int or null. Then in the function definition for renderNewWebformValue, the argument that receives the $row_num is defined as int $row_num. The first line of the method actually checks if $row_num isset which means a null would be handled correctly anyways... Changing the type of this argument to ?int $row_num should be handled correctly and prevent the possible type error.
However, upon making that change, I ran into the next issue with my view. When $row_num is null, my $new_value is now apparently a float instead of an array, which causes an error on argument #3... :p
The change I made that appears to fix BOTH issues is to only call $this->renderNewWebformValue if $new_value is an array, otherwise I just set $rendered_values[] to $new_value and move on...
The line now looks like $rendered_values[] = is_array($new_value) ? $this->renderNewWebformValue($field_handler, $row_num, $new_value, $separator) : $new_value; and that fixes it.
Because this happens in the "isWebformNumeric" branch, I suspect something changed in webforms or there was an edge case on the webform numeric fields that wasn't caught before.
Comments
Comment #2
tr commentedPlease post this information in the existing issue #3495283: TypeError: Drupal\views_aggregator\Plugin\views\style\Table::setCell(): Argument #2 ($row_num) must be of type int, null given
Comment #3
redeight commentedThis issue, while similar in error message to the one you claim this duplicates, deals with a completely separate method type signature. Per your comment in other issues, since my error pertains to a separate method, the fix in that issue will not correct this one so I've created a separate issue to deal with this specific one.
Comment #4
tr commentedWell I think it has the same root cause, and regardless I am not going to cross-post everything in two separate threads. Everything I said there applies here as well, and a proper fix to handling row_num that includes tests (and especially tests for special-case processing of webforms and commerce) will have to address all variations of this issue, otherwise it won't be a proper fix.