resolve TypeError: unsupported operand types: string + int;

[ginkgomzd]

Overview

resolve PHP 8 TypeError: Unsupported operand types: string + int in LineItem.tpl

Before

Editing a contribution for Event Fees, generates the error from the smarty tpl because participant count is apparently a string.

After

PHP8 compatible code.

Comments

There are probably other occurences of this type of problem but I have no idea how to root them out.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[demeritcowboy]

I can't reproduce the fail. I'm using php 8.1. I can see from smarty debug (below) that participant_count is a string, and there's a gazillion other warnings, but not this error. Also just running php -r "echo 12 + '14';" on the command line doesn't generate this error. Are you able to get a stack trace?

{$lineItem}

Array (1)0 => Array (1)  113 => Array (21)    qty => 1    label => "Best"    unit_price => "225.00"    line_total => "225.00"    price_field_id => "10"    participant_count => "1"    price_field_value_id => "18"    field_title => "Event Fee(s)"    html_type => "Radio"    description => null    entity_id => "23"    entity_table => "civicrm_participant"    contribution_id => "97"    financial_type_id => "4"    financial_type => "Event Fee"    membership_type_id => null    membership_num_terms => null    tax_amount => 0    price_set_id => "10"    tax_rate => false    subTotal => 225

[ginkgomzd]

I can generate the error with this analogous code when it hits the empty string:

<?php

$theVar = 0;

$theList = [ 0, 1, '2','' ];

foreach ($theList as $i) {
        echo "i[$i]|";
        var_dump($theVar);
        $theVar = $theVar + $i;
}

i[0]|int(0)
i[1]|int(0)
i[2]|int(1)
i[]|int(3)
PHP Fatal error: Uncaught TypeError: Unsupported operand types: int + string

[demeritcowboy]

Ok thanks I see, so effectively the same as php -r "echo 4 + '';", which does give the error. So then regarding how to reproduce on the form, how does participant_count become the empty string - for me it's either a string number like "1" or NULL. I can't see how to configure civi to make it the empty string when it gets to the form.

[ginkgomzd]

probably due to custom code.

I understand where you are coming from, but I think you are setting the bar too high. This change obviously makes the form layer more robust.

[demeritcowboy]

I don't think I'd say it's setting the bar too high it's more trying to find the sweet spot between:

• letting php errors do what they were designed to do, i.e. point out problematic code, and
• being too restrictive when the input values are legitimately a wide mix (which itself might be a sign of poor design but in civi is often pre-existing due to age and php being php).

So we have different definitions of robust, because just silencing the symptom could hide other future unrelated real problems, but I agree here there's limited chance of that.

I can't confirm via r-run, and I can't even see where the other file CRM/Price/Form/LineItem.tpl gets used, but going to merge based on the limited scope.