-
-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prevent string * int multiplification issue in PHP 8.0+ #1915
Conversation
Should we use type hinting for newly introduced methods? |
You mean this instead of this?
If yes, then we can have issues with 3rd party extensions overriding getSomething() We'll get error like "Uncompatible method declaration" Sample here: https://3v4l.org/V8r2e I don't mind of course if we don't need any compatibility :) |
Here you go with updated empty lines. Just pushed commit |
Some of fields are set/get dynamically by observers/tax calculators, think there's no big sense to make PDO returns in this case |
with this amount of new methods I wonder if its not easier, to extend the getData, setData logic to force types for specific fields instead of overwriting the methods. So in the end we just have a configurable array. |
Dedicated methods have a big advantage of being static analisys friendly. So im against of putting more logic in magic get data |
Hi @fballiano , after applying this release, all of my prices drop to zero in cart and Checkout. In Catalog and Product view everything is fine. |
I broke it down to the File /app/code/core/Mage/Sales/Model/Quote/Item/Abstract.php and here the function
If I comment this function out, it works and Prices are there. I'm not sure why. |
Thank you very much @constancyGmbH, I'll try to take a look at this ASAP |
I think it has something to do with setting this value to NULL.
|
mmmm it doesn't happen to me on a vanilla openmage installation :-\ |
ok, so maybe this is a Probleme with a custom module or an adjustment on our Magento installation.... |
Have you tried your Code in PHP 7 oder 8 (or Both)? |
that's what i was thinking, I tried it on php7.4 |
I haven't tested the finding of @constancyGmbH, but I highly suspect it is related to magento-lts/app/code/core/Mage/Sales/Model/Quote/Item/Abstract.php Lines 609 to 613 in dfb6fe8
This PR added a bunch of setters: magento-lts/app/code/core/Mage/Sales/Model/Quote/Item/Abstract.php Lines 1114 to 1477 in dfb6fe8
Just eyeballing without testing, we know that I do not know how best to address the issue, but may be something like: // Field is generic field name.
function setField($value)
{
$this->setData('field', $value === null ? null : (float) $value);
return $this;
} [edit] I'm not sure if the above is the correct fix. Does PHP 8 happy with |
I think this is the reason the price is zero in the cart: magento-lts/app/code/core/Mage/Sales/Model/Quote/Item/Abstract.php Lines 434 to 446 in dfb6fe8
With this PR, [edit] If we use |
+1 to revert this PR. [edited] echo '1' + 1; // OK, result int(2)
echo null + 1; //OK, result int(1)
echo '1.1' + 1; //OK, result float(2.1)
echo round('1.1'); //OK, result float(1)
echo '' + 1; // Not OK, PHP Fatal error: Uncaught TypeError: Unsupported operand types: string + int
echo round(''); // Not OK, PHP Fatal error: Uncaught TypeError: round(): Argument #1 ($num) must be of type int|float, string given When retrieving type But what if we set empty string to setField((int) $var); // OK for arithmetic, but not OK when testing for null.
setField((float) $var); // OK for arithmetic, but not OK when testing for null.
setField($var ?: null); // OK for arithmetic and testing for null, but not OK when testing === 0 Without knowing the intent of the original developer and how the field is being used, it is hard to know which of the above can be applied. But for I am not 100% sure, but prior to this PR, OM seems to work just fine with PHP 8. My conclusion is that this PR is unnecessary. |
This reverts commit 110e3d0.
I've created a PR to revert this one, altough I can't merge it without 2 other maintainers to approve |
Description (*)
I faced with fatal errors while upgrading native magento 1.9.x to PHP8.0 locally:
After debugging I found the issue 1:
echo '' * 1;
gives:
Fatal error: Uncaught TypeError: Unsupported operand types: string * int
Issue 2:
round('')
gives:
Fatal error: Uncaught TypeError: round(): Argument #1 ($num) must be of type int|float, string given
So patched core files with missing methods which should be casted to float.
Wanna share fix with you. Hope this helps to make whole code better.
Manual testing scenarios (*)
This is potential issue with PHP8, to be checked with auto tests
Questions or comments
This stuff gives small performance improvement coz we get rid of slow preg_replace, 2 substr and 1 strtolower calls after changes. Coz we use _getData() instead of magic method __call now
Varien_Object:
So on quote calculation we can save much calls to preg_match (even if count that _underscore caches calls)
If there are N calls to different methods getBlabla during quote recalculation, we save
N * preg_replace, N*2 substr, N strtolower calls
Not bad if N > 20 :)
Contribution checklist (*)