Sugar 13.0 and PHP 8.0(.19) or 8.2

Hello there!

I am working with a Sugar Cloud customer.

Currently, the cloud PHP version is 7.4 and the support matrix states PHP 8.0 as the minimum supported version for Sugar 13.0, so perhaps 7.4 is also supported?

When coding, I imported their system to a local setup using PHP 8.0.19 and... we received a number of errors.

This is concerning because eventually PHP will be upgraded on the cloud and their system will stop working (unless other configuration options make PHP behave differently from the local environment).

I'll focus on one specific issue, a logic hook sums two fields:

$bean->something = $otherbean->somethingelse_c + $otherbean->somethingdifferent_c;

This simple code works fine in PHP < 8 and it throws this error on 8.0.19:

[Thu Aug 31 22:06:56.295813 2023] [php:error] [pid 18] [client 172.27.0.1:42314] PHP Fatal error:  Uncaught TypeError: Unsupported operand types: string + int in /var/www/html/sugar/custom/modules/Quotes/myfile.php:113\nStack trace:\n#0 [internal function]: myfile->myaction(Object(Quote), 'after_save', Array)\n#1 /var/www/html/sugar/include/utils/LogicHook.php(289): call_user_func_array(Array, Array)\n#2 /var/www/html/sugar/include/utils/LogicHook.php(167): LogicHook->process_hooks(Array, 'after_save', Array)\n#3 /var/www/html/sugar/data/SugarBean.php(7403): LogicHook->call_custom_logic('Quotes', 'after_save', Array)\n#4 /var/www/html/sugar/data/SugarBean.php(2006): SugarBean->call_custom_logic('after_save', Array)\n#5 /var/www/html/sugar/modules/Quotes/Quote.php(457): SugarBean->save(false)\n#6 /var/www/html/sugar/data/Relationships/SugarRelationship.php(853): Quote->save()\n#7 /var/www/html/sugar/data/Relationships/One2MBeanRelationship.php(83): SugarRelationship::resaveRelatedBeans(false)\n#8 /var/www/html/sugar/data/Link2.php(755): One2MBeanRelationship->add(Object(Quote), Object(Product), Array)\n#9 /var/www/html/sugar/clients/base/api/RelateRecordApi.php(290): Link2->add(Array, Array)\n#10 /var/www/html/sugar/clients/base/api/RelateRecordApi.php(240): RelateRecordApi->createRelatedLinks(Object(BulkRestService), Array)\n#11 /var/www/html/sugar/include/api/RestService.php(315): RelateRecordApi->createRelatedLink(Object(BulkRestService), Array)\n#12 /var/www/html/sugar/clients/base/api/BulkApi.php(82): RestService->execute()\n#13 /var/www/html/sugar/include/api/RestService.php(315): BulkApi->bulkCall(Object(RestService), Array)\n#14 /var/www/html/sugar/api/rest.php(23): RestService->execute()\n#15 {main}\n  thrown in /var/www/html/sugar/custom/modules/Quotes/myfile.php

For clarity, the field types are (core field decimal with precision 0) = (custom field decimal with precision 0) + (custom field integer) which in theory should be fine, and the fields were created long ago through studio. The original customisation has been working for a long time.

In this case, the line below seems to be a possible solution. Is it the right one though, considering the decimal field should not be a string to start with?

$bean->something = (float)$otherbean->somethingelse_c + $otherbean->somethingdifferent_c;

What is the recommended step forward? In specific:

  1. Should we keep using PHP 7.4 even for development at this stage, as it is hindering the speed of the project
  2. Would you happen to have suggestions to make our local setup similar to Sugar Cloud so that we are testing the same things, before the PHP upgrade?
  3. How can we determine that fields/data are incompatible and need casting, throughout the system, before PHP is upgraded? Or is there a PHP option to prevent this type of error from happening? Would the rector tool spoken about here identify this type of issue?
  4. Could this affect native sugar logic as well, as potentially it would execute a similar logic?

Thank you for your help!

===============

For this specific instance, I've been testing the code on 3v4l.org https://3v4l.org/5cHlR#v8.0.19 as suggested.

It looks like the problem could be upstream where decimal fields should not be allowed to have an empty value as default, as that would be treated as string, and fail, which was fine on v7.4

The question still stands, would rector identify this issue? Or given that it is data-driven, the system will fail without apparent reason from the user perspective?

Thanks again