magento / magento2

Prior to making any Submission(s), you must sign an Adobe Contributor License Agreement, available here at: https://opensource.adobe.com/cla.html. All Submissions you make to Adobe Inc. and its affiliates, assigns and subsidiaries (collectively “Adobe”) are subject to the terms of the Adobe Contributor License Agreement.
http://www.magento.com
Open Software License 3.0
11.48k stars 9.29k forks source link

[2.4.4] Product with Salable Qty of 0 shows 'In Stock' on product page #35319

Closed FadedOut closed 2 years ago

FadedOut commented 2 years ago

FIX: A quick non-official hack/fix was posted further below by @loic-paquin and @jas8522 here

Preconditions (*)

  1. Upgraded from Magento 2.4.3-p1 to 2.4.4
  2. Default Luma Theme or 3rd Party
  3. Have backorders turned off (screenshot attached for confirmation that my settings are correct - though they did not change from 2.4.3-p1 where this was not a problem)

Steps to reproduce (*)

  1. Have a product with 0 salable quantity (configurable product)
  2. Go to frontend product page and check a variation/configuration (by selecting it)
  3. You can click "Add to Cart"

Expected result (*)

  1. It should say "Out of Stock" above SKU and/or you should not be able to select or click the variation swatch.
  2. Should not be able to click "Add to Cart" for an "Out of Stock" product (with 0 salable qty).

Actual result (*)

  1. It will allow you to click/select a swatch of an "out of stock" variation
  2. It will say "In Stock"
  3. Clicking "Add to Cart" it will reload page with error: "There are no source items with the in stock status"
  4. The "X in Stock" feature (only X left threshold) shows correctly when it is under my threshold, but does not show on a product that is really out of stock (with selecting the variation). So that function knows not to show because there are 0 in stock.
  5. Running re-index through CLI, I receive the following error (not sure if it's related - UPDATE: found this to not be related) and made no difference for this problem:

Product EAV index process error during indexation process: Deprecated Functionality: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /home/********/public_html/vendor/magento/module-catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php on line 444

My previous installation of 2.4.3-p1 that I just upgraded from, this worked as intended (out of stock variations could not be selected/clicked. It showed a cross-through of the variation that was out of stock). It now does not do this, after upgrading to 2.4.4.

Below are screenshots of the product page as well as the admin/backend showing 0 for default stock quantity. This example is shown on the stock Magento Luma theme.

magento-244-frontend-instock-bug-product_view magento-244-frontend-instock-bug-backend_settings

EDIT/UPDATE: The original report of EAV indexing (using CLI) failing might be related, was incorrect. It is not related and made no difference for the bug of "Product with Salable Qty of 0 shows 'In Stock' on product page" - they are separate issues.

Additional Information: https://github.com/magento/magento2/issues/35319#issuecomment-1101209973


Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

m2-assistant[bot] commented 2 years ago

Hi @FadedOut. Thank you for your report. To speed up processing of this issue, make sure that you provided the following information:

Make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, review the Magento Contributor Assistant documentation.

Add a comment to assign the issue: @magento I am working on this

To learn more about issue processing workflow, refer to the Code Contributions.


:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

VZeroCool commented 2 years ago

@magento give me 2.4-develop instance

magento-deployment-service[bot] commented 2 years ago

Hi @VZeroCool. Thank you for your request. I'm working on Magento instance for you.

magento-deployment-service[bot] commented 2 years ago

Hi @VZeroCool, unfortunately there is no ability to deploy Magento instance at the moment. Please try again later.

m2-assistant[bot] commented 2 years ago

Hi @engcom-November. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

engcom-November commented 2 years ago

Hi @FadedOut , Thank you for reporting and collaboration. Verified the issue on both Magento 2.4.3-p1 instance and 2.4.4 version after upgrading from 2.4.3-p1. Observations: Scenario 1: Existing Product - If Product Quantity is > 0 and Salable Quantity is 0 - User is able to select swatch and on clicking "Add to Cart" button - "The requested qty is not available" error message is displayed. Same behavior observed before and after upgrade image

Scenario 2: Existing Product - If both Product Quantity & Salable Quantity = 0, User is not able to select swatch (Crossed out) in 2.4.3-p1 instance and "The requested qty is not available" error message is displayed in 2.4.4 version image

Scenario 3: New Product created in 2.4.4 version with Product Quantity 0 - "There are no source items with the in stock status" error message is displayed But re-indexing working fine in all cases. image

2.4-develop branch behavior: image

engcom-November commented 2 years ago

@magento give me 2.4-develop instance

magento-deployment-service[bot] commented 2 years ago

Hi @engcom-November. Thank you for your request. I'm working on Magento instance for you.

magento-deployment-service[bot] commented 2 years ago

Hi @engcom-November, unfortunately there is no ability to deploy Magento instance at the moment. Please try again later.

github-jira-sync-bot commented 2 years ago

:white_check_mark: Jira issue https://jira.corp.magento.com/browse/AC-2877 is successfully created for this GitHub issue.

m2-assistant[bot] commented 2 years ago

:white_check_mark: Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

FadedOut commented 2 years ago

Thank you @engcom-November for verifying.

mikehobin commented 2 years ago

This happens for me in a test site using PHP 8.1, but if I revert to 7.4 the error goes away.

freakpol commented 2 years ago

This error:

Product EAV index process error during indexation process: Deprecated Functionality: explode(): Passing null to parameter #2 ($string) of type string is deprecated in vendor/magento/module-catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php on line 444

Is also happening for us. There are bunch of entries with null values on the eav tables. And that particular line, under PHP8.1 is preventing the proper reindex of the EAV indices.

FadedOut commented 2 years ago

@freakpol

Yeah it's weird, for me, if I run the command: bin/magento indexer:reindex then the error shows in the terminal. And in the Magento Admin [index management] it will say "Reindex Required" for the Product EAV. But the odd part: if I don't run the command and let CRON do it, the "Reindex Required" doesn't appear, it seams to run fine when ran by CRON.

So I'm not sure what is going on there, if the Product EAV is not really ever being completed correctly...but @engcom-November said reindexing was working fine for him, so I don't know...

And are you talking about the "catalog_product_index_eav" table? If so, I didn't see any "NULL" but I do have quite a few "1"s under the 'value' column. I'm guessing that's not correct. It's also bloated, like 75k rows. Not sure if that is correct... magento-catalog-product-eav-table

jas8522 commented 2 years ago

Upgraded 2.4.0-p1 to 2.4.4 and same issue regarding in stock status being wrong. PHP 7.3.x when on 2.4.0, now PHP 7.4.29 on 2.4.4

No errors or warnings when indexing:

bash-4.4$ php74 bin/magento indexer:reindex
Design Config Grid index has been rebuilt successfully in 00:00:00
Customer Grid index has been rebuilt successfully in 00:00:01
Product Flat Data index has been rebuilt successfully in 00:00:10
Category Flat Data index has been rebuilt successfully in 00:00:00
Category Products index has been rebuilt successfully in 00:01:14
Product Categories index has been rebuilt successfully in 00:00:00
Catalog Rule Product index has been rebuilt successfully in 00:00:01
Product EAV index has been rebuilt successfully in 00:00:01
Stock index has been rebuilt successfully in 00:00:00
Product Price index has been rebuilt successfully in 00:00:18
Catalog Product Rule index has been rebuilt successfully in 00:00:00
Catalog Search index has been rebuilt successfully in 00:00:41
Additional Promotion Action Product index has been rebuilt successfully in 00:00:00
Additional Promotion Action Product Rule index has been rebuilt successfully in 00:00:00

No system logging occurs or critical logging and there are no XHR requests generated when switching attributes.

I do get this critical error, but it doesn't appear to be connected to the loading of the page or selecting an attribute:

[2022-04-27T16:26:13.295234+00:00] main.CRITICAL: Magento\Framework\View\Asset\ContentProcessorException: Compilation from source: LESS file is empty: frontend/THEME/base/en_CA/Magento_Swatches/css/swatches.less in /vendor/magento/framework/Css/PreProcessor/Adapter/Less/Processor.php:99
Stack trace:
#0 /vendor/magento/framework/View/Asset/PreProcessor/AlternativeSource.php(156): Magento\Framework\Css\PreProcessor\Adapter\Less\Processor->processContent()
#1 /vendor/magento/framework/View/Asset/PreProcessor/AlternativeSource.php(114): Magento\Framework\View\Asset\PreProcessor\AlternativeSource->processContent()
#2 /vendor/magento/module-developer/Model/View/Asset/PreProcessor/PreprocessorStrategy.php(78): Magento\Framework\View\Asset\PreProcessor\AlternativeSource->process()
#3 /vendor/magento/framework/View/Asset/PreProcessor/Pool.php(77): Magento\Developer\Model\View\Asset\PreProcessor\PreprocessorStrategy->process()
#4 /vendor/magento/framework/View/Asset/Source.php(152): Magento\Framework\View\Asset\PreProcessor\Pool->process()
#5 /vendor/magento/framework/View/Asset/Source.php(121): Magento\Framework\View\Asset\Source->preProcess()
#6 /vendor/magento/framework/View/Asset/File.php(185): Magento\Framework\View\Asset\Source->getContent()
#7 /vendor/magento/framework/View/Asset/MergeStrategy/Direct.php(81): Magento\Framework\View\Asset\File->getContent()
#8 /vendor/magento/framework/View/Asset/MergeStrategy/Direct.php(60): Magento\Framework\View\Asset\MergeStrategy\Direct->composeMergedContent()
#9 /vendor/magento/framework/View/Asset/MergeStrategy/FileExists.php(44): Magento\Framework\View\Asset\MergeStrategy\Direct->merge()
#10 /vendor/magento/framework/View/Asset/Merged.php(111): Magento\Framework\View\Asset\MergeStrategy\FileExists->merge()
#11 /vendor/magento/framework/View/Asset/Merged.php(183): Magento\Framework\View\Asset\Merged->initialize()
#12 /vendor/magento/framework/View/Page/Config/Renderer.php(420): Magento\Framework\View\Asset\Merged->rewind()
#13 /vendor/magento/framework/View/Page/Config/Renderer.php(297): Magento\Framework\View\Page\Config\Renderer->renderAssetHtml()
#14 /vendor/magento/framework/View/Page/Config/Renderer.php(284): Magento\Framework\View\Page\Config\Renderer->renderAssetGroup()
#15 /vendor/magento/framework/View/Page/Config/Renderer.php(137): Magento\Framework\View\Page\Config\Renderer->renderAssets()
#16 /vendor/magento/framework/View/Result/Page.php(252): Magento\Framework\View\Page\Config\Renderer->renderHeadContent()
#17 /vendor/magento/framework/View/Result/Layout.php(171): Magento\Framework\View\Result\Page->render()
#18 /vendor/magento/framework/Interception/Interceptor.php(58): Magento\Framework\View\Result\Layout->renderResult()
#19 /vendor/magento/framework/Interception/Interceptor.php(138): Magento\Framework\View\Result\Page\Interceptor->___callParent()
#20 /vendor/magento/framework/Interception/Interceptor.php(153): Magento\Framework\View\Result\Page\Interceptor->Magento\Framework\Interception\{closure}()
#21 /generated/code/Magento/Framework/View/Result/Page/Interceptor.php(23): Magento\Framework\View\Result\Page\Interceptor->___callPlugins()
#22 /vendor/magento/framework/App/Http.php(120): Magento\Framework\View\Result\Page\Interceptor->renderResult()
#23 /vendor/magento/framework/App/Bootstrap.php(264): Magento\Framework\App\Http->launch()
#24 /pub/index.php(30): Magento\Framework\App\Bootstrap->run()
#25 {main} [] []

However since nobody else has reported that, I'm betting it's not related.

FadedOut commented 2 years ago

So the error when running reindex by CLI must be related to being on PHP 8.1, seeing how it's not doing it for @jas8522 while on PHP 7.4.x

But that also means, maybe then the Product EAV doesn't have to do with the stock? My table does have the "attribute_id" column in it, so maybe that is a separate issue (having to do with the attributes). Would have been nice to have been related so it could help pinpoint the stock visibility issue to help fix it quicker. This issue is a pain for my customers right now, it's like wack-a-mole checking which products are ACTUALLY in stock.

@mikehobin when you say the "error goes away" when going to PHP 7.4, do you mean the stock for each product shows correctly when on 7.4 compared to 8.1 or the "Product EAV index process error" when running the reindexing command goes away when returning to PHP 7.4?

@jas8522 Relating to your critical error, it appears it has something to do with your theme possibly? It specifies something with the LESS file being empty, maybe your theme isn't being compiled correctly? I would switch to Luma, flush all cache & run all the usual commands (I personally run the following: php bin/magento cache:clean ; php bin/magento cache:flush ; rm -rf var/cache/ ; rm -rf var/page_cache/ ; rm -rf var/view_preprocessed/ ; rm -rf pub/static/ ; rm -rf generated/code/ ; rm -rf generated/metadata/ ; php bin/magento setup:upgrade ; php bin/magento setup:di:compile ; php bin/magento cache:flush ; php bin/magento cache:clean ; php bin/magento setup:static-content:deploy) and check if that error stops happening in the log file when doing what you did to make that error occur in the first place. Best way to narrow down that issue (if it is theme related or not).

jas8522 commented 2 years ago

@FadedOut Thanks for the tips! I'm still fairly certain the critical error is not connected to this bug, so I'm happy to simply leave it as a footnote here in case a correlation does arise with other users. (Will continue troubleshooting it separately).

I'm most concerned about ensuring stock status display is repaired.

FadedOut commented 2 years ago

@jas8522 No problem 🙂. Hopefully you can get to the bottom of it

"I'm most concerned about ensuring stock status display is repaired." <- This I agree entirely, hopefully we get an update on this in the near future (though I fear we might be waiting a long time because some bugs - even deemed pretty important - seem to take months to get fixed ☹). Wish I knew how to code, I would help but unfortunately that is far above my ability 😕

jas8522 commented 2 years ago

I fear we might be waiting a long time because some bugs - even deemed pretty important - seem to take months to get fixed ☹ Don't I know it :(

I sure hope there will be some priority on 2.4.4 regressions because they just forced everyone to upgrade to this version to patch their latest high severity security flaw... There was no patch for 2.4.0 for this (only options were 2.4.3-p2 and 2.4.4), so we had no choice, otherwise I would have simply patched and not had to deal with this headache.

FadedOut commented 2 years ago

Yikes, yeah that's not fair to store owners, they definitely should have provided a patch. Not everyone likes to do major changes/upgrades like that. Esp if you got a busy business running and problems like this (or others, which 2.4.4 seems to have quite a few of) happen. Downtime is the super no-no for businesses (or a new barrage of support emails/frustrated customers).

hostep commented 2 years ago

@jas8522: the latest security fix you mention requires admin privileges, so it's not as bad as you might think it is. Also, if 2.4.4 gives you many issues (and a lot are being reported here on github, but that was expected for such a big release) it would probably be better to move to 2.4.3-p2 and wait on 2.4.5, than you'll also get an opportunity to even move to 2.4.3-p3 in case 2.4.5 is still buggy while still getting the latest security fixes.

loic-paquin commented 2 years ago

Hello @FadedOut

I had the same problem on my websites, it seems the problem is related to this commit https://github.com/magento/magento2/commit/332038ecfeed9161360780a927a54865afd09d87

As a quick and dirty fix you change the fonction getOptions from Magento/ConfigurableProduct/Helper/Data.php to the code used in 2.4.3 :

public function getOptions($currentProduct, $allowedProducts)
    {
        $options = [];
        $allowAttributes = $this->getAllowAttributes($currentProduct);
        foreach ($allowedProducts as $product) {
            $productId = $product->getId();
            foreach ($allowAttributes as $attribute) {
                $productAttribute = $attribute->getProductAttribute();
                $productAttributeId = $productAttribute->getId();
                $attributeValue = $product->getData($productAttribute->getAttributeCode());
                if ($product->isSalable()) {
                    $options[$productAttributeId][$attributeValue][] = $productId;
                }
                $options['index'][$productId][$productAttributeId] = $attributeValue;
            }
        }
        return $options;
    }

A cleanier way would be to override/plugin getJsonConfig from the class \Magento\Swatches\Block\Product\Renderer\Configurable so we can implement our own getOptions method for Swatches and keep the current behaviour on dropdown.

The getJsonConfig method , introduces in 2.4.4, 2 new properties canDisplayShowOutOfStockStatusand salable. Those properties are used in Magento/ConfigurableProduct/view/frontend/web/js/configurable.js (used in dropdowns) but nothing has changed in swatch-renderer.js ( used for swatches). I tried to change the implementation in the .js file but I gave up and just changed the getOptions method instead.

jas8522 commented 2 years ago

As a quick and dirty fix you change the fonction getOptions from Magento/ConfigurableProduct/Helper/Data.php to the code used in 2.4.3 :

Thank you for this! I replaced just the conditional starting with if ($this->canDisplayShowOutOfStockStatus()) { with:

if ($product->isSalable()) {
  $options[$productAttributeId][$attributeValue][] = $productId;
}

And now out of stock options do not appear in the dropdown.

For those using composer, it's in vendor/magento/module-configurable-product/Helper/Data.php

FadedOut commented 2 years ago

@loic-paquin Nice! I've only tested for a few minutes as this is a busy day for me but that seems to be the trick fix! I wonder if there are any regression problems that will pop-up... nice work figuring that out though 😀thank you for this!

@jas8522 And thank you for giving more of a pointer of where to find and replace. Both yours and the info from @loic-paquin helped me pinpoint the change necessary. Much appreciate it! So far in my quick test it appears to have indeed fixed it. As I said to loic-paquin, I wonder if there will be any regression issues that will pop up. Will have to do some more tests, but quickly checking it seems to be okay.

Thanks again to the both of you 😃. This will make many happy because it seems it is a problem for many. Not sure how this type of a fix comes from average Magento users so quickly and not Magento devs....where they at? Thanks to the smart members on here the users with these problems can still get [quicker] help.

mohammedTBB commented 2 years ago

Hello I had the same error after updating from magento 2.4.3-p1 to magento 2.4.4 and php 7.4 to php 8.1

while running index this error is showing: Product EAV index process error during indexation process: Deprecated Functionality: explode(): Passing null to parameter #2 ($string) of type string is deprecated in /var/www/html/imprimir-etiquetas/vendor/magento/module-catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php on line 444

And I have managed to know that it is happening because one of the product custom attributes dose not have an option assigend although the attribute is optional.

so the $row['value'] is empty and according to php8.1 Passing null to non-nullable internal function parameters is deprecated https://php.watch/versions/8.1/internal-func-non-nullable-null-deprecation

so the solution I have made is chagne file vendor/magento/module-catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php line 444 to : $values = explode(',', (string) $row['value']);

the error is not showing any more.

FadedOut commented 2 years ago

@mohammedTBB Thanks for that! This seemed to work.

It is odd though, running the command would cause that error in the terminal. Then in Magento backend, it would say "Reindex Required" but the "Updated" time would say it was updated at the same time as the command was ran. Then also if the reindex ran by cron the "Reindex Required" went away and it would say "Ready". Odd to say the least - not sure if the product EAV actually ever ran correctly (I'm guessing not). When running the command now with your fix it takes me like 15 seconds for it to complete the product eav (I do have probably 1k attribute options) - so it seems important to run correctly would be my guess. So, I much appreciate finding that change to get it fixed up for us 👍

ihor-sviziev commented 2 years ago

Looks like this issue was fixed in https://github.com/magento/magento2/commit/d255ba3fb31db0bea0f8b9fea96d33a85cf5e091 @FadedOut @engcom-November, could you confirm that?

FadedOut commented 2 years ago

@ihor-sviziev I made the change listed in the commit you linked and it seems the reindexing of EAV is working as intended. Though, the change posted above from @mohammedTBB had worked for me as well - but this commit change looks more thorough (and proper) so I will stick with this implementation. So, thanks for linking that 👍.

@ihor-sviziev The commit you linked to fixes the reindexing issue as shown here: https://github.com/magento/magento2/pull/35669 & here: https://github.com/magento/magento2/pull/35483 but does not fix this OP bug ("Product with Salable Qty of 0 shows 'In Stock' on product page") - that was fixed with a hack posted by @loic-paquin and @jas8522 above. A more proper fix would be nice but it seems they might be "working on it" I don't know - so many thanks to the quick fixes by those two or we'd be waiting months for a working visible stock standard functionality.

/side note: unfortunately I mentioned a different bug in the same report (salable qty 0 shows in stock & eav reindexing failing). I originally thought they were related only to later find out they were not so now this report is being referenced related to the EAV reindexing and they're not related.

engcom-Hotel commented 2 years ago

Hello @FadedOut,

As I can see this issue got fixed in the scope of the internal Jira ticket AC-2877 by the internal team Related commits: https://github.com/magento/magento2/search?q=AC-2877&type=commits

Based on the Jira ticket, the target version is 2.4.6

Thanks

cptX commented 1 year ago

Hi, please correct me if my input is wrong or irrelevant. I'm strugling to find a solution for an option of a configurable product to be striked-through instead of normally displayed in case it is out-of-stock. After a lot of searching I ended up to this patch MDVA-34850 here https://experienceleague.adobe.com/tools/commerce-quality-patches/index.html But I checked my 2.4.5 community installation and this patch was already implemented in the code but I still don't get the correct behavior! So to be honest I don't understand what is happening? My target is to have all options visible and the out-of-stock ones striked-through! How can we accomplish this in the current situation? Is this planned to be solved in 2.4.6?

drinkingsouls commented 1 year ago

I am having a similar issue. I can reindex Product EAV fine from command line. If I use an Admin Reindex module from Mageplaza or Bss Commerce or another vendor I get an issue with a null value.

Deprecated Functionality: explode(): Passing null to parameter #2 ($string) of type string is deprecated in vendor/magento/module-catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php on line 444

Changing line 444 from: $values = explode(',', $row['value']); To $values = explode(',', (string) $row['value']);

Makes this PHP8.1 compatible. Is this just missing 8.1 compatibility or does it signal something incorrectly set or missing in my database for product attrributes?

FadedOut commented 1 year ago

@drinkingsouls

Pretty certain that just means it's missing PHP 8.1 compatibility. Because that was popping up for me on a few different modules (the $string with null error). Once they were updated for PHP 8.x those errors went away.

drinkingsouls commented 1 year ago

@FadedOut thanks for the response. This issue should be addressed in the module rather than Magento itself?

FadedOut commented 1 year ago

@drinkingsouls No prob. Yup, it has to be fixed in the module because Magento works fine with PHP 8.x now. So if you're still getting problems like that it's because the module is not compatible with PHP 8.x - you'd have to bring that up with the module developers.

cptX commented 1 year ago

Guys the issue here is actually "Product with Salable Qty of 0 shows 'In Stock' on product page". By mistake it was correlated with "Product EAV index process error" as explained by @FadedOut . So please let's stick to the initial issue which is also major! I saw here that the fix was merged https://github.com/magento/magento2/commit/1fe7184e67ca089294787cd45c98c44cb0b13bac?diff=unified So my question is when are we going to receive a possible update? We have to wait until March 2023 when the 2.4.6 will be released? Can we apply the changes ourselves manually until an official update comes out?

FadedOut commented 1 year ago

@cptX

You are correct in that this is really about the stock and the dropdowns/swatches.

But A) I did not answer your previous post from a few days ago because you need to be able to read previous posts including the very first line of my OP. If you did, you would have notice that B) There is an interim fix that works fine. You do not need to wait for 2.4.6 and C) Yes, the dev "engcom-Hotel" already said the official fix would be in 2.4.6.

As for using the fix from the official patch posted (by engcom-Hotel on July 18) I had issues with it. So just use what has already been posted that has been confirmed to work. That is what has been already mentioned, the fix linked in my first OP (first line) works fine for now.

Don't get all bent out of shape until you fully read a bug report topic - there has been a temp fix posted. If there wasn't then I could understand your concern (as there are indeed several like these - no temp fixes) but it's not warranted here, thanks to the great members above we have a fix for now.

cptX commented 1 year ago

@FadedOut so if I understood correctly you suggest to use the patch here https://github.com/magento/magento2/issues/35319#issuecomment-1111842395 and not the official patch that is planned to be rolled out in 2.4.6 version? Please bear in mind I have 2.4.5 and not 2.4.4. Can this make a difference? If you believe there are issues with the official patch then how can we expect to arrive in 2.4.6 and work? Have you mentioned the issues you found to the devs? Also, please take into account that I'm not a professional programmer/developer. I just need to build a working and reliable site. Also, I'm completely new to magento. So I don't understand completely all the methodology of solving (important) issues...

FadedOut commented 1 year ago

@cptX

Yes that comment by "loic-paquin" that you linked to is correct. It is also not a "patch" it is simply a hack to make it work. It is not intended to be "official" in any capacity - it is a temporary fix until the official fix is released (2.4.6). You can use this fix for 2.4.5. I am on 2.4.5-p1 and have used that and it works fine (though do remember modifying core files is not recommended for the main reason of when upgrading to a new version of Magento the "hack" gets overridden - I had to reimplement the fix when I upgraded from 2.4.4 to 2.4.5).

As for mentioning that I had "issues" with the official commit does not mean there is any wrong with it. It is simply that it's a code release not for this version (2.4.5), it is code for 2.4.6. Which is why the developer said it would be fixed in 2.4.6.

Magento and it's code can indeed be complicated, so if you're not able to make sense of what to do, you may wish to hire a coder/Magento developer to help you with it. The comments (the fix posted) I believe to be maybe a 4 or 5/10 complicated, you just have to read thoroughly. But, I do understand making changes like that is not for everyone, to which is why I say you may want to hire someone to help with that. The information on how to make it work has been given and there is nothing more that needs to be done or said until the official fix is released with 2.4.6. The fix (also here: https://github.com/magento/magento2/issues/35319#issuecomment-1112289160 ) works so you'll just have to read it thoroughly or you may wish to hire someone to help.

If you do decide to attempt it yourself, the best thing you can do is simple: just make a backup of the file before you modify it. Then modify it and run the standard commands (I use the following for an all-in-one command). Then test if what you did worked. If not, revert the file and try again. But always keep a backup of the file and you'll be fine. It's posted in that comment which file it is.

rm -rf var/cache/* ; rm -rf var/page_cache/* ; rm -rf var/view_preprocessed/* ; rm -rf pub/static/*/* ; rm -rf generated/code/* ; rm -rf generated/metadata/* ; php bin/magento setup:upgrade ; php bin/magento setup:di:compile ; php bin/magento setup:static-content:deploy ; php bin/magento cache:flush ; php bin/magento cache:clean

Sorry I can't help more but I would just be a broken record and be wasting my time - everything you need has been posted already. With that fix you'll have a proper working variation stock visual.

cptX commented 1 year ago

@FadedOut thank you for your detailed answer! I have experience with web programming (drupal coding for 12 years) but it has been always for my own needs, not for customers, so my methodologies are not so polished or widely acceptable. So yes I can detect bugs, and try solutions, but I don't have adequate time to create a fine polished solution from scratch these days, thus I'm relying on the community for hints and ideas. I'm going to try your suggestions and of course I'll be waiting for the official solution in 2.4.6. With time I'll become more experienced in magento and probably I can be more useful to the community too! I'm a bit surprised though why such basic bugs come up. This specific bug according to what I have read, looks like it came up as a regression. It was previously solved in 2.4.3. So do we know why this came up again, and didn't stay solved since 2.4.3?

rohitkumawat17 commented 1 year ago

@FadedOut https://github.com/magento/magento2/issues/35319#issuecomment-1111842395 This is working fine if the product has only one option but If the product has two options like color and size then it shows crossed out for all the options. Any solution??

FadedOut commented 1 year ago

@rohitkumawat17 I'm sorry I'm not following. This topic has plenty of information to help you get this issue resolved. Simply follow the instructions posted above to have the cross-outs working correctly. And these changes still work fine with 2.4.5-p1 (I'm using it currently).

Here: https://github.com/magento/magento2/issues/35319#issuecomment-1111842395 and Here: https://github.com/magento/magento2/issues/35319#issuecomment-1112289160

rohitkumawat17 commented 1 year ago

I am still facing the issue. If the product has 2 attributes size and color.

FadedOut commented 1 year ago

@rohitkumawat17 if you do that fix you will not have the issue. Simple. If you modified the file and it is still doing it, then you've modified it wrong. My current site is living proof it works.

Or you didn't run the proper commands after modifying the file. Run: rm -rf var/cache/* ; rm -rf var/page_cache/* ; rm -rf var/view_preprocessed/* ; rm -rf pub/static/*/* ; rm -rf generated/code/* ; rm -rf generated/metadata/* ; php bin/magento setup:upgrade ; php bin/magento setup:di:compile ; php bin/magento setup:static-content:deploy ; php bin/magento cache:flush ; php bin/magento cache:clean

That's my super-all-in-one command.

rohitkumawat17 commented 1 year ago

Hi, Can you provide me the file? So I can confirm my file if I left anything?

I updated these files:

  1. Swatch-renderer.js
  2. Data.php

On Fri, Jan 27, 2023, 3:53 PM James Noon @.***> wrote:

@rohitkumawat17 https://github.com/rohitkumawat17 if you do that fix you will not have the issue. Simple. If you modified the file and it is still doing it, then you've modified it wrong. My current site is living proof it works.

Or you didn't run the proper commands after modifying the file. Run: rm -rf var/cache/ ; rm -rf var/page_cache/ ; rm -rf var/view_preprocessed/ ; rm -rf pub/static// ; rm -rf generated/code/ ; rm -rf generated/metadata/* ; php bin/magento setup:upgrade ; php bin/magento setup:di:compile ; php bin/magento setup:static-content:deploy ; php bin/magento cache:flush ; php bin/magento cache:clean

That's my super-all-in-one command.

— Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/35319#issuecomment-1406303311, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW67S6NKPDPQDA7CRWJHGITWUOO2ZANCNFSM5TRICPVQ . You are receiving this because you were mentioned.Message ID: @.***>

FadedOut commented 1 year ago

I'm not sure what you modified in swatch-rendering.js as there was no "fix" posted for that file...

Hopefully you have originals of both of those files. Always make a copy/backup of files then modify the new (copied file). If you have the originals, restore them and only make a copy of Data.php.

But no problem I'll add it below. This is for the composer installed Magento - not sure if the file would be the same for the non-composer version. EDIT: I should mention this file is from 2.4.5-p1, so directly replacing it in a 2.4.4 may not be super wise (if you're on 2.4.4 that is) - I'm not sure if anything else in the file changed from 2.4.4 to 2.4.5-p1. Use a program like WinMerge to compare. But ultimately the changes happened on lines 93-110 Magento 2.4.4-2.4.5p1 Variation Swatch Stock Crossout Fix.zip

I put the file into the correct folder structure for you to have a better understanding of where to put it. But as a refresher: ./vendor/magento/module-configurable-product/Helper/

And again, make sure to run that command above after replacing the file. And clearing browser cache.

FadedOut commented 1 year ago

Hello @FadedOut,

As I can see this issue got fixed in the scope of the internal Jira ticket AC-2877 by the internal team Related commits: https://github.com/magento/magento2/search?q=AC-2877&type=commits

Based on the Jira ticket, the target version is 2.4.6

Thanks

@engcom-Hotel

Can you double-check this please. This problem still exists in 2.4.6-p1, we still have to do the hack mentioned here: https://github.com/magento/magento2/issues/35319#issuecomment-1111842395. Will this ever get fixed properly so we can stop hacking files? It has been years with this issue (v2.4.1 in 2020!!! https://github.com/magento/magento2/issues/31117)

@engcom-November @engcom-Alfa @engcom-Bravo @engcom-Charlie

Can someone actually investigate and fix this? You guys add tags with "Progress: done" but it's never actually fixed...

engcom-Bravo commented 1 year ago

Hi @FadedOut,

Thanks for your update.

It is Working as expected in Magento 2.4-develop instance the configurable variation is crossed out and we are not able to add to cart.

Screenshot 2023-07-06 at 3 21 38 PM

Issue is reproducible in Magento 2.4.6-p1 instance.swatches are not crossed out.

Screenshot 2023-07-06 at 3 22 28 PM

It is working as expected in Magento 2.4.7-beta1 instance.swatches are crossed out.

Screenshot 2023-07-06 at 4 10 18 PM

Issue seems to fixed in latest version of the Magento i.e Magento 2.4.7-beta1.kindly upgrade to latest version of the Magento.

Thanks.

davirs commented 11 months ago

Could someone explain if this is possible and how I can apply the fix provided in version 2.4.7 to version 2.4.5?

Thank you

nthurston commented 9 months ago

I think this issue still exists on a product with a mix of swatches and dropdown attributes. It uses swatch-renderer.js (rather than configurable.js) in that case and swatch-renderer only disables the swatch options, not the dropdown options.