ThreeWest

Just updated the crosselling module today and sure enough, I'm getting these errors now. ugh!

If it's fixed, why is it still an issue in the latest version of Prestashop?

This appears to be the case. However, when you have a VPS account with a lot of resources, this is pretty bad as far as the cart goes. I sometimes have to hit save or save and stay 3-4 times before it will do either. I've started just opening a bunch I need to edit at once and when one won't save, just move on to updating another one. By the time I've done that, enough time has passed for the save to work, usually but not all the time but definitely get the errors less when I do it that way. This makes me worry about what will happen on the front end when my order volume increases. Will it error out on checkout because of performance....

Hello, I've been reading the Prestashop help documents for using overrides to add functionality. It seems simple but I have some questions. I have written a private function that makes an xml-rpc call to our warehouse computer. It returns the stock levels for an item based off of the SKU/reference code in real time. Then I take that stock level response and update the database table for that product with the stock level. I need to integrate this code into the shop so that it runs as soon as a customer opens the page for a product so that the stock levels are always up to date. I'm trying to understand what I need to do this and have a few questions: If I add it as an override for /classes/product.php, how do I get the function to execute on the frontend? How do I get it to run before the stock level is displayed? I see a depreciated function for getting the stock levels in product.php, is this the one I should be extending? Thank you.

It's in xxx_stock_available for anyone else wondering. Now I have to write a script that will handle updating this table for combinations. hmmm I still don't get why the quantity field in xxx_product_attribute is not being used instead of the one in xxx_stock_available and now I'm wondering if I can change something so the combinations are displaying the stock levels in xxx_product_attribute instead...

Thank you for this! It works great. I'm running PS 1.6.0.9. The admin way of doing this is just a joke. It should be setup just like the search cron. I have 1500 products which I don't think is a lot considering I originally had 10K and it was taking a whole day trying to regenerate the images for just 1500 products via the admin. Totally unacceptable. The biggest issue is having to keep hitting the back button and hitting regenerate again to continue for hours. Now I can run the script via cron and it can take as long as it wants as long as I can do other things while it's running. Cheers!

In what table are the manually entered stock levels for combinations being stored? They surely aren't being stored in xxx_product_attribute. There is a quantity field there and my script has updated the field in this table but it's not what's being reflected in the quantity area of the product. When I do change the quantity of a combination when editing the product, It is saved and I can see the quantity of that combination on the front end but can find the change nowhere in the database. I need to be able to manipulate these numbers in the database.

I'm running the latest 1.6 version of PS. How or what do I need to change to have the accurate stock levels visible on the front end for combinations when they are chosen by the customer? As it stands, the visible stock level is only that of the primary item for all of the combinations even if the combination is different than the primary. We have 1 item in 6 different colors. Each item has it's own SKU and has it's own stock levels from the warehouse based on that sku. We have a backend script that runs on cron that updates all of the stock levels from the warehouse in real time so we never have people ordering items that are out of stock. We want to be able to create 1 product page for each of our items that come in different colors, etc. but be able to show the customer the real stock level of each color. Right now we have each color listed as an individual product because we can't get the combinations to show the right stock levels. This causes our customers to wade through hundreds of the same products in different colors on the site. Is there a way change the code to make visible the stock level of each combination? UPDATE: Hmmm I see that the right stock level shows when I change to a combination if I manually make the change from edit product - quantities. So now I'm just wondering why if I update the attribute quantities for the same combination in the DB why it still only shows the default item quantity.

This doesn't work for 1.6 by the way.

Thanks. I'll check it out. I just hope this is not the norm with PS. It reminds me of the activities with the Interspire Shopping Cart (now named BigCommerce). It's like this was done on purpose to create business for add-ons just because this particular thing is simply too against the norm to overlook the possibility.

Why on earth are payment options tied to shipping addresses? Having this issue on checkout is terrible for business. I shop online extensively and have never had the payment options withheld until I put in address information. What if I'm in Ireland but want to order a gift from such a shop to a friend in the US? The billing address is Ireland but the shipping is in the US. Someone could set the payment options different for each country? This setup doesn't make sense. Our site hasn't launched yet and I used usertesting.com to get some feedback and every tester said they would abandon the cart because of that payment issue at the bottom of the one page check out. People want to use guest checkouts and they want to see the payment options even if they don't put in their address. They also don't want to have to hit a save button when they do put in an address. The multi step checkout page isn't any better. You can choose your shipping option on the first step but then there is another step called "shipping". If it's the shipping address, it should say shipping address. These checkout pages are poorly designed. I'm using the latest 1.6 too. Simply poorly designed. The rest of the cart is awesome.

I couldn't get my eyes to stop bleeding from the new admin panel made for 3 year olds who are comforted by bright colors. I'm an adult and I need an adult admin panel. I was all angry over this release yesterday but have decided to use the previous version and not upgrade to 1.6 until PS gets it together. I really wish that admin panel doesn't stay but they are so proud of it, I feel like they will so on some level I'm still sitting the fence. I want at least an option to use a different or the old admin panel. The new one had many buttons not working too. I can say I was rather impressed by the rollback feature that worked flawlessly for me. I'm cart hunting and just installed PS so I'm not too depressed about it but I can't image this happening if I had an active store. We've been spoiled by Wordpress. I don't hesitate to hit the update on that and my site never breaks. Which brings me back to the ghastly admin panel... it looks ripped off from Wordpress. Tacky. Very Tacky... Like showing up at ball wearing the same dress as someone else...

Another good cart ruined. Responsiveness should be an OPTION. Especially on the backend. Buttons were failing, theme broken, etc. I did a roll back. Luckily I haven't put this cart into production. If it's going to keep going in the direction of forced layouts, it's better to jump ship now. The backend changes are too much. This isn't Wordpress! Now it looks unprofessional.