GuillaumeCW

Bonjour, La seule chose qu'apporte cette méthode, c'est de remplacer une requête avec file_get_content et l'URL http://ec.europa.eu/taxation_customs/vies/viesquer.do par une connexion Soap et l'URL http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl. La seconde méthode est celle préconisée par l'UE. Pour empêcher l'exemption de TVA d'un client dans le même pays que la boutique, il faut configurer le module (cf. pièce jointe). La traduction est pas terrible, mais cf. classes/pdf/HTMLTemplateInvoice::getTaxTabContent : //... $tax_exempt = Configuration::get('VATNUMBER_MANAGEMENT') && !empty($address->vat_number) && $address->id_country != Configuration::get('VATNUMBER_COUNTRY'); //... VATNUMBER_COUNTRY est le nom de la valeur configurée pour le "Pays du client", c'est à dire le pays de votre boutique.

Le bout de code en haut a une coquille car il commence mais ne va pas au bout de la validation du numéro mais seulement de celle du préfixe. Zappé de répliquer la modification ici car j'avais fais la modification en production. Donc merci de l'avoir fait remarquer. Je poste le code complet dans ce post et le référence depuis le premier car je dois apparemment être déjà trop vieux pour comprendre comment éditer son code... <?php class VatNumberOverride extends VatNumber { /** * Use overriden `WebServiceCheck` method. * * @see VatNumber::hookActionValidateCustomerAddressForm () */ public function hookActionValidateCustomerAddressForm(&$params): bool { if ($vatNumber = $params['form']->getField('vat_number')) { $errors = static::WebServiceCheck($vatNumber->getValue()); if (!empty($errors)) { $vatNumber->addError($errors[0]); return false; } } return true; } /** * Use SOAP service to validate VAT number. * * @see VaTNumber::WebServiceCheck() * @throw SoapFault */ public static function WebServiceCheck($vat_number): array { if (empty($vat_number)) { return []; } $vat_number = str_replace(' ', '', $vat_number); $vat = Tools::substr($vat_number, 2); $prefix = Tools::substr($vat_number, 0, 2); // Validate country prefix. if (!in_array($prefix, static::getPrefixIntracomVAT(), true)) { return [Tools::displayError('Invalid VAT number')]; } // Validate number in corresponding country database via VIES. try { $soap = new SoapClient('http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl'); $is_valid = $soap->checkVat(['countryCode' => $prefix, 'vatNumber' => $vat])->valid; } catch (SoapFault $e) { return [Tools::displayError('Error from validation service: '.$e->getMessage())]; } if (!$is_valid) { return [Tools::displayError('Invalid VAT number')]; } return []; } }

Ok, après avoir relu, j'ai compris le malentendu dans votre esprit car vous dites que la chaîne qui est rentrée côté e-commerce est composée du préfixe, mais sur le site de validation de l'UE, on rentre une chaîne sans préfixe. C'est ça ? Si oui : si vous regardez le bout de code partagé, la chaîne entrée par le client est découpée de son préfixe et l'API de VIES reçoit les informations comme elle l'attend. C'est cette API qui fait sa validation pas nous. Vous avez bien un numéro de TVA validé et l'autre non. Si non : je ne sais vraiment pas donc encore une fois, bon courage.

Et je dois rajouter <php aussi ? Je pense que l'extrait est suffisant pour aider tous ceux qui le méritent. J'ai plusieurs sites en 1.6.1.20 où 45839048503 est refusé mais ES45839048503 est accepté. Supprimer votre fichier cache/class_index.php... je ne sais pas. Comment je peux savoir ce que vous faîtes de vos copier/coller ?

Bonjour, Le code est toujours fonctionnel de mon côté. J'espère que vous trouverez la solution. Courage.

Bonjour, Je vous aide volontiers : "utilisée" doit être à l'infinitif "peu" prend un "t" à la 3ème personne du singulier ce qui est variable est dynamique par définition; sinon c'est une constante pour en savoir plus sur les variables Smarty accessibles en front : http://doc.prestashop.com/display/PS16/Displaying+content+on+the+front+office postez votre question dans la section au dessus : ici, c'est pour discuter de potentiels bugs

Vous avez une trace de notice PHP en attribut "value" de votre champ de recherche de produits. Mais c'est plutôt étrange qu'une valeur soit renseignée côté serveur pour cet attribut. EDIT : je n'avais pas vu le debug Prestashop en bas de page. Les temps de requêtes sont normaux, donc il y a probablement un fichier PHP exécutant une longue instruction et gênant le chargement. Suivez l'ordre d'inclusion des fichiers en ajoutant un bon gros die('stop') pour identifier où ça coince.

Ci-dessous une capture d'écran prise il y a 30 secondes des entêtes relevés par Chrome dans la réponse à une requête de l'URL que vous essayez de servir en https. On voit la redirection 302 fournie par Nginx.

Bonjour, Je regarderai du côte de la configuration de Nginx à votre place car c'est lui qui est à l'origine de la redirection du second sous-domaine, et non Apache via le .htaccess généré par Prestashop en sauvegardant votre configuration.

Bonjour, Ça m'étonnerait que ce genre de modules existe sur Prestashop malheureusement, car votre projet requiert pas mal de fonctionnalités qui je pense ne font pas partie des besoins courants d'un e-commerce classique. Vous postez votre question dans une section dédiée aux rapports de bugs, mais au vu des contraintes auxquelles je peux penser pour votre projet, le plus court chemin serait probablement un développement complet avec un framework PHP comme Symfony, Laravel, Zend... qui intègrent des "bundle" de gestion d'utilisateurs, de moyens de paiement, etc... Si votre niveau en développement ne vous permet pas d'utiliser ces outils, Wordpress pourrait être une bonne piste mais dans tous les cas, il faudra mettre la main à la patte. EDIT: à la réflexion, l'apprentissage de Prestashop pourra être moins difficile que celui d'un framework, et par rapport à Wordpress, Prestashop a déjà un certain nombres de fonctionnalités requises qui sont disponibles. Donc un développement sur Prestashop est probablement une bonne solution.

Bonjour, Votre capture d'écran montre bien 3 x 2 x 9 x 4 combinaisons d'attributs possibles, soit 216 déclinaisons. Les erreurs de DevTools sont explicites : les boutons pour revenir au produit ont tous le même ID, ce qui n'est pas valide dans un document HTML, même si ça n'a aucune conséquence ici. Je vous conseille d'éviter les valeurs d'attributs "JE CHOISIS MON ATTRIBUT". Les attributs ont vite fait de gonfler une base de données Prestashop. Les attributs font partie des 2-3 fonctionnalités que Prestashop permet de désactiver pour optimiser les performances de chargement.

Sa version 1.7 vous sera plus utile : https://github.com/PrestaShop/ps_languageselector

Salut, Ne le prenez pas mal svp, mais vous avez posté votre sujet dans une section de report de bugs, et mon opinion personnelle serait de déconseiller votre solution. Prenez exemple sur le fichier le module officiel blocklanguages. 95% de la solution à votre besoin est dans ce module. Au lieu de l'accrocher à displayNav, accrochez votre template à displayHeader.

Bonjour, Mais c'est quoi pour vous GeoIP ? Géolocaliser les IPs n'est pas incompatible avec le SEO. Bloquer les IPs, dont celle des robots des moteurs de recherche, en fonction de leur localisation, oui.

Bonjour, Il suffirait je pense de découper la génération de vos déclinaisons en plusieurs lots, sinon de découper votre produit en plusieurs produits. OVH a à moitié raison : si vous n'avez personne pour configurer le CGI timeout du service HTTP, un serveur dédié ne changera pas grand chose.