This can be due to many factors independent of our module, in doubt, the first thing to do is to graft the module on the hook Header. In the module configuration, click on the “Add” icon in the top right corner, then add and finally specify the module and the Header hook. The module normally works on the actionDispatcher hook but this is sometimes incompatible with some URL redirection modules.
If your shop has a lot of custom overrides, this can also have a big impact.
Another solution is to create an override in the FrontController class (override/classes/controller/FrontController.php) with the following code, it is however not very recommended:
Note that Pretty URLs very often cause problems and there is little we can do about it. The way this module has been made is simply incomprehensible in 2020 and totally deviates from the way Prestashop should work. If you own this module and use it with ours, we will try to help you but don’t expect miracles.
Far be it from us to make forced sales, but it is clear that our URL rewriting module works with this one, just like the other redirection modules.
The purpose of the module is to redirect all “dead” pages (404) by itself without your intervention.
Its first option allows you to retrieve URLs of pages not found and applies a redirection if terms are similar in the database, otherwise it adds an entry
This allows you to correct mistyped or slightly wrong URLs for 99% of them and ensure that your SEO remains correct despite errors in external links for example.
The module also manages the redirection of deactivated or deleted pages by sending them back to their logical parent, for example a deleted product will have its URL sent back to
The last redirection algorithm to the parent folders allows to retrieve the last potentially out-of-field items of the first two types. It will take for example /folder/subfolder to redirect to /folder. If folder doesn’t exist either it will send to /. This also allows you to recover a large part of the old 404 pages that are still unindexed from deleted pages without having to manage them one by one.
In the case of a migration you can also use the Regex mode, although this one is very greedy and reserved to developers. It allows you to use the php preg_match function in the following way:
preg_match(‘/’.$rule.’/i’, $url)
The / are escaped by the program, you don’t have to.
The easiest thing to do is to contact us, we will do it for free if it’s a module with a large audience, if it’s for a custom implementation, it usually takes us one hour, or 60 € without VAT in 2020.
The module manages the production of robots.txt and adds the line that allows search engines to find the sitemap easily, whatever the shop.
This has been done because the multishop can give different sitemap addresses and the address given in the robots.txt must be absolute and not relative.
Your product reservation time is too short! It should be a minimum of 25 minutes to ensure that customers arriving on the payment page have enough time to pay.
At this level, the time is reset to 0 on checkout to avoid any problems. There remains the case where a user takes a long time to pay on an external platform such as PayPal, which we have not yet found a solution for the moment although the problem is extremely rare. We insist on the fact that it is dangerous to use less than 25 minutes.
Products are counted in a separate database table from Prestashop. If the time limit is exceeded, they can be removed from the user basket.
Only users who have the product in their cart will be able to order them.
This module is very demanding and offers almost real time for each customer. There are options in the module to mitigate this. The option to disable stopwatches in the lists is by far the most efficient.
Yes, but this requires an implementation that we could not automate because Prestashop did not allow it. A guide is available with the line to add to do it in the module back office.
They are very light, a few cents after the first 100,000 uses in 2020. Prices are available here: https://developers.google.com/places/web-service/usage-and-billing
It can be due to several things:
– The API key is not the good one or misspelled.
– The key is limited to the wrong domain, we recommend to put domain.tld/* or *domain.tld* which makes sure to support almost everything.
– You have not enabled the correct APIs. The Places API must be enabled otherwise it won’t work. We also ask to set up Maps as a whole and Maps Javascript as well.
– You must have entered your payment card information.
To debug this part, we open the Chrome developer console (See here) and in the Console tab very often appears a red inscription from Google Maps telling you the error.
