cart.quantity returned zero0 but now returns blank

[jbruni]

Expected behavior

In fact, previous behaviour.

Until this Monday (Dec 10, 2018), {{cart.quantity}} output was 0 (number zero) when the cart was empty.

This is the expected behavior.

Actual behavior

Since yesterday, {{cart.quantity}} returns a zero-length string, when the cart is empty.

This has affected several sites we develop. For example, https://macofalltrades.com

This is how the cart preview link looked like until yesterday:

Now, returning empty string, here is how it is looking like:

Steps to reproduce behavior

• Use the Handlebars code snippet shared above.
• Travel back in time, two days ago, before BigCommerce breaking change has been applied. Confirm the code works as expected.
• Return to present time, and confirm the current backwards incompatible behavior.

Related

• cart.items returned empty array [] but now returns blank #1404
• possibly STRF-5640 - Load cart quantity in FE #1379
• possibly Don't fire cart API request if there's no cart ID #1402
• possibly Disable loading of cart on non-cart pages #1401

Request

Please revert this breaking change. Or fix it to be backwards compatible. Thank you! 🙏

[bookernath]

Thanks; we're looking at this with priority this morning.

As an FYI, #1379 / #1401 / #1402 are not related to the regression; however, we are changing our "best practice" for how to interact with the cart to use FE API calls. You can probably fix this issue for yourself in advance of us deploying backend code to fix it by using the method in #1379 - which will go out with Cornerstone 2.7.0.

We still intend to support the old way of doing things (accessing Cart in handlebars) so we're going to get this fixed as soon as possible.

[flair-duncan]

Hi @bookernath - is there an estimated timescale?

Reason being, the BC theme store team are pushing our updates on Fridays, so if it's likely to be resolved on the backend before Friday, we can get on with fixing specific clients sites, rather than our themes. If it's highly unlikely to be implemented this week, we'll focus on fixing our themes.

[carsonreinke]

@bookernath While I understand that BigCommerce wants to change this for accessing the cart, it changes how we do things quite dramatically and it is not the best approach. Cart line items do not have a single use case like presented in that PR.

[bookernath]

@carsonreinke can you give an example of what you mean?

Just to make sure I'm articulating this clearly, we don't plan to do anything with the existing {{cart}} resource - we intend to keep supporting it and all the existing themes and stores that might be using it.

However, towards the goal of making the storefront faster, we plan to move the interactions to the frontend and disable the cart object by default in Cornerstone which will result in a faster response time for the page, especially for stores with certain configurations like a lot of discount rules, or shoppers who have a lot of items in their cart.

Anyone who still wants to use the Cart resource can keep it enabled.

All of the same information - such as the cart line items - can be accessed via our Storefront Cart API, and we've provided a convenience function for that in stencil-utils for accessing it.

[bookernath]

@flair-duncan we plan to get a fix out to our first deployment tier today. Our support team will be equipped to fix any stores they're contacted about. We'll consider a more aggressive deployment across all stores later in the day.

[carsonreinke]

@bookernath I am going to respond on your PR, so not to mix in.

Our support team will be equipped to fix any stores they're contacted about

So we have to contact for a specific store?

[bookernath]

If you want to guarantee it gets fixed as quickly as possible, I'd advise getting a ticket in with our support team. You can mention our internal JIRA issue: STRF-5787 and ask that your store get upgraded to the fixed version.

If you don't get in touch, you'll still get the fix, just possibly later today. We don't have a means of detecting which stores are affected (functionally) by this issue, so we can only accelerate those we know about.

[bookernath]

This fix is deploying to our first deployment tier in production now. Our support team is able to upgrade any stores still affected. Assuming everything goes well in our rollout, all stores should get the fix within 24 hours. I'll post an update if that changes.

[jbruni]

I'm closing the issue because BigCommerce fix deployment has reverted the problem in our stores. All is working fine again, just as before.

Thank you!