don@ptg

What we did on the blank orders, is look at the customers cart. The products were still there and it helped us recover the orders.

I noticed our site was responding slower this morning and I noticed an unusually high number of visitors. The culprit at the time seemed to be 91.240.109.1. A google search of that address seems to suggest its something to do with Prestashop software. https://github.com/PrestaShop/cronjobs/issues/7 has people complaining about it and prestashop too. We had no cronjobs and the module talked about in the linked thread was installed but not enabled. It looks like someone during this time was trying to hit /module/cronjobs/callback resulting in a 404, close to 5000 times. We uninstalled the cronjob module just for safety as this entire experience seems very suspect. My question is was this experience truly related to prestashop in some way as the link thread seems to suggest, or was it something else?

I looked in our live site and the downloaded version and the folders and file is there. I am still using the solution I stated in the first post and our site is processing $6000 - $12000 USD a day in sales. I do plan on using Zmacedoni's kind fix soon though.

There is a thread here that already deals with this but I thought that maybe it had gone unnoticed since the newest version of PrestaShop still has the problem. https://www.prestashop.com/forums/topic/465898-error-al-crear-pedido-manual-solucionado/ The our web site was originally launched on 1.6.1.0. The 1.6.1.1 upgrade broke the payment proccess, and we had the same fault with the upgrade to 1.6.1.2 this morning. We have the USA Epay Module from Presto-Chango installed as our only payment module. When the classes/stock/StockAvailable.php is left as is some products would cause the payment window to hang and the page will never redirect. I turned on developer mode to get this error. Fatal error: Uncaught exception 'PrestaShopException' with message 'Property StockAvailable->id_product_attribute is empty' in /home/ptg/public_html/classes/ObjectModel.php:909 Stack trace: #0 /home/ptg/public_html/classes/ObjectModel.php(246): ObjectModelCore->validateFields() #1 /home/ptg/public_html/classes/ObjectModel.php(652): ObjectModelCore->getFields() #2 /home/ptg/public_html/classes/stock/StockAvailable.php(406): ObjectModelCore->update(false) #3 /home/ptg/public_html/Core/Business/Stock/Core_Business_Stock_StockManager.php(128): StockAvailableCore->update() #4 /home/ptg/public_html/classes/stock/StockAvailable.php(472): Core_Business_Stock_StockManager->updateQuantity(Object(Product), '0', -1, NULL) #5 /home/ptg/public_html/classes/order/OrderDetail.php(473): StockAvailableCore::updateQuantity('577', '0', -1) #6 /home/ptg/public_html/classes/order/OrderDetail.php(638): OrderDetailCore->checkProductStock(Array, '2') #7 /home/ptg/public_html/classes/order/OrderDetail.php(678): OrderDetailCore->create(Object(Order in/home/ptg/public_html/classes/ObjectModel.php on line 909 Replacing the classes/stock/StockAvalible.php file with the one from 1.6.1.0 seems to have solved the problem. For both of the newer versions. It does seem to be fixed, but if this is not the correct way to solve the problem, then I would appreciate the feedback. The other thread is difficult for me to follow since I do not read any other language. Google translate seems to help though.

I had this problem too! Lucky I had google translate as there were no solutions in english. Our live 1.6.1.1 PrestaShop install kept showing zero products on some orders and the orders that did show would not empty the shopping cart at times. This led customers to double order when they saw products in their cart. Very unhappy boss and customers. By replacing the classes/stock/StockAvailable.php with the version in 1.6.1.0 and clearing the cache, both problems were fixed immediately. Thank you!

Thank you for the help! It works now.

I am looking for advise on what file truncates the product name to 17 characters in the accessories section on the bottom of the product pages. I did a search of all files in my prestashop folder and four files came up with truncate:18. \modules\blockcart\blockcart-json.tpl \modules\blockcart\blockcart.tpl \themes\default-bootstrap\modules\blockcart\blockcart-json.tpl \themes\default-bootstrap\modules\blockcart\blockcart.tpl I tried changing the instances of truncate:18 in the files to truncate:40, one file at a time, then returning it to its original configuration if no change was noted after a refresh of the page. So far no changes in the files above have increased the product description length. It looks like the files names truncated above have something to do with a discount and are not what I need to change to see the results I am hoping for. Any advice is appreciated.

Thanks to all who replied, I was able to get the database working on the new server without the error using the help from this thread.

Did anyone find a solution to this? I am having exactly the same problem. A little background info. My work has a functioning 1.6.1.0 PrestaShop folder that was installed in a server that needs to be moved to another location. It was upgraded a month ago and the site functions correctly in its original folder. Once the files and database where transfered to another server per http://doc.prestashop.com/display/PS16/System+Administrator+Guide#SystemAdministratorGuide-MovingPrestaShop I keep getting the Key 'id_product_2' doesn't exist in table 'ps_specific_price' on the new server. The database was imported several times, with the same error each time. I installed at fresh install of the last version of PrestaShop and compared the structure of ps_specific_price to the malfunctioning one and they appear to be the same. The first attachment is for the site with the error. The second attachment is for the fresh install. The third attachment is the home page. The admin area functions. It has the same error and a white screen though once you try to move to the products page. I tried the solutions suggested above with exactly the same results as the other members. In my case the problem is still not fixed. The most unusual thing to me is that the database works fine in the old site folder, the problems only show in the new version. The files where moved using ftp. Thank you for the help!

I finally found some information. I searched before, but I was not using the same search terms. http://doc.prestashop.com/display/PS16/System+Administrator+Guide#SystemAdministratorGuide-MovingPrestaShop

Hello, I inherited a mess that I am trying to fix after my work let another employee go. The problem is the site was originally zencart, then when the other employee wanted to install other stores they put them inside each other and used redirects to push visitors to the different folders. Its a mess, so far I have found magento, wordpress, other zencart installs and finally the PrestaShop folders all installed inside a very old zencart structure. The PrestaShop is working and is fairly bug free. I contacted my hositing company (Godaddy)and they recomended destroying everything and starting over with a fresh install of PrestaShop. I saved the database and the sass/css files to try rebuilding a duplicate site on a local server at work. The local server with a new PrestaShop install is supposted to be a duplicate of the live site for testing. Testing on a live site is not the owners prefference. On my first attempt a few strange things happened. The css files were not a problem. Once the database was erased and rebuilt the local host site would not show at all, it kept redirecting to the current live site and my log in for the admin area would not work using the same passwords. I think some of this is caused by the mess on the original site. So I was hoping to find out what database files are required to rebuild the store inventory, order and customer lists and just try importing those into a fresh PrestaShop install by themselves, leaving the rest of the database from the fresh install alone. Thank you for the advice.