Open ivanweiler opened 8 years ago
@ivanweiler Thank you for reporting.
Indeed, this issue exists and we already have the task in our backlog (internal ticket MAGETWO-43095
containing multiple issues) to implement mechanism which would enable browser cache invalidation by the server. There are some more cases caused by this problem: #2339, #3280
We are going to update all the tickets as soon as issue is resolved.
If you have any concerns regarding customer data caching in the local storage please let us know, we are open to discussion. Thank you.
Good to hear it's being worked on, thx.
I'm experiences same bug, is there a date for solution? Thanks
Looks like ( MAGETWO-43095 ) is the internal story where this would actually be solved
same problem here with magento 2.0.7 version.
3 month now... it is great that magento internals create internal tickets but is there any timeline we user can see for the tickets? I see many cases where internal tickets where created month ago and are not solved till today. For us users it would be great just to know if magento works on the tickets and when can we expect solutions. For now internal ticket created means just ok it is documented but we have no info if this will be solved in days, weeks moth or years...
Facing the issue of no customer name in top link because of local storage. Please fix this asap.
Increased priority of the issue.
I updated to 2.0.7, still having problems with this issue
Can't the localStorage be updated regularly by polling the server? Would solve all the problems I think.
I am using Magento 2.1.0 and facing similar issue. Is there any method that I can try ?
I am also struggling with same issue. Awaiting FIX :(
@routbiplab @wclabhinav totally agree - no idea how you can online with this...
v2.1.2 also too
same issues here :(
Is there any solution till ?
Hi @shahankitb997 Currently the issue is still not fixed. We will update the ticket as soon as we have anything to add. Thanks.
it is now one year later since the ticket had been created @shahankitb997 - wow no solution so far!
Well, to be fair, it doesn't seem like something you could fix with one line of code. The whole idea of caching to the local storage (which is: the information in local storage isn't changed until the next POST request because user didn't do any changes) may be misused here. I'm not saying real-time updates are needed here(if it is so, why even bother caching this stuff?), but there should be a way for the server to tell clients the localStorage-cached information was invalidated: maybe, a timestamp of when prices / promotion rules were last changed with each GET response.
Issue is reported on Mar 3, 2016. Still no Solution? More than a year and crucial Issue. Not even work around released. Is there any specific date when it's going to fix or in which release we get this FIXED?
@shahankitb997 Currently there is no specific date for the fix to be delivered, however, based on community feedback, we are looking into ways to increase its priority. I will update this ticket as soon as more information will be available.
Thank you.
@ivanweiler, thank you for your report. We've created internal ticket(s) MAGETWO-78706 to track progress on the issue.
@magento-engcom-team Please see the second comment on the issue. I believe that your recently opened MAGETWO-78706
is actually duplicate of MAGETWO-43095
which has been opened for a year and half now...
omg really reported 3 Mar 2016 and not fixed... a big WOW to the magento2 team. A major checkout issue lasting for over 1.5 years... could pls a magento management team member write a feedback here which internal processes are going totally wrong?
We ran into the same issue for one of our clients.
This doesn't qualify to close the current issue, but it's a work-around so that at least the customer won't see outdated prices.
diff --git app/code/CleanCheckout/DynamicCart/etc/module.xml app/code/CleanCheckout/DynamicCart/etc/module.xml
new file mode 100644
index 00000000000..5574fba777d
--- /dev/null
+++ app/code/CleanCheckout/DynamicCart/etc/module.xml
@@ -0,0 +1,8 @@
+<?xml version="1.0"?>
+<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Module/etc/module.xsd">
+ <module name="CleanCheckout_DynamicCart" setup_version="1.0.0">
+ <sequence>
+ <module name="Magento_Customer" />
+ </sequence>
+ </module>
+</config>
diff --git app/code/CleanCheckout/DynamicCart/registration.php app/code/CleanCheckout/DynamicCart/registration.php
new file mode 100644
index 00000000000..0a3a1b9e408
--- /dev/null
+++ app/code/CleanCheckout/DynamicCart/registration.php
@@ -0,0 +1,9 @@
+<?php
+
+use Magento\Framework\Component\ComponentRegistrar;
+
+ComponentRegistrar::register(
+ ComponentRegistrar::MODULE,
+ 'CleanCheckout_DynamicCart',
+ __DIR__
+);
diff --git app/code/CleanCheckout/DynamicCart/view/frontend/requirejs-config.js app/code/CleanCheckout/DynamicCart/view/frontend/requirejs-config.js
new file mode 100644
index 00000000000..433657b3932
--- /dev/null
+++ app/code/CleanCheckout/DynamicCart/view/frontend/requirejs-config.js
@@ -0,0 +1,9 @@
+var config = {
+ config: {
+ mixins: {
+ 'Magento_Customer/js/customer-data': {
+ 'CleanCheckout_DynamicCart/js/customer-data-mixin': true
+ }
+ }
+ }
+};
\ No newline at end of file
diff --git app/code/CleanCheckout/DynamicCart/view/frontend/web/js/customer-data-mixin.js app/code/CleanCheckout/DynamicCart/view/frontend/web/js/customer-data-mixin.js
new file mode 100644
index 00000000000..3ae1ecedc53
--- /dev/null
+++ app/code/CleanCheckout/DynamicCart/view/frontend/web/js/customer-data-mixin.js
@@ -0,0 +1,24 @@
+define(['underscore'], function (_) {
+ 'use strict';
+
+ return function (target) {
+ /**
+ * We can't use extends here, so create a copy of the original function.
+ */
+ target.getExpiredOriginal = target.getExpiredSectionNames;
+
+ target.getExpiredSectionNames = function() {
+ /**
+ * Retrieve original expired sections.
+ */
+ var expired = target.getExpiredOriginal();
+
+ /**
+ * Always expire the cart.
+ */
+ expired.push('cart');
+ return _.uniq(expired);
+ };
+ return target;
+ }
+});
It essentially makes sure that the cart section is expired in local storage on every request. This section update call only takes ~100ms for us, and doesn't block rendering. So we're pretty happy with the results.
Hope it helps someone!
@breg-13 thank you for joining. Please accept team invitation here and self-assign the issue.
More use cases for this issue: https://github.com/magento/magento2/issues/9043
Additional use case: #3566
I have the same issue on Magento 2.2.3, does anyone has a fix ?
Thanks !
Same happens for customer group obviously: https://github.com/magento/magento2/issues/17565
@magento-engcom-team @ishakhsuvarov
Any update on this issue? It happens when we run the reindex:catalog_product_flat and the product is disabled. The cart page showed the original price instead of the special price.
When we re-enabled the product and saved it will run the reindexRow but the special_price column are null from what I check, it will only generate after I run the reindex:catalog_product_flat command.
I fetch same issue in Magento 2.3.0 where always shown item in in mini-cart even if remove from shopping cart & delete product.
Same here on a update with Magento 2.3.0 Tried this proposal, https://github.com/magento/magento2/issues/3566, but it doesn't work. I am investigating.
Hi @engcom-Bravo. Thank you for working on this issue. Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:
[ ] 1. Add/Edit Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.
[ ] 2. Verify that the issue is reproducible on 2.4-develop
branchDetails
- Add the comment @magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 3. If the issue is not relevant or is not reproducible any more, feel free to close it.
@engcom-Bravo Thank you for verifying the issue.
Unfortunately, not enough information was provided to acknowledge ticket. Please consider adding the following:
"Component: "
label(s) to this ticket based on verification result. If uncertain, you may follow the best guessOnce all required information is added, please add label "Issue: Confirmed"
again.
Thanks!
@engcom-Bravo Thank you for verifying the issue.
Unfortunately, not enough information was provided to acknowledge ticket. Please consider adding the following:
"Component: "
label(s) to this ticket based on verification result. If uncertain, you may follow the best guessOnce all required information is added, please add label "Issue: Confirmed"
again.
Thanks!
:white_check_mark: Confirmed by @engcom-Bravo
Thank you for verifying the issue. Based on the provided information internal tickets MC-30006
were created
Issue Available: @engcom-Bravo, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
@magento give me 2.4-develop instance
Hi @lfluvisotto. Thank you for your request. I'm working on Magento instance for you.
Hi @lfluvisotto, here is your Magento Instance: https://0e1f03ca77e9a92f73d077c81a1b8fc1-2-4-develop.instances.magento-community.engineering Admin access: https://0e1f03ca77e9a92f73d077c81a1b8fc1-2-4-develop.instances.magento-community.engineering/admin_837a Login: d29f5b4b Password: d024662721db
@magento I'm working on it
5 years! well done Magento Core team!
Hi @gabrieldagama any reason priority changed from P1 to P3. Is there any fix internal processing for this problem
@mrtuvn, here is a description of why the priority has decreased: https://github.com/magento/magento2/pull/30140#issuecomment-802824494
Hi @chernenm. Thank you for working on this issue. Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:
Area: XXXXX
label to the ticket, indicating the functional areas it may be related to.2.4-develop
branch@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure. 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.Hi @engcom-Delta. Thank you for working on this issue. Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:
Area: XXXXX
label to the ticket, indicating the functional areas it may be related to.2.4-develop
branch@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure. 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.Here are my thoughts after reading https://github.com/magento/magento2/pull/30140
User adds product to cart. User navigates Price changes internally User Navigates and sees product on current document with price different than what shows in minicart for the added product. ^ Main Issue
Fix: We already output data-product-id / data-price-amount on listings for pricebox and additionally could use schema markup to accomplish this.
Modify to check integrity of price using the data-product-id match and ensure data-price-amount matches localstorage record.
Other things to check/ensure: **special/sale prices? cart rules? catalog rules?
Edit: reviewed cart format in storage and item formatting is gross Should also refactor the format for cart item storage and get rid of the html and let it be built via minicart.js then the price integrity check that would address this would fit better. Additionally cart subtotals in the cached cart storage is html too..
a fix is do-able but requires some refactoring or parsing the html out to match our numbers and recalculate the subtotal properly.
Hi @ivanweiler,
Thanks for your reporting and collaboration.
We have verified the issue in Latest 2.4-develop instance and the issue is reproducible.kindly refer the screenshots.
The price in Cart remains 100 but the price of the Product in Category is updated to 90
Hence Confirming the issue.
Thanks.
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-12946 is successfully created for this GitHub issue.
Description (*)
Hello,
If customer adds product to cart, content of its cart is cached in browsers 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:
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
Preconditions (*)
Magento 2.4-develop
Steps to reproduce (*)
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
Additional Notes (*)
The price is Updated in View and Edit Cart, and in Summary