Add to Cart never works

[osseonews]

We built this demo store locally, with our unique client id and endpoint, and we were able to see all the pages, navigate etc. However, on the actual product page, the "Add to Cart" button is never functional. It is just greyed out and you can't click it. Is there some other setting required to activate the Cart? Thanks.

[osseonews]

So I figured out that the application needs to actually get a price of a product to create the Add to Cart, but there is no indication that a price needs to be in the JSON file for the product. So are the prices only getting fetched from the Commerce Layer endpoint? Not clear how this works. Also, it looks like the "sku" key in the products.json is what is used to fetch the data from CommerceLayer. If so, what is the purpose of the "variantCode" key?

[marcomontalbano]

Hi @osseonews , Commerce Layer manages SKUs , as you said in the products.json there's an attribute called sku that is the connection between the demo store product and commerce layer. Inside the products.json you can find 3 codes:

1. productCode identifies the master product.
2. variantCode identifies a specific variation for a master product (e.g. a red shirt, or a blue shirt).
3. Sku uniquely identifies a product (e.g. a red shirt with xl size) that can be sold. At the moment the variantCode is used to show different variations when you are using facets or doing a search. This can be also used if you want to show all the variations for a product in the product list page.

Going back to your original question, you already added the client id and the endpoint in your environment variables. As said, the product sku has to be present as sku in your commerce layer organization and your organization need to be properly configured (did you add a price and a stock for that sku?) Last but not least, you should update the countries.json file specifically you should update all market references, pointing them to your commerce layer markets. You don't need to put the price in the products.json; the price will be automatically fetched for commerce layer.

If this still doesn't work, open the developer tool from your browser and check if you have any console error and if you see any network request to commerce layer API endpoint.

I hope that this can help you, and thanks for your feedback. We will update the demo store documentation to better clarify all these aspects.

[osseonews]

Hi @marcomontalbano Thanks for the comments. Yes, we realized that we need to have the SKU in the commerce layer organization and also that we need to update the countries.json file with the correct market id. We did both, but the problem is that whenever we update the products.json file with the correct SKU from our commerce layer organization, we get errors on the frontend. Specifically, one error is Error: Cannot find a Product with sku equal to 5PANECAP000000FFFFFFXXXX

This happens because have changed the SKU in the products.json file to our sku, but for some reason the system is still looking for the old SKU 5PANECAP000000FFFFFFXXXX. We tried to remove the .next folder to clear the cache and rebuild, but it doesn't do anything.

Basically, we cannot figure out how to actually use our own product.json data. We have tried repeatedly to update the products.json file per above with the correct SKU's, but we keeping errors for SKU's that only exist in your implementation of the products.json. Any ideas? Thanks.

[marcomontalbano]

Hi, did you update the pages.json and taxons.json? In these file there are references to skus for our demo.

• pages.json has the "/" route that points to the homepage. This contains few page components and the productGridPageComponent has a list of skus.
• taxons.json is used to build the taxonomies (we can also write something related to this). In the demo store we have two different taxonomies (gender and main category) both contain skus. You can create all taxonomies you need ..the first taxonomy in the list will be used to built the main navigation in the website header. If you just want to test this, you could create one catalog, with one taxonomy and one taxon and put your skus in that taxon. This should fix the error you mentioned and render an updated main navigation.

Let us know

[osseonews]

Thanks. Yeah, we didn't update those. Wasn't sure what they were for. We will update now and see if it fixes the error.

[osseonews]

BTW, fixing the pages.json and taxons.json file worked! But, we also needed to modify the slug in the products.json. Anyway, we can now get our products from commercelayer. Have a few more unrelated issues, i'll post. thanks.

[marcomontalbano]

Thanks a lot for your feedback! We will improve the documentation with all these findings. I'll keep this issue open until that.

[osseonews]

@marcomontalbano below are some more issues I have found. I figured it might be easier to just list them all here instead of opening a new issue for each one:

• [ ] Bug in Cart in Menu: The cart in the Header.tsx (line 71) doesn't update properly when you update the cart on the actual cart page. The Header cart only updates when you add something from a product page. You can recreate this bug, by simply adding items to the cart from a product page and then going to the cart page, updating them (e.g. add/ reduce quantity or delete items), and you will see that the Cart in the menu doesn't update. I assume this is because the Cart page is pulling information via an outside script, and the menu cart is based on a different state? Not sure. But, I think you need some sort of data fetching (e.g. useSWR) for the Menu cart, so it's updated correctly from what is actually in the cart on the backend.

• [ ] SEO Bug for Product Pages for Variants: This is not necessarily a bug per se, but the way the variant product pages are set up is very bad for SEO and going into production with this repo would damage a site. The reason is because each variant, has it's own slug, but in reality the page generated for each variant is the same across all the variants. This is classic case of duplicate content. So for example, product/black-apron-with-white-logo/APRONXXX000000FFFFFFXXXX is the same exact page content as product/white-apron-with-black-logo/APRONXXXFFFFFF000000XXXX. The solution for this is simple. Each variant should have the same exact product slug, you can then grab variants for a product by simply filtering the products.json by the "parent" slug, then presenting the results on the frontend. Right now, the repo just builds the page by filtering for the product sku in the URL, which is why it requires a separate page for each variant.

• [ ] Images Carousel: Feature Request : The Images carousel is missing thumbnails. Thumbnails is part of the Swiper package you use. It's critical to have thumbnails for multiple images, so the user is aware of what images are actually available. This is easy to implement by justing adding the swiper thumbs plugin and passing the correct props. I guess you need to add some key in the images array in the products.json to store these thumbnails for each associated larger image.

• [ ] Removing locale from URL for main locale For most businesses, they probably would have one main locale. Let's say it's in the US. They won't want to have an en-Us in the URL for product pages for that locale. How is it possible to remove the en-us from the URL in that scenario, while retaining the locale for possibly other locations? Can there be some sort of setting that defines the main locale, which will display pages without locale, and then the secondary locales only have the locale in the URL?

That's it. hope it helps.

[marcomontalbano]

Hi @osseonews, thank for sharing these. About the first one we already have an internal card to handle that scenario when the hosted cart is used with embed=true About the SEO issue we are using the canonical url for all the product pages ..all variants point to the first variant of a master product. This should be enough to solve duplicate content. Let us know if this is fine for you. We also have a card to general improve the SEO of the demo-store but currently should be good enough. About last two I'll share them internally.. both look interesting!

[osseonews]

Hi @marcomontalbano Thanks. What does it mean, internal card? That means you are already working on fixing the cart bug? As for SEO: Yes, if there is only 1 canonical, that should be fine. I wasn't able to confirm that. I'll look.

[osseonews]

BTW, I think "Removing locale from URL for main locale " is a critical thing, though obviously not a bug. The issue is that this repo is a low-code way of building a CommerceLayer website. Most low-code website are built by small biz, who will not have websites in multiple countries and languages. So even though it's great to have a solution that can support growth via different languages down the road, if you need to, for immediate needs it's not a good solution. I would think you can set some sort of default value for the location in an ENV variable, and then the main routes in the store can drop the location in the URL, and then only the secondary locations will show up in the URL, if they are used.

[marcomontalbano]

Hi @marcomontalbano Thanks. What does it mean, internal card? That means you are already working on fixing the cart bug? As for SEO: Yes, if there is only 1 canonical, that should be fine. I wasn't able to confirm that. I'll look.

Yes exactly. We already having an internal discussion about that. Demo Store is embedding our Hosted Cart, that's why state is not shared at all.

[osseonews]

Just a quick update, I did some research on the SEO issue and I'm quite convinced that doing it the way you are doing it now, all variants have their own URL even if the canonical URL points to the master product, is not good for SEO. As SEO is critical for any website, I think this is the wrong route to go down. It's also very confusing for a user in terms of a UI, as you have multiple URL's with the same exact content. The correct way to do this is that variants of a product should never have their own URL. Only the master product page should have a URL/Slug. For products that don't have variants, then obviously it's not an issue.