Computed value is dropping the last character when returned.

Created on 19 March 2024, about 1 year ago

Having a strange issue with computed fields.

I have 2 computed text fields on a node to display based on a regular fields value.
- If the field used to calculated the computed field value has 12 characters or digits, the first computed field will get that fields value.
- if the field used to calculate the computed field value has 8 characters or digits, the second computed field should be populated with that fields value. So only one of the 2 computed fields gets displayed for this particular use case

For the most part it works as expected, the only problem is the last character or digit is missing from the computed fields display. It acts as if it doesn't even exist - yet if I dpm the $value being returned for the computed field before it is returned the correct number is output.

Here is code sample for one of the 2 computed fields in .module file: (This is for the computed field when there are only 8 characters/digits)

if (!$entity->get('field_upc')->isEmpty()) {
    $upc = $entity->field_upc->value;
dpm($upc); // outputs "01234567"
    $digits = str_split($upc);
    $count = count($digits);
    if ($count === 8) { // for the other field this is $count === 12
//     $value = $upc;  
     $value = $entity->field_upc->value; // tried this instead of previously commented out but is the same result as "value = upc"
dpm($value);  // also outputs "01234567"
     return $value;
    } else { return; }
  } else { return; }
}

However the returned value that gets displayed for the computed field on the published node view is "0123456" and is missing the last number of "7" - All the while dpm($value) outputs the full 8 characters/digits of "01234567", so how it is dropping the last character is beyond me.

Same for the other computed field when expecting 12 characters/digits:
the dpm($value) is an output of "012345780912" (12 characters/digits) but the computed field value is: "01234578091" (11 characters and missing the last character of "2")

The input field "field_upc" is a regular text field with custom validation that only allows for digits and it must be either 8 or 12 digits in length. The fields maximum length is also set to 12 and limited to 1 value (so it can accept an 8 or 12 digit code)

The first computed field "field_upca" is set to max length of 12 and limited to 1 value. (for UPC type A)
The second computed field "field_upce" is set to a max length of 8 and limited to 1 value. (for UPC type E)

I'll include a screen capture showing the dpm() output with both the default field and the computed fields displaying. Both would not normally be displayed - I just left the regular field (field_upc) to show the value difference when rendered. When/If get this working right only one of the two computed fields will display when rendered based on the default field used to calculate from.

For good measure: I'm on Drupal 10.2.4, PHP 8.1.13 on Apache 2.4.38 and no errors are reported on screen or in dblogs.

πŸ› Bug report
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States sidgrafix

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @sidgrafix
  • πŸ‡ΊπŸ‡ΈUnited States sidgrafix

    Well.. I found the cause of the problem.

    It is directly related to setting the computed fields "maximum length" (The maximum length of the field in characters) during field creation. I matched the max length of the default text field of 12 (which always worked fine and displayed properly) for the computed field (which drops the last digit/character). It appears if a value for a computed field is the number of characters that is the max allowed by the computed field, on render it will drop the last digit/character and only save and display 11 characters.

    I ran 3 tests to confirm this:
    First I created a new computed text field and left it set to default of 255 for maximum length, and the correct 12 digits/characters rendered in the computed field.
    Second I created another computed text field and set it's max length to 13, again the correct 12 digits/characters displayed.
    Third I created another computed text field and set its max length to 12 (same as one of the original computed fields I had set) and this time like before only 11 digits/characters displayed... which is not correct.

    So this is obviously a bug! Considering I have a regular text field that has a max character length of 12 (and it accepts and displays 12 characters/digits without issue) a computed field set the same should also display all 12 digits/characters and does not. For whatever reason it is only rendering with 11 characters and provides no errors or notices when it probably should.

    I think the field storage of the value is correct (if I edit the 2 computed fields I am having issues with - the correct max length value is shown grayed out "12 and 8 respectively" meaning the database returns what was original set, so the issue is likely not in the default field storage) so it has to be somewhere during rendering after the value is calculated - somehow 1 is subtracted from the fields max length before being displayed.

    I'm not 100% sure but I think Drupal's default handling of any fields input exceeding max length of allowed characters would normally returns an error stating the fact. Being that isn't happening here tells me the computed fields validation passed (during node add/edit save) and has to do with some calculation during display rendering maybe in the field formatter. Unless for some reason computed fields don't adhere to standard field validation, which if that is the case there could be a bigger issue.

    With all that, I'm not sure where to start looking to create a patch for this issue.

    For now as a work around (should someone else fall victim to this issue) just replace the computed fields with new ones making the max length +1 more than actually needed (so if you need 12, make it 13 - if you need 8, make it 9..and so on).

    This should be duplicatable as well based on the tests I ran should someone wish to try and solve this issue.

Production build 0.71.5 2024