benw

I think we've found the problem. It seems to be caused by Apache mod_security. In WHM ModSecurity Tools, there are a lot of 302 errors shown e.g. Request: GET / Action Description: Access denied with redirection to http://www.example.com/ using status 302 (phase 4). Justification: Pattern match "^5\\d{2}$" at RESPONSE_STATUS. Request: GET / Action Description: Warning. Justification: Operator GE matched 0 at TX:outbound_anomaly_score. We managed to fix it by editing ModSecurity Vendors - disabling "OWASP ModSecurity Core Rule Set" and enabling "OWASP ModSecurity Core Rule Set V3.0" instead.

We originally thought this was limited purely to admin users as it only happened when you had been logged into the admin. It has now happened to one of my colleagues who has never logged into the admin, only the front end. This is pretty alarming now, as the site is due to go live soon and we can't have this happening to customers! There is nothing of use in the access and error logs, only hundreds of 302s to the site root (/). There were a load of references to our local development domain in the various connections tables so have emptied those to see if that helps. It's pretty difficult to debug as we haven't found a reliable way to replicate it!

We installed a self signed certificate on our staging server and that doesn't seem to have had an effect as someone in our office has had the redirect issue again. Anyone else have any ideas?

We aren't using an SSL on our staging server at the moment, though the live site will obviously have one. We weren't planning on adding one to our staging server, though I guess there is no harm in adding a self-signed certificate and enabling these options to see if it works.

Hello. We are getting a problem on our Prestashop 1.6 shop where people are randomly experiencing a too many redirects error (lots of 302s to the root /) which makes the whole website inaccessible. This is only happening on our staging server, it doesn't happen on our local environments. The only way to fix it is to delete a cookie which is created at the time of the error. We have tried debugging the contents of this seemingly dodgy cookie, but can't see anything that is stored in it that would cause a redirect issue. We have tried many different things in trying to fix this to no avail: Various .htaccess fixes including regenerating it Disabled the Advanced SEO Friendly URLs module we are using to clean the URLs - https://addons.prestashop.com/en/url-redirects/19643-advanced-seo-friendly-urls.html Tried across a number of browsers, happens in all of them Played around with the various cookie settings including changing the Cookie IP check but this made no difference It can happen 5 times in 10 minutes or you can go days without having the issue. There doesn't seem to be anyway to reliably replicate it. It is also worth noting that we are using PHP7 with the custom Blowfish class. Our current server setup: Prestashop 1.6.1.16 6 core CPU with 8GB RAM CENTOS 7.3 Apache 2.4.27 MySQL 5.6.37 PHP 7.0.23 Thanks

Maybe get the Carrier from the Order (using $order->id_carrier) and then check the "is_free" property of the Carrier ?

I think each fabric does have its own price. That module could work though, similar to this colour example: http://demo.presto-changeo.com/1605awp/index.php?id_product=3&controller=product#/color-blue

One of the products the client sells uses 6 different areas where the customer can select a fabric - and there are 549 different fabrics. That means there is a total of 27 quadrillion possible combinations (27 million billion or 17 decimal digits). 549 to the power of 6 ... Does that mean every possible combination would need to be created (auto generated)? Can Prestashop even handle that many ? Or is there a better way to manage such a product? Thanks,

Solved it. The Classic theme checks whether the variable is set in the template, so I had to copy that to the Starter theme: {theme}/templates/_partials/notifications.tpl {if isset($notifications)} {* template code *} {/if}

With the Starter theme, the Customer "forgot password" page is giving an error: ContextErrorException in smarty_internal_templatebase.php(157) : eval()'d code line 432: Notice: Undefined index: notifications But the error does not happen in the Classic theme, and I can't see the difference - maybe I'm missing something? In "/controllers/front/PasswordController.php", the display() function does NOT pass any notifications to the template: public function display() { $this->context->smarty->assign( array( 'layout' => $this->getLayout(), 'stylesheets' => $this->getStylesheets(), 'javascript' => $this->getJavascript(), 'js_custom_vars' => Media::getJsDef(), 'errors' => $this->getErrors(), 'successes' => $this->getSuccesses(), ) ); $this->smartyOutputContent($this->template); return true; } If I add the notifcations key myself (like in other display functions), then it fixes the error - but I don't want to edit core code, and why doesn't the error happen in the Classic theme? 'notifications' => $this->prepareNotifications()

Nope, but the bug is reported in Forge since last month: http://forge.prestashop.com/browse/BOOM-2697

I'm having the same kind of problems due to lack of documentation. Here are some things I've found out so far that might help. 1.7 documentation (incomplete) http://doc.prestashop.com/display/PS17/English+documentation It's missing the entire "Design" section. I found an article from June 2016 saying it would be released soon but I guess it never happened yet? http://build.prestashop.com/news/module-development-changes-in-17/ The Developers section is also incomplete and just points to: http://developers.prestashop.com/ The GitHub page has some links to updated docs: https://github.com/PrestaShop/PrestaShop/tree/develop In a Smarty template you can display all current variables with {debug} (opens in a popup window).