Cela peut être du à beaucoup de facteurs indépendant de notre module, dans le doute, la première chose à faire est de greffer le module sur le hook Header. Dans la configuration du module, cliquez en haut à droite sur l’icone « Greffer » puis ajouter et enfin précisez le module et le greffon Header. Le module fonctionne normalement sur le hook actionDispatcher mais cela est parfois incompatibles avec certains modules de redirection URL.
Si votre boutique possède beaucoup d’override customisés, cela peut aussi avoir un impact conséquent.
Une autre solution consiste a créer un Override dans la classe FrontController (override/classes/controller/FrontController.php) avec le code suivante, c’est néanmoins une méthode peu recommandée :
A noter que Pretty URL pose très souvent des problèmes et nous n’y pouvons pas grand chose. La manière dont à été faite ce module est tout bonnement incompréhensible en 2020 et dévie totalement le fonctionnement de Prestashop comme il devrait être. Si vous possédez ce module et que vous vous en servez avec le notre, nous ferons en sorte de vous aider mais ne vous attendez pas à des miracles.
Loin de nous l’idée de faire de la vente forcée mais force est de constater que notre module de réécriture d’URL lui fonctionne avec celui-ci, comme les autres modules de redirections.
Le module a pour but de rediriger toutes les pages « mortes » (404) par lui même sans que vous ayez à intervenir.
Sa première option permet de récupérer les URLs des pages introuvable et applique une redirection si des termes sont similaires en base de donnée, sinon il ajoute une entrée
Cela permet de corriger les URL mal tapées ou légèrement fausse pour 99% d’entre elles et assurer à votre SEO de rester correct malgré des erreurs dans des liens externe par exemple.
Le module gère également la redirection des pages désactivées ou supprimées en les renvoyant vers leur parent logique, par exemple un produit supprimé verra son URL renvoyée vers
Le dernier algorithme de redirection vers les dossiers parents permet de récupérer les derniers éléments potentiellement hors champ des deux premiers types. Il prendra par exemple /dossier/sousdossier pour renvoyer vers /dossier. Si dossier n’existe pas non plus il enverra vers /. Cela permet également de récupérer une grande partie des anciennes pages 404 encore indéxées qui découlent de pages supprimées sans avoir à le gérer une par une.
Dans le cas d’une migration vous pouvez également utiliser le mode Regex, bien que celui-ci soit très gourmant et réservé aux développeurs. Il permet d’utiliser la fonction php preg_match de la manière suivante :
preg_match(‘/’.$rule.’/i’, $url)
Les / sont échappés par le programme, vous n’avez pas à le faire.
Le plus simple reste de nous contacter, on le fera gratuitement si il s’agit d’un module avec un public large, si c’est pour une implémentation personnalisée, cela nous prend généralement une heure, soit 60€HT en 2020.
Le module gère la production du robots.txt et y ajoute la ligne qui permet aux moteurs de recherche de trouver le sitemap facilement, quelque soit la boutique.
Cela a été fait car le multishop peut donner des adresses de sitemap différentes et l’adresse indiquée dans le robots.txt doit être entier (absolu) et non relatif.
Votre temps de réservation produits est trop court ! Il doit être minimum de 25 minutes pour assurer que les clients arrivant sur la page de paiement ait tout le temps nécessaire pour payer.
À ce niveau, le temps imparti est remis à 0 sur le checkout pour éviter tout problème. Il reste le cas sur lequel un utilisateur prend beaucoup de temps à payer sur une plateforme externe type PayPal, chose sur laquelle nous n’avons pas encore trouvé de solution pour le moment bien que le problème soit extrêmement rare. Nous insistons sur le fait qu’il est dangereux de mettre moins de 25 minutes pour la réservation des produits.
Les produits sont comptés dans une table de base de donnée séparée de celle de Prestashop. En cas de dépassement du temps imparti ils peuvent être enlevé du panier des utilisateurs.
Seul les utilisateurs ayant le produit dans leur panier pourront le commander.
Ce module est très exigeant et propose quasiment du temps réel pour chaque client. Des options dans le module permettent d’atténuer ce fait. Celle consistant à désactiver les chronomètres dans les listes est de loin la plus efficace.
Oui mais cela demande une implémentation que nous n’avons pas pu automatiser car Prestashop ne le permettait pas. Un guide est disponible avec la ligne à ajouter pour le faire dans le back-office du module.
Ils sont très léger, quelques centimes après les 100000 premières demandes en 2020. Les prix sont disponibles ici : https://developers.google.com/places/web-service/usage-and-billing
Cela peut être du a plusieurs choses :
– La clé API n’est pas bien renseignée.
– La clé est limitée à la mauvaise adresse, nous recommandons de mettre domain.tld/* ce qui permet d’être certains de quasiment tout prendre en charge.
– Vous n’avez pas activé les bonnes API. Il faut que l’API Places soit activé sinon cela ne fonctionnera pas. Nous demandons aussi de mettre en place Maps dans sa globalité et Maps Javascript également.
– Vous devez avoir renseigné votre carte de paiement.
Pour débugger cette partie, nous ouvrons la console développeur Chrome (Voir ici) et dans l’onglet Console apparaît très souvent une inscription en rouge de Google Maps vous précisant l’erreur.
