Too many product features – slow back office

The product Features tab contains predefined list of features and values you can select. Sometimes there are dozens or even hundreds of predefined features. The whole list must be loaded, although just few features are used for a given product. This may considerably slow the loading of product page in back office.

A possible quick fix for this situation is to load the features list only if they are needed. For Prestashop 1.6:

  • upload this file
  • unzip and copy to /override /controllers/AdminProductsController.php
  • clear cache or manually delete /cache /class_index.php

The features tab in product page will now contain the button for switching the features in back office on / off . This setting apply for all products.

Important: do not override /override /controllers/AdminProductsController.php if it already exists

The procedure is safe and completely reversible, but cleaning the Prestashop cache is sometimes tricky. If you did not clean the cache for a long time, backup the /cache/class_index.php, clean the cache and wait several days to make sure no hidden problem become manifested after the cache was cleaned. Finally, perform the procedure described above.

Products do not save in PS 1.6

Save and Stay button in Prestashop 1.6.0

The “Save and stay” button does not work in product detail in various subversions of Prestashop 1.6.0.9. This problems first appeared with Chrome some time ago. But the button was more or less operational in Firefox – until the March 2019 Firefox update.

There is a nice and easy to install module attempting to resolve the issue. Unfortunately this solution is not 100% reliable. Some customers were greatly satisfied with the module, some reported the problem as still unsolved, even when advised to clear the browser cache.

Thus, the only reliable solution is to upgrade the prestashop version. You may decide for the “big” upgrade to PS 1.7 or for the much easier upgrade to PS 1.6.1. Yes, that is righ, any subversion of PS 1.6.1.X is sufficient, but you will certainly use the last one. let us assume prestashop 1.6.1.24.

Can you keep your customized PS 1.6.0.x default theme when upgrading to latest PS 1.6.1.24 subversion? The answer is yes, with due precautions. These are issues we are aware:

  • Contact form – the contact form in in PS 1.6.1.24 get some extra hidden fields and will not work after upgrade. Get the PS 1.6.1.24 zip file, unpack and replace \themes\default-bootstrap\contact-form.tpl with the same file from the unpacked zip
  • Product page. Check product with combination and special prices. It it does not work properly (the prices do not change as expected), you need to replace both \themes\default-bootstrap\product.tpl and \ themes\default-bootstrap\js\product.js . Do not forget to clear the browser cache

Warning – upgrading Prestashop without upgrading the theme is always risky. On the other hand, I am aware of many shops undergoing such kind of speed upgrade without any several errors.

Invalid token: direct access to this link may lead …. (PS 1.7)

When navigating in the backoffice, the error Invalid token: direct access to this link may lead to a potential security breach pops up.

This problem has been widely discussed and there are several possible solutions:

  • change the php version (possibly to php 7.1 or higher)
  • upgrade all php packages
  • remove unused php packages
  • disable the session IP checking in prestashop backoffice

Recently a client encountered the invalid token problem on Prestashop 1.7.5 – in the products page only. Unfortunately, neither of the approaches mentioned above worked, even the complete upgrade of php libraries had no effect. This error seemed as a nightmare to debug, but luckily enough, I have noticed that the problem disseapears after turning the https off. Thus the cause is clean, at least in this case:

Cause: This server used nginx as reverse proxy to apache. The standard setting does not pass the $_SERVER[‘HTTPS’] variable to php. Prestashop 1.7 (comparing to previous versions) improved the https detection by adding $_SERVER[‘HTTP_X_FORWARDED_PROTO’] in Tools:: usingSecureMode . But this is apearently not sufficient.

Solution: Pass the $_SERVER[‘HTTPS’] into php. It can be done by modifiing nginx configuration, but I have opted for a less direct approach – prepending a file in php.ini. The content of the file is

<?php
if(isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'){
$_SERVER['HTTPS']='on';
$_SERVER['SERVER_PORT'] = 443;
}
if(isset($_SERVER['HTTP_X_REAL_IP'])) {
$_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP'];
}

the added bonus of this approach is fixing the remote address issue (Add my IP in the Maintenance section).

Summary

  • switch off the https protocol: set the Use SSL to No in the backoffice (Configuration / Main), if not possible, set PS_SSL_ENABLED to 0 in the ps_configuration database table)
  • check if the invalid token problem disappears
  • switch the https back
  • alternatively to the steps above, inspect the output of phpinfo() function. Open the page with phpinfo(); function over https protocol. Look for $_SERVER[‘HTTPS’] . If not present, this is your problem.
  • if https is really the culprit, edit the php.ini file and use the auto_prepend_file directive to prepend the file containing the code above and reload apache…. or on a shared hosting, ask your provider