Jump to content

xertion

Members
  • Posts

    27
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xertion's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. This seem to be the correct answer to the issue. I tested with Firefox and it seems to work 100% of the time after I tried updating a product ~10 times or so. However - one thing that still is unanswered is how come Google Chrome would allow Prestashop to run the Javascript SOMETIMES but not all the time. As I described in the first post, if I save the product in Google Chrome 10 times, it might work once or twice. If it was just that Prestashop used deprecated/old methods it should not work at all. Confusing.
  2. We have an issue with saving or updating products in our store. When we create a new product, add name "HelloWorld" and try to save the product by clicking "Save and Stay", the page refreshes with a blank Name-field and the information added before clicking the Save button is gone. I've checked the following things: I've used Google Chrome's Network Tab to confirm that the POST request actually contains the new value. It does. I've double checked the MySQL database to make sure that there is no empty rows being created on the failed calls. This does not happen - no data is created or updated in the database on the failed calls. I've checked var/log/apache2/error.log for errors that fit the timestamp of when I save the product. No errors are reported. I've checked Google Chrome Console for Javascript errors. No Javascript error is output. I've checked var/log/mysql.log and var/log/mysql/error.log. No errors that match the timestamp is present. I've set define('_PS_MODE_DEV_', true); in defines.inc.php to see if any debug messages are output. There is no. In the case when we Update products, the old information is there after the page refresh. So the issue is not that it writes data to null, the problem is that it never write any data at all. If we repeat this process ~10 times it will sometime succeed with a green success message, but most of the time it fails without any error being returned in the frontend or in logs. I've encountered this on two separate installations of Prestashop (one 1.6.1.4 and one 1.6.1.5) on the same server. My suspicion is that there is something in the server environment, combined with bad error handling or a bug in Prestashop that cause this error. We've had the sites up and running since Prestashop 1.6.1.5 release without issues. These problems started happening just a few weeks ago but has persisted since then. We have not changed or updated the server either. I've asked the Server Admins to check if the server have run out of memory or storage in any of the partitions. It has not - all partitions is available so any temporary files created should have space available for them. At this point I feel like I've looked into it all but I still can't find the cause of the problem. Any ideas? Anyone ran into similar issues?
  3. Thanks for responding. Well since I'm only adding ONE product to the cart, I don't understand how it could be any of those issues. It can't be that it requires more than 1 package, it can't be that it's out of stock (I already check, but also if its only a single product it doesnt make sense to send a package and wait with one), and it cant be different warehouses or carriers for different products, because like I said, it's only 1 product in my testing. I did do some more testing and it seems like $package_list is suppose to contain the id_address_delivery as the key of each item. Example $package_list = Array([78125] => Array());. In my case, the key of the items in $package_list is 0. Which means, it think that the id_address_delivery is 0. Even though I already added $id_address_delivery to the $cart object. Also, $delivery_option_list ($cart->getDeliveryOptionList()) contains an array of each item in the cart. Here I can see that $id_address_delivery is set to 0. This happens even though I set $this->context->cart->id_address_delivery to my address and called .save(); afterwards to update the entry in the database. (Check my link to my code in first post to see how I add id_address_delivery). The result of $id_address_delivery being set to 0 on the products, is that later in the foreach-loop that I mentioned in previous post, it adds id_carrier and id_warehouse to key 0. Which creates a new key in the array (which results in the order running twice, since it now has 2 keys. One with key 0, one with the real id_address_delivery as key).
  4. I did more testing and debugging. There is a foreach loop in PaymentModule.php:232 that adds id_warehouse and id_carrier to $package_list. If I do a print_r($package_list); before, and after the foreach loop. I can see that the loop has added a second item in the $package_list array with key 0. The item is empty except for id_warehouse and id_carrier keys. See complete array ($package_list) below. This seems to be the reason why it is creating 2 orders/packages since later in the PaymentModule there is a foreach loop that adds an order for each item in the $package_list array... Help? Ideas?
  5. So after additinal debugging it seems like this have something to do with $this->context->cart->getPackageList(); and PaymentModule.php:252 foreach ($package_list as $id_address => $packageByAddress). It seems like Prestashop is intentionally creating 2 orders. On the bottom of the first order it says "LINKED ORDERS" and it displays a link to the second order. However that order contains no products or items. This makes me believe that Prestashop for some reason think that I want to split the order into 2 packages/addresses (back to getPackageList()) even though I only add 1 product in the cart and in the order. Ideas?
  6. I'm building a Payment-module to Prestashop and I'm having issues with the validateOrder() function which creates the order and saves it to the database actually creates 2 orders with the same reference, id_cart and so on. It also sends 2 emails and so on. I use $cart->OrderExists() to check if order already exists before I call validateOrder(). I also made a debug and followed the messages in ps_log table and found the following. As you can see. validateOrder() is only being called once, which remove the idea of it's me that accidently calls the function twice. You also see it only finishes once. But inbetween almost all functions are called twice... My complete controller that handles the payment can be found here: https://dpaste.de/EMYm I call "validateOrder" at line 425. Anyone have any ideas of why validateOrder() would only be called once, but do all its stuff twice? Im running on 1.6.0.9
  7. We have free shipping for orders over a $40. All orders below $40 pay shipping. For accounting reasons, we need to know how much we earn from shippings on the website. Meaning, how many people that pay and how much the total amount is, for shipping. Currently this is not possible to see in Prestashop from what I know... This is only visible on a order-per-order basis by looking on each order's details. But we need to see it for tens of thousands of orders. If no one know how to do this in Prestashop, does anyone know it which table this data is stored so that perhaps we can do a SQL Query to find out?
  8. So we've been having this issue for years now throughout multiple versions. In something like 1 out of 100 orders, the customer address of an order gets replaced by some other user's address. This has been happening over 2 different payment modules so it's not isolated to a specific module. I can't replicate it over and over again. But since we're having ~80,000 orders. That's a lot of orders with wrong addresses even if it only happens occasionally... So what happens is the following... A customer places an order using address "John Doe, King Street 1, London" and in the backend the address of the order becomes "Jimmy Johnsson, Queens Street, Manchester" (A address already in the database, belonging to a completely other customer who placed an order 5 years ago). See screenshot attached or link below: http://imgur.com/MxwZ32R (Blurred out some private information about the customer, but you can see the addresses are completely different). Also as you can see here (http://imgur.com/EfZLhGR) the address that is set to the order, does not even exist in the list of addresses belonging to the customer. You can also see that the REAL address that was entered during checkout is saved and placed in the list of customer addresses. But the "active" address of the order is an address that has nothing to do with the current customer to do at all. Usually it is the same 2-3 address that keep coming back, all of them belonging to users from way back in time. We've been trying everything to figure this error out... Including looking through line-by-line of the payment modules to see if there is some hardcoded address ID in there somewhere... There's not. For anyone interested in one of the payment modules code, that handles the checkout and payment and saving of the addresses. You can see it here: http://paste.ofcode.org/T889rkuq6KEMu6EV4rfrAK As you can see. It uses the posted data from Tools::getValue();, creates a new address and then adds the id of the address to $cart->id_address_delivery and $cart->id_address_invoice. Perhaps there is some bug from updating Prestashop's database over and over again throughout the years of us using Prestashop and moving from version to version. Anyone ran into the same bug/error before? Ideas for solution? EDIT: After additional testing I found out something new. When I check $cart->id_address_invoice and $this->context->cart->id_address_invoice, they are different. For some reason, sometimes the $this->context->cart->id_address_invoice is set to a address that is very far back in time. In my case there are 100,000 addresses in the database that differs the context->cart->id_address_invoice from the cart->id_address_invoice. Now I tried to update the context cart by doing "$this->context->cart->id_address_invoice = $cart->id_address_invoice". It did not work though. Any ideas of how I should update the context->cart->id_address_invoice/id_address_delivery ?
  9. Seriously? How arrogant could you be? After using Prestashop for more than 5 years, I'm so freaking tired of your attitude, responses and just plain arrogance. You seem to think that the people reporting these problems are stay-home moms who set up their hobby store, know nothing about web development and is not worth listining to, because "you know better". The reason I say this is because if you really had read the comments in this thread, and listened to the issues people are reporting, you would laugh at the idea of saying that the solution is the server DOSPageInterval. Yes you are right. DOSPageInterval can help you fix a couple of seconds of load time. But is it 12 seconds people are reporting? No. People are reporting 2min, 5min, 10min load times. Timeouts on server, 500 errors etc. While you guys have been writing this issue off, I have been trying to experiment and find a solution to it. I have yet found the exact reason why the load times are insane as they are. But I have found how to stop it and how to avoid it as a temporary solution. Our temporary solution: It seems like if you login to another user profile that has less permissions, the load time issue is gone. We use the Translator profile and we activate Product-permissions to it. The tabs then load instantly and we can save and update products fine. On the SuperAdmin user profile. which have all permissions activated, the load time are 2-3min long. This is means that you can bascally not use your SuperAdmin to manage your stores products. You need to use a second account with less permissions and therefor I don't see this as a permanent and final solution. But a temporary one. So... there you go Prestashop staff... Hopefully after being spoonfed a clue to the problem, perhaps maybe you will be able to fix it for real this time. Regards A user who will never set up a secondary project in Prestashop ever again.
  10. I just updated to 1.6.0.12 and this issue persists for me. Seems like people are describing slightly different symptoms and problems in this thread. But for me if I go to a product, the tabs (SEO, Warehouse etc) of the product is taking forever to load (Aprox. 2 minutes and 30 seconds load time). If I try to save the product before these tabs are loaded I get an error saying friendly url field etc is missing (Because they haven't been loaded yet in the tabs). We had 1.5.6.2 previously without any issues. Loading products and saving them were done in seconds. We then upgraded to 1.6.0.9 where this issue started, and it's so bad that it's impossible to do day-to-day work tasks. We then upgraded to 1.6.0.12 as I mentioned above, and the issue persists. We have about 5000 products and 400 categories in our store. 99% of our products do not have any attributes or combinations but are just plain, simple, basic products. This issue seem to happen on all products I try to load.
  11. The complete error is: Fatal error: Cannot use object of type Product as array in /modules/ganalytics/ganalytics.php on line 379 Line 379 is the if (!isset($product['price'])) of the wrapProducts() function. Complete code: /** * wrap products to provide a standard products information for google analytics script */ public function wrapProducts($products, $extras = array(), $full = false) { $result_products = array(); if (!is_array($products)) return; $currency = new Currency($this->context->currency->id); $usetax = (Product::getTaxCalculationMethod((int)$this->context->customer->id) != PS_TAX_EXC); foreach ($products as $index => $product) { if (!isset($product['price'])) $product['price'] = (float)Tools::displayPrice(Product::getPriceStatic((int)$product['id_product'], $usetax), $currency); $result_products[] = $this->wrapProduct($product, $extras, $index, $full); } return $result_products; } So I guess there is an issue with the Prestashop Google Analytics module combined with this feature.
  12. I have a large security flaw in our Prestashop 1.5.4.2 installation where users can see eachothers cache. For example, on a customized product text field sometimes we see saved text/data from another user. Or when checking out and it displays the addresses, it is displayed another users address which is cached. So there seem to be a large security bug, where the cache is not restricted to each user id, but the cache seems to be global. Anyone recognize this issue? Anyone have ideas for solution or atleast how to narrow it down to find exactly where the problem is. One thing is that this problem does not seem to happen 100% of the time. It seems to only happen sometimes and there are only few customers have have complained on seeing other users addresses and so on.
  13. We have a blockcategories menu with about 400 categories total including all the subcategories, and this is creating too many links on each of our page, resulting in not-optimal onpage SEO. I want to add rel="nofollow" and some Javascript to all links except the root and the selected category and it's children and siblings. Example: - Subcategory A (Root, dofollow) - Subcategory A-1(Sibling of selected, dofollow) - Subcategory A-2 (Selected, dofollow) - Subcategory A-2-a (Child of selected, dofollow) - Subcategory A-2-b (Child of selected, dofollow) - Subcategory A-2-c (Child of selected, dofollow) - Subcategory A-3 (Sibling of selected, dofollow) - Subcategory B (Root, dofollow) - Subcategory B-1 (Nofollow) - Subcategory B-2 (Nofollow) - Subcategory B-2-a (Nofollow) - Subcategory B-2-b (Nofollow) - Subcategory B-3 (Nofollow) - Subcategory C (Root, dofollow) - Subcategory D (Root, dofollow) I have been successful with Selecting the Root, the Selected and the Children of the selected. However I've been unsuccessful with selecting the Siblings of the selected (That share the same Parent). How do I Select the Siblings of the Selected Category within the Blockcategories .tpl files?
  14. We have a large Prestashop Database where the .sql file is about 300 MB, where we have millions of database entries. Example of our database: • 30,000 ps_address • 105,000 ps_cart_product • 300,000 ps_connections • 25,000 ps_customer • 270,000 ps_guest • 1,500,000 ps_pagenotfound • 350,000 ps_search_index etc. I have tried the 1-Click Auto Upgrade 4 times and I've tried Manual Upgrading in a Local Setting aswell. Each time the Upgrader is having large issues with Updating the Database from 1.4.8.2 to 1.5.4.1. We have now set memory limit to 2 GB, We've set Max Times to 300 and 600 Seconds, Tried 2 Different Server Environments, without any results. When using the Auto Upgrader the Auto Upgrader runs through all the files fine, but when updating the Database it takes an incredible long time and then we get the following error: "Internal Server Error " jqXHR. Now please correct me if I'm wrong, but the reason for this is because of some kind of Time Out or Fatal Error occuring during Prestashop trying to update the Database. We have checked both apache2 error.log and mysql error.log to find what issues are causing these errors. The first time we found out that it ran out of memory (And therefore increased from Prestashop recommended 128MB to 2 GB) and the next time we found out that mysql gave an error about the Log Size. After fixing these issues we have not found any more Fatal errors in the error.logs. When I instead try the Manual Update and run /install/upgrade/upgrade.php it just loads, loads and loads without returning any error really. When I check settings.inc.php file after running the manual upgrade, I can see that Prestashop changed the _PS_VERSION_ to 1.5.4.1 from 1.4.8.2 so the Upgrade File _IS_ doing some things. My personal guess is that your Upgrade Tool is NOT efficient for large databases. I would love to get a solution on this, so please either correct my faults or help us be able to upgrade a "real business" website instead of only being able to upgrade websites with sub 1000 customers.
  15. Hi guys. I just finished updating my store from 1.4.x to 1.5.3.1 and I noticed that in the latest versions of Prestashop, the team has changed the way the URL's works for the products that are using the Home Category. Ofcourse this is a huge problem for us because of having a store for many years means that we got a lot of incoming links to some of our products. If suddenly the URL change, this is negative for our SEO even if a 301 Redirect is possible to mitigate some of the damages. In old Prestashop the URL's to normal products were displayed as store.com/category/id-product/ however all Products that was located in Home Category was using store.com/id-product/. In the lastest version of Prestashop, products in the Home Category is now using store.com/home/id-product/. How do I revert this to the old way? I still want to keep /category/ for all other products. But the ones in Home I need to be displayed in the same way as before. This is not the first time that we've had SEO issues with Prestashop updates. If a team member reads this, I would like you to take these things into considerations when doing updates in the future.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More