Table::getCellRaw(): Return value must be of type string, false returned

@poker.ca: Can you provide some details about your view? Are you aggregating Webform or Commerce data, or something else? What is the data type of the field? It would help a lot if you could export your view and post it here so we can see exactly what is being done.

I added stricter typing to this module in 2.1.0, which can reveal existing problems, especially in parts of the code that have no test coverage. There is some special-case code for both Webform and Commerce that is completely untested, and I have mentioned in other issues how this is not maintainable or supportable in the long run. We really need test cases for both of these "exceptions", and I'm not the best person to write them because I don't use either of those modules.

It would be helpful if I had a *simple* views export that I could use to reproduce this error - that is, maybe one of the standard Drupal views that has been modified to use Views Aggregator and reproduce the problem, so that it doesn't involve a lot of elaborate site setup with complicated content types and many large modules.

The fix should be quite simple, but I have to understand where the wrongly typed data is coming from, that's why I need to see how you've configured your view.

Seeing this problem too.

    elseif (isset($field->value)) {
      $value = $field->value;
    }

This gets an empty array.

    if ($compressed && is_array($value)) {
      $value = reset($value);
      if (is_array($value)) {
        $value = reset($value);
      }
    }

reset([]) is FALSE, hence the bad return value.

My view is a list of timeslots which have a duration field, and I am aggregating the duration.

If a timeslot is current, it has no end time and no duration, hence the empty field value.

Thank you, that's very helpful.

It's a duration field from https://www.drupal.org/project/duration_field →

I think the comment here is wrong -- lots of field types have a 'value' property:

    // Get the commerce value.
    elseif (isset($field->value)) {
      $value = $field->value;
    }

Yes, trying to figure out the original intent is a bit of a problem in this section of the code since it isn't explained in an issue or in a code comment, and the comments that are there seems to be inconsistent.

If special casing is going to be used for Commerce and Webform (which is something I'm really not happy with) then it should be explicit: Test for Commerce/Webform, then call a special method with the special code. Else treat it as a normal field. But that's not what was done here - it seems Commerce and Webform have exceptions in many different places, so it's not clear what code is "special" and what code applies to normal fields.

Regardless, the code has always declared "@return string", and all I did was to reinforce that by adding :string as the return type hint. So before, it was returning an array for you, and it is still returning an array for you, but now it's complaining because the array is not a string.

Opening a MR with a patch. Please tell me if this fixes the problem for you!

Tests pass, but that means nothing because we don't have any test cases which exercise this section of code.

I can reproduce this with a numeric field.

1. Create a node type
2. Add a numeric field to it
3. Create three nodes, one of which has an empty value for that field
4. Create a view with fields title, numeric field.
5. Set aggregation to:
- group and compress title field
- SUM on numeric field

The MR fixes the crash with the test case from my last comment.

I'm not sure where a test would go -- struggling to figure out the structure of the existing tests.

This just happened to me and the MR fixes the issue.

In my case the MR also fixes de issue.

Also got this problem, MR 27 fixed it.

Thanks,

I still get this, even with the latest commit from 2.1.x-dev

The website encountered an unexpected error. Try again later.

TypeError: Drupal\views_aggregator\Plugin\views\style\Table::getCellRaw(): Return value must be of type string, bool returned in Drupal\views_aggregator\Plugin\views\style\Table->getCellRaw() (line 758 of modules/contrib/views_aggregator/src/Plugin/views/style/Table.php).

stemiwe,

I think you need to patch using MR 27 here. The lastest dev still doesn't have this MR commit.

I am getting a similar problem, this is the error:

TypeError: Drupal\views_aggregator\Plugin\views\style\Table::getCellRaw(): Return value must be of type string, bool returned in Drupal\views_aggregator\Plugin\views\style\Table->getCellRaw() (line 758 of /public_html/modules/contrib/views_aggregator/src/Plugin/views/style/Table.php).

Using the forked code doesn't help - if I revert to the old (2.03) version of the Table.php file I don't get the error and everything seems to work!

I note that this error is for type 'bool', which might be the difference.

We also had this problem, MR 27 fixed it.

Thank you!!

I encountered the same error and just tried adding a type-casting if statement, which fixed it for me. However, the solution I found may not work for everyone because my use case is because the node ID column in my view is being shown as a string and not an int.

I don't see what #19 or #20 has to do with this issue. $group_aggregation_results is always an integer, unless you updated your version of the module without running the update hooks. Regardless, it's a different problem and you should open a different issue if you can reproduce the error on a clean site.

I'm seeing almost the same error, but with int as returned value:

TypeError: Drupal\views_aggregator\Plugin\views\style\Table::getCellRaw(): Return value must be of type string, int returned

Therefore MR !27 in it's current state wouldn't help here.

I have a similar problem in a commerce price field. The error I get is the following one:

TypeError: Drupal\views_aggregator\Plugin\views\style\Table::getCellRaw(): Return value must be of type string, null returned in Drupal\views_aggregator\Plugin\views\style\Table->getCellRaw() (line 754 of modules/contrib/views_aggregator/src/Plugin/views/style/Table.php).

I replaced the changes here with casting
return (string) $value;

and then cast the number_format() here because the $custom_delimiters[0] is a string in my case
$rendered_values[] = number_format($new_value, (int) $custom_delimiters[0] ?? 0, $custom_delimiters[1] ?? '.', $custom_delimiters[2] ?? '');

robertoperuzzo → changed the visibility of the branch 3484017-tablegetcellraw-return-value to hidden.

robertoperuzzo → changed the visibility of the branch 3484017-tablegetcellraw-return-value to active.

Had new install of Views Aggregator and got this error on first attempt to create a view. In my case, some fields being aggregated were empty and returning FALSE. Using patch in MR27 worked for me.

Could another solution be updating the return type from just string to something like string|bool. Note this has to be done in getCell() as well, which fails if string is not returned.

Thank you, @scampbell1 : #20 (3482129-20.str-to-int.patch) fixed this for me, whereas MR !27 did not. Still not clear why $group_aggregation_results arrives here as string, but #20 fixes the resulting problem.

@poker.ca
This issue is about the error:

TypeError: Drupal\views_aggregator\Plugin\views\style\Table::getCellRaw(): Return value must be of type string, false returned

MR!27 solves that specific error, which results from the situations described in #3. That's a very specific issue, which has a very specific cause, and the MR solves that very specific issue.

The patch provided by @scampbell1 does NOT solve the very specific issue that is described in the issue summary above.

Regardless, what I said in reply to @scampbell1 in #21 is still true:

it's a different problem and you should open a different issue if you can reproduce the error on a clean site.

So, @poker.ca , can you reproduce your error on a clean site? And, as I asked in #21,

[did] you update your version of the module without running the update hook

?

@poker.ca: You clearly have a DIFFERENT problem. So open a NEW issue for your problem, and provide instructions for how to reproduce that problem on a clean site.

The $group_aggregation_results variable should ALWAYS be an integer. If it isn't, ON A CLEAN SITE, then there is a problem with this module that needs to be solved (in a different issue, because that's not the problem the OP raised). This can't be solved without community input as to the exact conditions that cause this problem.

$group_aggregation_results is defined in the schema as an integer, and is treated in the code as an integer, and should always be an integer. The only reason I know of where it would not be an integer is if the module was updated from an older version (where this variable was sometimes a string) and the update hooks were NOT run. That would be a user error, not an error with this module. Again, the only way to determine this is if you provide instructions for reproducing this error on a clean site.

TR Said to post this here. Even though its a completely different method, the error is VERY similar.

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.