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.
The easiest way is to start at https://cloud.google.com/maps-platform and then create the key here https://console.cloud.google.com/google/maps-apis/credentials.
Fill in “HTTP Referrer” and put your domain like this *.domain.com/*
Normally, yes! Afterwards, some people don’t meet Prestashop’s standards, but it’s rare. The best-selling modules are supported. It’s been several years since we have had a new request for adaptation.
Yes, on the address creation and order pages. This will not work on module pages without our intervention however.
Google used to allow it before but removed this feature. It is supposed to come back by 2021 and we will implement it when the time comes.
You can submit a correction to Google on this subject: https://support.google.com/maps/answer/3094088
The module can’t do anything about it, much to our regret.
Recommendations are made with the same results as Google Maps. It works everywhere on earth, even in Greenland.
They are supported by the service you don’t have to configure anything. If a price is offered it means that the service can deliver in the area.
Prices are transmitted by the service in real time. You can manipulate this price through the settings and even define a basket price from which delivery is free of charge. The Prestashop options in the carrier tab are not used to define them.
We set up this system of questions-answers based on the requests we receive precisely because to make evolve the documentation attached with the plugin is binding. This allows us to react more efficiently. However, we will be happy to answer you and then complete it.
Let’s talk about it! We’re always receptive to good ideas.
Yes, but not in the context of support, which only concerns the monitoring of the implementation and correction of bugs. If it is a micro adjustment we will of course help you, however if the work is more consequent we will propose you an estimate. Our hourly rate is 60 € without VAT per hour.
Not for the moment on Prestashop, we are thinking about integrating Prestashop’s warehouse management, this has not been asked for yet. You can still use different pickup point in MultiShop.
For WooCoomerce, this is possible with the Local Pickup Plus plugin available here : https://woocommerce.com/products/local-pickup-plus/
The support concerns only the available pickup points and the associated stocks, the proposed schedules respect those of our plugin however.
Yes, all our modules are multi-language and multi-shop compatible. Configurations may change for each shop.
For Stuart and Deliver.ee, you can also define a pickup point per eShop.
About Magic Redirect 301, you can define which redirections will be used by which eshop. Note that this is automatically done by the system when creating the rules, you will not have to manage the distribution of the rules yourself.
Regarding URL Rewriter (SEO, it supports each of the different eshops separately to avoid creating duplicates.
Lonelystock (Product Isolation) separates each product in the shops but the stocks being managed in a common way in Prestashop, times and quantities are managed together. We simply followed the usual Prestashop behaviour with regard to stocks.
Simple Sitemap is natively made to manage all the complexities of multi shop and multi language, even at the level of other plugins (blogs …) when it is possible of course.
There are three modes, one allows to manage the preparation time at the time of the order, a second allows to apply this to each store opening to avoid night orders impossible to respect. The last one applies the second mode only for D+1.
This module allows you to automate the management of the orders to the service. It manages the order taking and its complete follow-up. Once set up you don’t have to do anything special, everything will be managed and transmitted to the service (packages, schedules, locations…) then synchronized with Prestashop/WooCommerce.
The plugin first looks at which days are available and at which hours, then reduces the proposed hours according to the different rules given in the configuration (breaks, preparation time, management on D+0/1). The mode of preparation time is also important because it will affect differently for each day.
The plugin also applies a small default time margin to avoid problems of premature orders.
The manual mode allows you to retrieve the delivery options and the associated price without automatically launching the order on the service side. The service will not launch the delivery so you will have to validate it yourself.
This information is pre-filled in the back office of the order so that you can launch the order easily.
This may have several reasons:
– There is no price or delivery date available for this address.
– The service does not deliver to this address.
– The carrier associated with the module (see advanced tab) is not the right one. You just have to change it.
– The user display (“hook”) is not hung in the right place. This is quite rare on Prestashop, much less on WooCommerce where an option allows you to change it. This is very useful if you have a checkout plugin like WooFunnel.
– Your module is not connected to the service because your login is not the right one. This is normally indicated.
– You didn’t fill a payment card or your account is blocked. This is very rare.
The schedules are broken down by days, you can define daily schedules with breaks. Services start at 9 AM and end at 11 PM in general, although this varies from city to city.
You can also define adjustable preparation times according to the days.
Finally, an advanced mode allows you to stop/start offering same day orders from a certain time. This allows for example to avoid orders too early in the morning or at night that are impossible for you to manage.
You have to indicate the times following the 24:59 format, for example for 9h01 : 09:01
Ha this is unfortunate but certainly not insolvent. Could you clarify and describe a little bit what’s not working? Don’t hesitate to send us your back-office login and FTP (or SSH!) connection so that we can work more efficiently! Don’t hesitate to send us screenshots as well.
We generally answer within 24H working days, 48H during school holidays.
To contact us, please send us a message from the platform on which you purchased the product, so that we can easily centralize the requests and answer you as soon as possible.