Top 20 Adobe Commerce core issues
Magento 2 and Adobe Commerce have 1000+ core issues. This is the list of the top issues discovered by merchants.
1.Magento 2.3 images cache generation generates wrong hash for some images with a custom theme that has the keep_frame var set to 0
#19710 opened on Dec 11, 2018
I just upgrade my Magento 2 project from 2.2.6 to 2.3. After the upgrade, some images in the catalog are showing placeholders instead of the images. I have regenerated the images cache with the catalog:images:resize but some images are still missing (swatch images in category pages and image thumbnail in category pages).
After some investigation, it seems that is it a problem with the hash used for the image cache directory. When generating the images cache in the CLI, all images have in their misc params used to build the hash a value of “keep_frame” => 1, although in the view.xml file of my custom theme, the param “product_image_white_borders” is set to 0. When generating the image path for the catalog pages, the keep frame param is 0.
My investigation led me to the ParamsBuilder class (module-catalog/Model/Product/Image/ParamsBuilder) that uses its viewConfig property to get the value of the var “product_image_white_borders” in the “hasDefaultFrame” function. Seemingly, when running the CLI command, the view config that is injected in the ParamsBuilder is not the same that is used by the ImageResize command, and it has a wrong “product_image_white_borders” value of 1. It seems that it does not use the theme that the ImageResize command is currently processing, and its scope is global.
Reported By: Caroline Boivin
2. Carding Attack
#28614 opened on Jun 8, 2020
My store has been the target of several carding attacks in the last few weeks, growing in intensity and sophistication. Thousands of credit cards (presumably stolen numbers) are “tested” using a single guest cart on my store.
Initially we were manually blocking IP addresses after receiving the Payment Transaction Fail email notices, and increased Cloudflare security level. When the attacks became more frequent, created a custom fail2ban filter that would ban IP addresses having several POST requests to
/rest/<view>/V1/guest-carts/<cart_id>/payment-information
.Then the attacks started to come from dozens of IP addresses. At that point we noticed that ModSecurity wasn’t working, and once we got that fixed, they have mostly stopped.
3. The shipping information was unable to be saved. verify the input data and try again.
#23908 opened on Jul 26, 2019
We had to debug this issue as well today on a 2.3.1 shop, thanks to all the helpful comment above and our investigation, this is a brief summary:
- The issue here is that a logged in customer still can have the flag
customer_is_guest
set to 1 on thequote
- This flag is the root cause of the bug reported here, although it’s not clear yet how this flag is being set incorrectly
- We’ve searched through various shops we maintain ranging between Magento 2.1, 2.2 and 2.3 versions and all versions are affected by this inconsistent
customer_is_guest
flag on the quotes (we've seen shops where hundreds of quotes existed where this is incorrect) - We believe the bug reported here only came to the surface in Magento 2.3.1 an 2.3.2 due to some changes done recently in the QuoteAddressValidator class. Before those versions, the incorrect flag also existed but didn’t really seem to have caused issues.
Our current solution, was to add an after plugin to the getCustomerIsGuest
function of the Magento\Quote\Model\Quote
class. And do something like this:
public function afterGetCustomerIsGuest(QuoteModel $subject, $result)
{
$customer = $subject->getCustomer(); return $customer->getId() === null;
}
So instead of checking the flag from the database, we check if the customer’s id is null or not to decide if a customer is a guest or not.
Now, this is only a workaround.
To fix this properly in Magento, two things need to happen in my opinion:
- the root cause of this bug needs to be found and fixed (Quote
customer_is_guest
set to 0 for guests #24736 might be related) - a database upgrade script should be written which fixes all incorrect
customer_is_guest
flags in thequote
table, so all existing quotes which are being prevented to go through the checkout start working again.
I’m reopening this issue for now again (yes, I realise we still don’t have steps to reproduce, but the issue seems to be very real).
4. Paypal some orders fail with main.CRITICAL: Wrong order ID: Component: Sales
#15427 opened on May 22, 2018
When using paypal express integration as the payment method on Magento 2.2.2 a small number of orders fail after the payment has been taken by paypal. No order is registered in Magento, but paypal takes payment and sends a confirmation to both customer and store owner.
Looking in the logs the error which seems to be associated with these orders failing is:main.CRITICAL: Wrong order ID: "000000222". {"exception":"[object] (Exception(code: 0): Wrong order ID: \"000000222\". at .../vendor/magento/module-paypal/Model/Ipn.php:140)"}
5. Checkout with PayPal throws a “Something went wrong ……”
#28092 opened on May 3, 2020
Getting this error after Pay Button is pressed, but the change to the PayPal site is still happening.
Unfortunately, nothing logged in the log directory or in the the report directory.
6. Duplicate orders with same Quote Id at same time with few time difference.
#13952 opened on Mar 5, 2018
Preconditions
- Ability to process requests at same time. (in our case, we had use 2 different Client’s system.)
Steps to reproduce
- Login as a User
- Add items to cart and proceed through checkout.
- Select Any payment method. Not click on place order button
- Now login to the same account in another system.
- And proceed to checkout with the same items. Not click on place order button.
- Now you have to click on place order at the same time with both the systems.
Observe order confirmation screen of both systems.
Depending on your infrastructure, this bug may be challenging to reproduce. It requires all of the “Place order” button clicks to be processed concurrently by Magento. You will not see the bug if Magento is processing requests sequentially (as the second request will reference a cart ID that no longer exists).
7. Scrolling issue in backend pages | bouncing up and down
#22392 opened on Apr 17, 2019
This is very hard to reproduce on an environment but I’ve seen it happening in category edit page, product edit page and a lot of other module pages in all versions of Magento from 2.2.4 to 2.3.1.
There is probably a script that’s preventing users from scrolling up when the whole document form can be seen in the current window so when you scroll up you’re returned to the same point you were in the screen although the scrollbar still exists.
In rare occasions, when the sticky header appears, the size of the document of the document is altered and it causing an infinite bouncing effect.
Since it’s very hard to describe I decided to capture it on a video and attaching it here. If someone can help me out on how to replicate it every time I would appreciate it so that I can write detailed steps.
8. Paypal Pro currency issue
#7977 opened on Dec 28, 2016
Preconditions
- Magento CE 2.1.2
- Setup two websites, each one has its own Paypal Pro account.
- Setup base currency as CAD for each website
- Product currency is CAD
Steps to reproduce
- Go to the 1st website (main website), place an order (CAD $10.00) by using Paypal Pro payment, both Magento and Paypal show the amount in CAD
- Go to the 2nd website, place an order (CAD $10.00) by using Paypal Pro payment, Magento shows CAD10.00, but Paypal actually charge the customer USD $10.00.
- The customer is charged in USD on the 2nd website
9. session_start(): Failed to read session data: user (path: /var/lib/php/sessions)
#17310 opened on Aug 1, 2018
While viewing the orders page in the admin area and opening several orders I’m facing an error message.
Steps to reproduce
- Browse the order pages in the admin area
- click on an order
- go back to the order list
- click on an other order again
- retry several times
- see error message in the admin area:
Message in step 6 of reproduction appears, in the log, I can find the following:
{"0":"Warning: session_start(): Failed to read session data: user (path: /var/lib/php/sessions) in /vendor/magento/framework/Session/SessionManager.php on line 193","1":"#0 [internal function]: Magento\Framework\App\ErrorHandler->handler(2, 'session_start()...', '/home/cloudpane...', 193, Array)\n#1 /vendor/magento/framework/Session/SessionManager.php(193): session_start()\n#2 /generated/code/Magento/Backend/Model/Session/Interceptor.php(63): Magento\Framework\Session\SessionManager->start()\n#3 /vendor/magento/framework/Session/SessionManager.php(130): Magento\Backend\Model\Session\Interceptor->start()\n#4 /generated/code/Magento/Backend/Model/Session/Interceptor.php(14): Magento\Framework\Session\SessionManager->__construct(Object(Magento\Framework\App\Request\Http), Object(Magento\Framework\Session\SidResolver\Proxy), Object(Magento\Backend\Model\Session\AdminConfig), Object(Magento\Framework\Session\SaveHandler), Object(Magento\Framework\Session\Validator), Object(Magento\Framework\Session\Storage), Object(Magento\Framework\Stdlib\Cookie\PhpCookieManager), Object(Magento\Framework\Stdlib\Cookie\CookieMetadataFactory), Object(Magento\Framework\App\State))\n#5 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(111): Magento\Backend\Model\Session\Interceptor->__construct(Object(Magento\Framework\App\Request\Http), Object(Magento\Framework\Session\SidResolver\Proxy), Object(Magento\Backend\Model\Session\AdminConfig), Object(Magento\Framework\Session\SaveHandler), Object(Magento\Framework\Session\Validator), Object(Magento\Framework\Session\Storage), Object(Magento\Framework\Stdlib\Cookie\PhpCookieManager), Object(Magento\Framework\Stdlib\Cookie\CookieMetadataFactory), Object(Magento\Framework\App\State))\n#6 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(66): Magento\Framework\ObjectManager\Factory\AbstractFactory->createObject('Magento\\Backend...', Array)\n#7 /vendor/magento/framework/ObjectManager/ObjectManager.php(70): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->create('Magento\\Backend...')\n#8 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(144): Magento\Framework\ObjectManager\ObjectManager->get('Magento\\Backend...')\n#9 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(230): Magento\Framework\ObjectManager\Factory\AbstractFactory->resolveArgument(Array, 'Magento\\Framewo...', NULL, 'session', 'Magento\\Store\\A...')\n#10 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(34): Magento\Framework\ObjectManager\Factory\AbstractFactory->resolveArgumentsInRuntime('Magento\\Store\\A...', Array, Array)\n#11 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(59): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->_resolveArguments('Magento\\Store\\A...', Array, Array)\n#12 /vendor/magento/framework/ObjectManager/ObjectManager.php(70): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->create('Magento\\Store\\A...')\n#13 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(144): Magento\Framework\ObjectManager\ObjectManager->get('Magento\\Store\\A...')\n#14 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(230): Magento\Framework\ObjectManager\Factory\AbstractFactory->resolveArgument(Array, 'Magento\\Framewo...', NULL, 'redirect', 'Magento\\Backend...')\n#15 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(34): Magento\Framework\ObjectManager\Factory\AbstractFactory->resolveArgumentsInRuntime('Magento\\Backend...', Array, Array)\n#16 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(59): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->_resolveArguments('Magento\\Backend...', Array, Array)\n#17 /vendor/magento/framework/ObjectManager/ObjectManager.php(70): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->create('Magento\\Backend...')\n#18 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(144): Magento\Framework\ObjectManager\ObjectManager->get('Magento\\Backend...')\n#19 /vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php(230): Magento\Framework\ObjectManager\Factory\AbstractFactory->resolveArgument(Array, 'Magento\\Backend...', NULL, 'context', 'Magento\\Ui\\Cont...')\n#20 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(34): Magento\Framework\ObjectManager\Factory\AbstractFactory->resolveArgumentsInRuntime('Magento\\Ui\\Cont...', Array, Array)\n#21 /vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php(59): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->_resolveArguments('Magento\\Ui\\Cont...', Array, Array)\n#22 /vendor/magento/framework/ObjectManager/ObjectManager.php(56): Magento\Framework\ObjectManager\Factory\Dynamic\Developer->create('Magento\\Ui\\Cont...', Array)\n#23 /vendor/magento/framework/App/ActionFactory.php(40): Magento\Framework\ObjectManager\ObjectManager->create('Magento\\Ui\\Cont...')\n#24 /vendor/magento/framework/App/Router/Base.php(297): Magento\Framework\App\ActionFactory->create('Magento\\Ui\\Cont...')\n#25 /vendor/magento/framework/App/Router/Base.php(158): Magento\Framework\App\Router\Base->matchAction(Object(Magento\Framework\App\Request\Http), Array)\n#26 /vendor/magento/framework/App/FrontController.php(50): Magento\Framework\App\Router\Base->match(Object(Magento\Framework\App\Request\Http))\n#27 /vendor/magento/framework/Interception/Interceptor.php(58): Magento\Framework\App\FrontController->dispatch(Object(Magento\Framework\App\Request\Http))\n#28 /vendor/magento/framework/Interception/Interceptor.php(138): Magento\Framework\App\FrontController\Interceptor->___callParent('dispatch', Array)\n#29 /vendor/magento/framework/Interception/Interceptor.php(153): Magento\Framework\App\FrontController\Interceptor->Magento\Framework\Interception\{closure}(Object(Magento\Framework\App\Request\Http))\n#30 /generated/code/Magento/Framework/App/FrontController/Interceptor.php(26): Magento\Framework\App\FrontController\Interceptor->___callPlugins('dispatch', Array, Array)\n#31 /vendor/magento/framework/App/Http.php(135): Magento\Framework\App\FrontController\Interceptor->dispatch(Object(Magento\Framework\App\Request\Http))\n#32 /generated/code/Magento/Framework/App/Http/Interceptor.php(24): Magento\Framework\App\Http->launch()\n#33 /vendor/magento/framework/App/Bootstrap.php(256): Magento\Framework\App\Http\Interceptor->launch()\n#34 /pub/index.php(37): Magento\Framework\App\Bootstrap->run(Object(Magento\Framework\App\Http\Interceptor))\n#35 {main}","url":"/admin/mui/index/render/key/[MASKED]/order_id/[MASKED]]?namespace=payone_sales_order_view_transactionstatus_grid&sorting%5Bfield%5D=sequencenumber&sorting%5Bdirection%5D=asc&isAjax=true","script_name":"/index.php"}
The path /var/lib/php/sessions
was never set anywhere. I actually can't understand why Magento is trying to use the path when redis is configured. It may be related to SessionManager->registerSaveHandler()
?
10. Cart caching problems
#3625 opened on Mar 2, 2016
If a customer adds product to the cart, content of its cart is cached in browser's local storage. Now, if price of any product in cart change for any reason (catalog rule, special price, main price change) while customer is on site:
- wrong price is displayed in mini cart on all pages
- wrong price is displayed in main Cart page, but right Summary box is reloaded with correct price; so there are 2 totally different prices displayed on Cart page for the same product (this one on current develop branch, not sure for stables)
- wrong price is even displayed on first Checkout step in Order Summary box
Any customer would be really confused with this, he/she would either quit or not notice change and buy at the wrong price.
This is just one example, I believe many more edge cases can be presented, maybe going out of stock or something like that.
I’m not sure if current customer data js cache has any mechanism to be invalidated by the server. Magento cache was flushed btw, has nothing to do with this.
It’s also for discussion how secure is caching customer name and similar data to local storage, but that’s another topic :)
Regards,
Ivan
Steps to reproduce (*)
- From Magento Admin go to Catalog — Products, Add a Simple Product
- Fill in all the required fields, set Price 100 for example, Save the Product
- Open Store View, and Add the previously created Product to Cart
- From Magento Admin go to Catalog — Products, and Edit the previously created product, set Price to 90, for example. Save
- Open Store View, refresh the web page
- Click on Cart in the top right corner and verify the Price
Expected result (*)
The price should be updated to 90
Actual result (*)
The price in Cart remains 100 but the price of the Product in Category is updated to 90
11. Unable to update simple product custom option in cart when quantity is 1
#18812 opened on Oct 25, 2018
Steps to reproduce
- Go to product page and select options and click add to cart. || Update 9/19/2019: The quantity of the product added must be more than a half of its Stock quantity! ||
- Go to cart and select “Edit/Update Item”
- Select different option from original and click update.
Actual result (*)
- Error message on product page.
- || Update 9/19/2019: (Those messages haven’t been observed at now. Only the one below still appears) ||
The requested qty is not available
Notes
It manifests as well if you have configurable product, where associated product has 1 stock, and configurable has custom option. Once selected and added to cart. If you try to update only custom option, the result is the same.
It appears that the code in Magento/Quote/Model/Quote.php#updateItem
updates product item or adds new one if product item with matching custom/configurable options does not exist and later removes old item.
Problem is inside updateItem()
, call to to addProduct() throws, because actual product qty is 1.
12. Magento 2.4 critical load of RAM triggering OOM killer due to CSP module 100.4.0
opened this issue on Sep 9, 2020
We found out via SSH top that the RAM consumption was peaking during the category generation on the frontend (from uncached to cached).
First, we thought it was a Redis issue because 9 out of ten times the page would look broken like we have seen in the M1 days because of a Redis issue.
But actually “the broken page layout” was the result of PHP running out of memory.
The result would get cached and stay in the cache until the Redis cache was cleared.
After a lot of digging, I found the source of the issue in:
vendor/magento/module-csp/Model/BlockCache.php
Under the function: load($identifier)
This function uses a crazy amount of RAM.
A quick workaround is disabling the module to keep the shop RAM usage healthy.
The log errors show that this function is causing issues.
Buggento!