@mediacom87 a dit dans Des modules et des hacks - liste non exhaustive des modules présentant un risque :
@eolia de mémoire, la faille est corrigé sur les dernières versions du module depuis des années.
Le problème n'est pas de savoir s'il y a une correction mais s'il est présent sur l'hébergement dans une version avec faille justement ;)
2 de plus: vm_advancedconfigurator et jscomposer
Comme ces 2 là font toujours la paire, la même ligne est à ajouter dans SupplierController.php ;)
public function canonicalRedirection($canonicalURL = '')
{
if (Tools::getValue('live_edit')) {
return;
}
if (!Validate::isLoadedObject($this->supplierr) && (int)Tools::getValue('id_supplier')) {
$this->supplier = new Supplier((int)Tools::getValue('id_supplier'), $this->context->language->id);
}
if (Validate::isLoadedObject($this->supplier)) {
parent::canonicalRedirection($this->context->link->getSupplierLink($this->supplier));
}
parent::canonicalRedirection($canonicalURL);
}
Pensez également à contrôler la valeur de max_input_vars (par défaut à 1000 si non configurée sur le serveur) dans le cas d'un nombre important de zones / tranches de poids / prix
Cette variable correspond au nombre maximum de champs acceptés par le serveur lors de la soumission d'un POST.
Mettez-là à 10 000 et vous serez tranquilles également pour les traductions ;)
header('Location: '. Tools::getShopProtocol() . $url);
:smirk:
Si votre boutique est en https et que la génération des pdf crashe car le tpl utilise $img_ps_dir modifier la ligne 141 de /classes/pdf/HTMLTemplate.php en remplaçant:
'img_ps_dir' => 'http://'.Tools::getMediaServer(_PS_IMG_)._PS_IMG_,
Par
'img_ps_dir' => Tools::getShopProtocol().Tools::getMediaServer(_PS_IMG_)._PS_IMG_,
idem dans /classes/pdf/HTMLTemplateSupplyOrderForm.php à la ligne 175.
Merci @doekia qui m'a enlevé une belle épine du pied :slight_smile:
Même réponse que sur l'autre forum: Supprimez ce module de votre ftp
On est bien d'accord, j'ai la même chose^^
Donc tu remplaces le bloc else avec le code que je t'ai fourni plus haut...
{ else c'est impossible en php...
Un conseil, gardez quand même le thème par défaut dans le répertoire /themes car Prestashop l'utilise s'il ne trouve pas les trads ou mails dans le thème en cours...
Vous pouvez avoir les doutes que vous voulez mais le message est on ne peut plus clair:
Link to database cannot be established:SQLSTATE[HY000] [2002]
Le lien avec la base de données n'a pu être établi.
Avec la 1.6, chez OVH on peut avoir aussi le message "504 bad gateway" ou "Mysql has gone away" qui reflètent bien la qualité du service dès qu'on sollicite un peu la base.
La différence du core est minime entre la 1.5 et la 1.6, la seule chose qui pourrait changer seraient un thème ou des modules plus gourmands en ressources.
Un mutu c'est bien pour tester ou découvrir, mais dès qu'on a besoin de répondant ou que le trafic et le catalogue augmente il faut passer à plus sérieux.
Concernant les hébergeurs je préfère ne rien dire... votre offre "Premium" est un pauvre vps (donc un mutu déguisé par abstraction logicielle).
Dédié ou semi-dédié, je n'en démords pas. Au moins vous êtes maître de votre machine et vous ne risquez pas de subir les conséquences d'un environnement surchargé ou défaillant.
OVH vous raconte des salades.
Même si c'est bien de nettoyer vos tables, le problème ne vient pas de chez vous mais de leur réseau interne qui sature à certaines heures en mutualisé.
Il faut savoir que même les base dites "Pro" chez eux sont aussi en mutualisé. Elles ont juste plus de place^^
Donc pour éviter ce genre de souci passez sur un semi-dédié ou un dédié, surtout si cette boutique est votre gagne pain.
Moi je vois une 200 mais en page blanche: https://www.my-dressing.eu/index.php?fc=module&module=lydia&controller=validation
@frede98 Dans le module ou à la banque ?
Une commande payée qui ne se finalise pas c'est que le retour de la banque a échoué.
Il faut:
C'est surement un souci d'url retour qui n'est pas bon ou redirigé
@rp-lemaire Quand vous le testez depuis le navigateur, quel est la réponse ? Page blanche ?
Oui avec une requête ajax contenant les prix du panier.
Si prix modifié, une bulle d'info apparaît
Je pense que le souci de la langue n'est pas l'origine du problème.
Lorsque vous désactivez le mode debug, allez sur la page produit et regardez l' error.log de votre serveur.
Le mode debug de Prestashop passe outre certaines erreurs dons pas toujours évident de déterminer la source du pb...
Bah là, c'est votre serveur sql qui a planté et comme le mode debug est activé vous voyez l'erreur...
Pour vos traductions, tentez de traduire les manquantes depuis l'onglet des traductions mais ce n'est pas ce qui pose le plus gros problème de l'affichage de vos pages produits.
Je pense qu'il a un souci dans la base de données (soit l'id_lang n'est pas bon ou manquant pour les produits)
Mais je me répète, vu qu'on ne soutient pas cette version 1.7 moisie et bancale, il va être difficile de vous aider plus :(