WalTig

Cron Jobs won't work when your shop is in maintenance mode. However, when you perform a ping on webcron.prestashop.com to get the IP adress and you add that ip address on the maintenance page as if it was your ip address, cron jobs will work even in maintenance mode.

This is an old thread ... but maybe it will ehlp someone someday. I upgraded to 1.6.1.0. and positioning was acting strange: "Live edit" was not working at all (page shows correctly but could not move anything) .... "Positions" could only be seen per module (not for all modules at the same time) .... I was working in Chrome. Switched to IE and everything was okay.

Running your shop in Catalog mode is not the same as normal mode with all products as "not available for order" ..... Even having all products as "not available for order" will not effect your global settings (like the cart function), where Catalog mode does effect the global settings. So ... in reality, there can be cases where one would like to work with Catalog mode while showing product prices. That being said ... the following adjustment was needed but not quite enough for my PS version 1.6.1.0 In product.tpl I also had to change: <form id="buy_block"{if $PS_CATALOG_MODE && !isset($groups) && $product->quantity > 0} class="hidden"{/if} action="{$link->getPageLink('cart')|escape:'html':'UTF-8'}" method="post"> to: <form id="buy_block" action="{$link->getPageLink('cart')|escape:'html':'UTF-8'}" method="post">

I noticed that Prestashop Installation Error at x % still is a popular topic. As a heavy user / developer for own use I have done quite some installs (versions 1.5 and 1.6 in dutch language). And every now and then I am also facing the Prestashop Installation Error at x %. I can agree with the common opinion that it is not a bug in Prestashop (however, a more clear error message and error log would be nice). In case the error is not caused by permissions, the error is caused by server settings. Difficulty is that it is not always caused by server errors, so there is not always usefull info in the error logs. What I noticed today is: - SELinux might have an influence. Disabling SELinux gave a different behaviour (more progress in the installation process). Do not forget to enable SELinux again. - Permission 777 on all folders gave a different behaviour (more progress in the installation process). Do not forget to change the permissons back. - And most striking: after a partial installation it is worth trying to work with Prestashop. I ended up with a perfectly working Prestashop (including 63 installed modules) while the installation stopped at 63% during the installation of the modules. Removing the install folder and renaming the admin folder was enough to have a full functional Prestashop install.

Yes I did. This is what solved it in my case. I found out that (at least 'sometimes') session id's had a very long lifetime and that customers (within a company) with terminal sessions sometimes share session id's. Even though this was not the case for every (other) customer with terminal sessions. At two different points in the process I destroy the user cookies and session ID's. Mind you that this might be a bit of a overkill (but that does not bother me). Maybe destroying the cookies and session id at only one point would be enough. Or, maybe just renewing the session id would be enough. So if you are struggling with the same problem, you can try and see whether my solution is working for you too. If so, you can play a bit with the code and start decreasing the number of steps if you like. Untill you changed so much that the solution is not enough anymore. When you have reason to decrease the code, my best guess would be: you don't need the code at logout. And you can keep the 1st line and the last 4 lines. Skip the lines in between. Try and see if that works. Most important point imho is after closing an order since the biggest problem was customers mixing up their carts and orders. Or otherwise, keep the full code at both points. I did never feel the need to review the code once I started to use it. At (1) user logout (in class 'Customer' in function 'mylogout' ) and at (2) order confirmation (in class 'OrderConfirmationController' just before calling order-confirmation.tpl) I added a few lines to unset the cookies and to renew the session id. And for one particular customer (the one with the terminal sessions) I used an one-time-only script based on their current session id to detroy that session id the first (next) time they entered the webshop. This to ensure that they stop sharing that id. After that we do not face this problem anymore (and it the past it was a daily problem). $cookie = Context::getContext()->cookie; unset($_COOKIE[$this->_name]); unset($cookie->detect_language); unset($cookie->id_customer); unset($cookie->logged); unset($cookie->id_guest); unset($cookie->passwd); unset($cookie->customer_firstname); unset($cookie->customer_lastname); unset($cookie->id_cart); $this->context->cookie->PHPSESSID = ''; $_SESSION = array(); session_destroy(); setcookie("PHPSESSID","",time()-3600,"/"); Good luck!

Thanx for your fast response though. In the mean time I have found a solution. That is how things go all the time. A few minutes after placing a post I will find the solution. Already for that reason writing a post is valuable. I have read some posts about deleting and recreating .htaccess but IMHO that's nonsense (for this specific situation that is). This is what did the trick for me: Adding the following lines to the nginx configuration in the server{} block - which is not in the location / {} block (tried that block too but was not solving my problem): rewrite ^/api/?(.*)$ /$baseUri/dispatcher.php?url=$1 break; rewrite ^/([a-z0-9]+)\-([a-z0-9]+)(\-[_a-zA-Z0-9-]*)/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1-$2$3.jpg last; rewrite ^/([0-9]+)\-([0-9]+)/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1-$2.jpg last; rewrite ^/([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$1$2.jpg last; rewrite ^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$1$2$3.jpg last; rewrite ^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$3/$1$2$3$4.jpg last; rewrite ^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5.jpg last; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6.jpg last; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7.jpg last; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8.jpg last; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?/[_a-zA-Z0-9-]*\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9.jpg last; rewrite ^/c/([0-9]+)(\-[_a-zA-Z0-9-]*)/[_a-zA-Z0-9-]*\.jpg$ /img/c/$1$2.jpg last; rewrite ^/c/([a-zA-Z-]+)/[a-zA-Z0-9-]+\.jpg$ /img/c/$1.jpg last; rewrite ^/([0-9]+)(\-[_a-zA-Z0-9-]*)/[_a-zA-Z0-9-]*\.jpg$ /img/c/$1$2.jpg last; rewrite ^/([0-9]+)\-[a-zA-Z0-9-]*\.html /product.php?id_product=$1 last; rewrite ^/[a-zA-Z0-9-]*/([0-9]+)\-[a-zA-Z0-9-]*\.html /product.php?id_product=$1 last; rewrite ^/([0-9]+)\-[a-zA-Z0-9-]*(/[a-zA-Z0-9-]*)+ /category.php?id_category=$1&noredirect=1 last; rewrite ^/([0-9]+)\-[a-zA-Z0-9-]* /category.php?id_category=$1 last; rewrite ^/([0-9]+)__([a-zA-Z0-9-]*) /supplier.php?id_supplier=$1 last; rewrite ^/([0-9]+)_([a-zA-Z0-9-]*) /manufacturer.php?id_manufacturer=$1 last; rewrite ^/content/([0-9]+)\-([a-zA-Z0-9-]*) /cms.php?id_cms=$1 last; rewrite ^/content/category/([0-9]+)\-([a-zA-Z0-9-]*) /cms.php?id_cms_category=$1 last; rewrite ^/page-not-found$ /404.php last; rewrite ^/address$ /address.php last; rewrite ^/addresses$ /addresses.php last; rewrite ^/authentication$ /authentication.php last; rewrite ^/best-sales$ /best-sales.php last; rewrite ^/cart$ /cart.php last; rewrite ^/contact-us$ /contact-form.php last; rewrite ^/discount$ /discount.php last; rewrite ^/guest-tracking$ /guest-tracking.php last; rewrite ^/order-history$ /history.php last; rewrite ^/identity$ /identity.php last; rewrite ^/manufacturers$ /manufacturer.php last; rewrite ^/my-account$ /my-account.php last; rewrite ^/new-products$ /new-products.php last; rewrite ^/order$ /order.php last; rewrite ^/order-follow$ /order-follow.php last; rewrite ^/quick-order$ /order-opc.php last; rewrite ^/order-slip$ /order-slip.php last; rewrite ^/password-recovery$ /password.php last; rewrite ^/prices-drop$ /prices-drop.php last; rewrite ^/search$ /search.php last; rewrite ^/sitemap$ /sitemap.php last; rewrite ^/stores$ /stores.php last; rewrite ^/supplier$ /supplier.php last;

I can see your shop is okay now. I'm curious how you fixed the problem with the images since I am facing the same problem now. Prestashop 1.6 on a nginx server and after i enable the friendly URLs feature, the product images don't show anymore. I have added the same configuration as you did. What was your soultion? Was it in the configuration (then: can you show me yours)? Or did you find the solution somewhere else?

Well, this is an old thread. However, I would be very interested in knowing the alternative method which doesn't show any carrier at all. Only the link is broken. Can somebody provide more info? This is why: I use Prestashop as a B2B-solution. We don't have one-time-only customers. we have relations with our customers for many years. The carrier and the fee for transport differ from one customer to another. Some customers have to pay. Some customers have free transport. Anyway, this all is stored and handled in our ERP system (we import the Prestashop order in XML format in our ERP system). So we don't want to bother the webshop customer with carriers, but we don't want to tell them that transport is free (because in many cases it is not). Just ignoring (not mentioning) the carrier module would be the best option for us. Thanks in advance.

Sometimes the cause of a problem is in another place than where you are looking. I had the same message when adding a carrier. TECHNICAL ERROR: Details: Error thrown: [object Object] Text status: parsererror Found out I cannot use a equals sign (=) in the field where you fill in the description for the delay. Replacing the equals sign with a minus sign (−) solved my problem. God ways are mysterious, so are Prestashop ways.

Hmmm, looks like I'm the only one having this problem? Anyway... this case popped up in my head every now and than this weekend and I was wondering... Maybe it makes sense to make all cookies "account-related". So that every account will use only his own cookies even when he's sharing the same machine and same IP address with other accounts. The only question is "how" can I do that? The thing crossing my mind is extending every key with the account number.

Here is the situation: We have a dedicated (Linux) server with Prestashop 1.5.6.1. Multiple users (at one of our customers) are logged in (front office) at the same time. They all have different accounts (mail addresses and passwords). Though they experience strange things like staying connected after log off, seeing each-others name, sometimes they have multiplied cart lines, not selected products are added to the cart, etc. The ("only" as far as I can see) difference with other customers is that these users are working though Terminal Services (Thin Clients). I am a stranger to Terminal Services, but this is what I think: PrestaShop uses the Cookie class to manage session variables. Parameters set in the cookie are given to the client, but in this case to multiple users. Sessions are not really stored on the server. This does mean, I am afraid, that one session will be used by several users in this case. Checking the IP address of the cookie (which is a Prestashop option) has no effect since these users share one IP address. So in fact they are "stealing" each-others cookies. Of course I would appreciate very much getting some hints on this topic: Is the assumption right that using Terminal Services / thin Clients can cause these problems? And in what direction do we have to find the solution? Is it in Prestashop? Or should our customer solve this at Terminal Services side? And if the solution should be found in Prestashop.... is there anybody with experience or knowledge to point me in a certain direction? Thanks in advance.

Okay... that's how things go. More than a day struggling. Then posting the question. And now finding out myself. A stupid mistake: the input field was in between form-tags, but not in between the correct form-tags. SOLVED !!! (even though I don't know how to change that in the topic header.

I want to add a custom input field to the form where the customers confirm their order. I'm struggling with where to read the value of this field. This is what I did: In order-carrier.tpl I added this: <p>{l s='TEST'}</p> <p><input type="text" name="my_test"></p> And so far no problem. It shows perfectly and the customer can give the input. But now.... I have to retrieve the input. I suppose I have to use: $my_test = Tools::getValue('my_test'); Also tried: $my_test = $_POST['my_test']; I tried to place this in several files. But it looks like I cannot find the right place to do this (or I'm overseeing something else). I tried: modules\bankwire\controllers\front\validation.php OrderController.php OrderConfirmationController.php OrderOpcController.php bankwire.php ParentOrderController.php I thought the last one would be the best, since logging shows me that it's the first (processed) in line. EDIT: I thought the first location (validation.php - function postProcess) would be the best, since logging shows me that it's the first (processed) in line. Unfortunately until now I cannot read the value of the input. Of course I would appreciate very much finding someone who's able to give me the hint which will get me out of this headache :-)

And some more info... (using Prestashop 1.5.6.2. and PayPal module 3.6.6). What I wanted to have is: Fee calculation for the customer (I'm okay with combining shipping costs and fee in one amount) Translation for the PayPal payment option in checkout page with informing the customer about the 3,4% + € 0,35 fee This is what I did: ------------------------------------------------------------------------------------------------------------------------------------------------ In file /paypal/express_checkout/process.php To get the fee included in the shipping cost I inserted the next two lines directly after the line (339) $shipping_cost_wt = $this->context->cart->getTotalShippingCost(); $fee = ((($total+$shipping_cost_wt)+0.35)/0.966)-$total; $shipping_cost_wt = $fee; ------------------------------------------------------------------------------------------------------------------------------------------------ In file /paypal/integral_evolution/notifier.php To still have a correct check on the paid amount (otherwise you will receive payment error messages) I inserted the next line directly after te line (67) $tax = $cart_details['total_tax']; $fee = ((($subtotal)+0.35)/0.966)-$subtotal; And I also replaced the next line if ($this->comp($mc_gross, $total_price, 2) !== 0) with this one if ($this->comp($mc_gross, $total_price+$fee, 2) !== 0) ------------------------------------------------------------------------------------------------------------------------------------------------ In file /paypal/views/templates/hook/express_checkout_payment.tpl To enable translation and inform customers about the fee I replaced line (36) {PayPal_content_payment_choice} with this one: {l s='PAY WITH YOUR PAYPAL ACCOUNT (FEE 3,4% + € 0,35)' mod='paypal'} ------------------------------------------------------------------------------------------------------------------------------------------------

I had the same problem as some other users. This topic has [sOLVED] in addition, but I cannot find the solution in this thread. And the last reply before mine is young and also contains the request for a solution. Therefor I add my experience to this thread. Maybe it will help others. My problem: Changes to CMS pages disappear (changes are not saved, even though I try to save them and everything seems to work fine). PrestaShop version 1.5.6.2 My findings: I turned on displaying errors in the file ../config/defines.inc.php by changing define('_PS_MODE_DEV_', false) into define('_PS_MODE_DEV_', true). Then I received an error.... PrestaShopDatabaseException: Unknown column 'indexation' in 'field list'. The executed SQL statement was like this: UPDATE `ps_cms` SET `id_cms` = '1',`id_cms_category` = '1',`position` = '0',`indexation` = '0',`active` = '0' WHERE `id_cms` = 1 And indeed, opening MySQL database, looking at table ps_cms there was no field named indexation. My solution: So I added this new field (ALTER TABLE `ps_cms` ADD `indexation` INT( 1 ) NOT NULL). After this adjustment all works like a charm. Of course one last action: changing back define('_PS_MODE_DEV_', true) into define('_PS_MODE_DEV_', false) again.