François38

Bonjour à tous, Je suis le sujet depuis un moment mais j'interviens car je lis beaucoup de confusion concernant le DSP2. Comme l'a indiqué Yama, il est tout à fait normal qu'il n'y ait plus de 3D secure (le SMS), n'est plus censé exister dans le cadre de la DSP2. Le 3D secure v.1 (SMS) reste utilisé dans seulement 2 cas: 1- si votre module stripe n'est pas DSP2 (dans ce cas la transaction est envoyée en 3DS V1 à la banque). 2- la transaction est envoyées en DSP2 à la banque émettrice de la carte mais celle-ci n'est pas compatible DSP2 ou le client n'a pas encore l'application ou de smartphone biométrique. (dans ce cas c'est stripe qui est censé prendre la décision d'utiliser en secours l'ancien système). Concrètement, le DSP2 (3D Secure v.2) fonctionne ainsi : en plus des informations classiques (numéro de carte, nom du porteur, montant), on envoi désormais des infos personnelles sur le client (adresse de facturation, de livraison, téléphone, adresse ip, etc..) ces informations permettent à la banque émettrice d'évaluer le risque de la transaction et c'est désormais elle (et plus vous) qui détermine s'il faut une authentification forte ou non (le fameux sms, mais qui va être délaissé au profit d'une application, de mots de passe, et surtout de données biométriques) Concrètement, si les données personnelles correspondent à ce que la banque connais du client et de ses habitudes, la transaction sera faite "sans friction", aucune authentification forte n'est nécessaire, ou si le montant est faible, la transaction se fait directement sans sms ni rien d'autre). Si par contre les données ne correspondent pas (exemple le client fait livrer des fleurs chez sa belle mère, à une nouvelle adresse inconnue de la banque émettrice, ou d'une adresse ip différentes de celle utilisée habituellement), là la banque demande l'authentification forte. Pour les puristes, sachez que j'ai synthétisé mon explication, car il y a d'autres cas ou l'authentification forte sera demandée, et d'autres cas ou on peut encore basculer sur une authentification 3DS V.1, mais ce serait plus long à expliquer, il y a plein d'articles sur le net détaillant le principe de manière précise). Donc pour résumer, si tout fonctionne bien, il est normal que le paiement puisse se faire sans sms. C'est justement le but, de sécuriser encore plus le paiement (avec plus d'indicateurs et de données contrôlées) tout en fluidifiant le parcours client (pas de sms ou d'authentification forte si tout indique que c'est bien le porteur de la carte qui tente de faire l'achat). Malheureusement, et on reviens au sujet du topic, le module stripe de 202ecommerce ne fonctionne pas comme il faut. Puisque outre les doubles facturations (voir sujet en anglais ici => https://www.prestashop.com/forums/topic/1000346-stripe-official-sca-ready%09module-problems/), outre les paiements "incomplets" remontés inutilement (chaque fois qu'un client fait un panier sur votre site), le module ne remonte pas les infos nécessaires à la prise de décision par la banque. pour le DSP2. Le gros problème c'est que si on envoie à la banque, une transaction dites DSP2 avec des données incomplètes ou erronées, la banque refuse tout simplement le paiement (l'effet inverse de ce qu'on nous dit, à savoir que pour ne pas perdre de paiement il fallait etre compatible DSP2 au 14 septembre...) Au final sachez également que la France à obtenu il y a 3 semaine un report de la mise en application du DSP2 (de 12 à 24 mois selon les sujets). Il n'y a donc pas du tout urgence à changer votre module stripe !! Laissons le temps à stripe de trouver un autre partenaire plus performant que 202ecommerce, ou laissons le temps à 202ecommerce de sortir un module qui tiens la route. En attendant, n'installer surtout pas de version 2.x.x du module sur un site en production ! (sauf si vous êtes l'un de mes concurrents :-d)

Yes, I wanted to do the same thing, but I do not know how to do it. Sorry.

Yes, my mistake ! Use this function : public static function my_visibility_function($my_visibility_function) { if ($my_visibility_function == 'both') return '<span style="background-color : #0b9819; color : #ffffff; border-radius : 4px/4px"> všade </span>'; elseif ($my_visibility_function == 'catalog') return '<span style="background-color : #009adf; color : #ffffff; border-radius : 4px/4px"> katalóg </span>'; elseif ($my_visibility_function == 'search') return '<span style="background-color : #0020df; color : #ffffff; border-radius : 4px/4px"> vyhľadávanie </span>'; else return '<span style="background-color : #6c6c6c; color : #ffffff; border-radius : 4px/4px"> nikde </span>'; }

Ok, in fact, there was just one extra "," in my code, before a.`visibility` For translate, use this fields_list : $this->fields_list['my_visibility'] = array( 'title' => $this->l('Visibility'), 'align' => 'left', 'class' => 'fixed-width-xs', 'align' => center, 'havingFilter' => true, 'filter_key' => 'my_visibility', 'callback' => 'my_visibility_function' ); And add this function under the fields list : public static function my_visibility_function($my_visibility_function) { if ($visibility_state_lang == 'both') return '<span style="background-color : #0b9819; color : #ffffff; border-radius : 4px/4px"> všade </span>'; elseif ($visibility_state_lang == 'catalog') return '<span style="background-color : #009adf; color : #ffffff; border-radius : 4px/4px"> katalóg </span>'; elseif ($visibility_state_lang == 'search') return '<span style="background-color : #0020df; color : #ffffff; border-radius : 4px/4px"> vyhľadávanie </span>'; else return '<span style="background-color : #6c6c6c; color : #ffffff; border-radius : 4px/4px"> nikde </span>'; } You can update the traduction because it is google translate for Slovensko. The best would be to use the translation files but I could not use the variables. Regards,

HI MrGun, In AdminOrdersController.php Add this line on SQL select : $this->_select .= ', oi.`number` AS `invoice_number"; Add this line under the first, or under other line starting with $this->_join $this->_join .= ' LEFT JOIN `'._DB_PREFIX_.'order_invoice` oi ON (oi.`id_order` = a.`id_order`)'; And add this on fields list : $this->fields_list['invoice_number'] = array( 'title' => $this->l('Invoice Number'), 'align' => 'center', 'width' => 100, 'havingFilter' => true, 'filter_key' => 'invoice_number' );

Hi Kaper, In AdminProductsController.php Add this line on SQL select : $this->_select .= ', a.`visibility` as `visibility_state`'; And add this on Fields list : $this->fields_list['visibility_state'] = array( 'title' => $this->l('Visibility'), 'align' => 'left', 'class' => 'fixed-width-xs', 'align' => center, 'havingFilter' => true, 'filter_key' => 'visibility_state' );

La modification de invoice.tpl n'aura (au mieux) que résolu le problème sur les factures. Mais l'adresse de livraison doit également être celle du point relais, dans l'historique des commandes du compte client, sur les BL, et surtout dans l'email de confirmation de commande.. En effet, je pense que la seule possibilité cohérente est d'ajouter une nouvelle ligne dans la table ps_address Adresse associée au client, mais désactivée pour ne pas qu'il puisse s'en servir pour une prochaine commande sans passer par le module Mondial Relay. je pense qu'il faut ajouter un INSER TO dans MRManagement.php Pour que la ligne soit créée dans ps_adress, (en plus de ps_mr_selected). Reste à associer l'adresse nouvellement créée à la commande... A+

Bonjour, Merci Modock pour la requête ! Pour ceux qui sont en multiboutique comme moi, voici la requête permettant d'intégrer les transporteurs en masse pour toutes les boutiques. insert into product_carrier(id_product,id_carrier_reference,id_shop) select p.id_product,c.id_reference,s.id_shop from product p, shop s, carrier c where c.active=1 and c.deleted=0 Comme le faisait remarquer Franck Bugnet, lorsqu'un produit n'a aucun transporteur de sélectionné, prestashop condière pour celui-ci que tous les transporteurs sont disponibles. De ce fait la requête SQL ci-dessus n'a pas grand intérêt en l'état. Par contre, pour ma part je l'ai utilisée pour ajouter tous les transporteurs sauf un (Lettre Suivie) que je veux pouvoir sélectionner uniquement pour quelques produits au cas par cas. Il n'est également pas utile d'exclure les transporteurs inactifs, car étant justement inactifs, ils ne seront pas disponibles (mais au moins le jour où vous le réactivez, pas besoin de revenir toucher la base). Voici donc la requête : Je prends donc tous les transporteurs qui ne sont pas supprimés et qui ne s'appellent pas 'Lettre Suivie' (on peut aussi filtrer avec l'ID). insert into product_carrier(id_product,id_carrier_reference,id_shop) select p.id_product,c.id_reference,s.id_shop from product p, shop s, carrier c where c.deleted=0 and and c.name!='Lettre Suivie' A+

Merci pour ton retour

Parfait Bayside ! Et merci KevinNash pour ton retour. Cela prouve que parfois le .htaccess se met bien à jour tout seul comme un grand... Je ne sais pas si c'est lié à la version ou à autre chose, il faudrait que j'aille jeter un oeil sur la fonction concernée dans le code à l'occase. Je vous rejoins sur la rapidité affichée sur GTMetrix. Elle ne change pas vraiment (voir pas du tout) même si la note est tout de même améliorée. (en tout cas pour moi et Bayside). Par contre (toujours pour mon cas) on le ressent nettement sur l'affichage des pages. Je pense donc que ça n'améliore pas le temps de chargement serveur mais uniquement le temps que mets le navigateur à récupérer les contenu (en même temps le principe des serveurs de média muti-domaine sert justement à contourner la limite des navigateurs), le reste c'est plutôt la bande passante et la rapidité de traitement du serveur.

Oui en fait c'est surtout la solution que propose prestashop dans sa doc. - Le hic c'est que c'est pas hyper documenté. - Le second hic c'est que vu que c'est pas bien documenté, ça laisse place à plein de sujets ici ou là qui ne nous orientes pas vers la bonne manière de configurer les serveurs de média. - Le troisième hic, c'est que même si quelqu'un à compris et suivi la doc, il se retrouve avec un .htaccess qui n'a pas été mis à jour dans visiblement 100% des cas (il doit y avoir un bug là dessus), d'où l'astuce citée plus haut pour forcer la regénération. Quoi qu'il en soit, toujours effectuer ses configs sur une boutique de test. A+

Bayside, Pour commencer par la fin de ton post : Oui ce n'est pas une solution miracle. Soyons clair, un bon serveur vaut 100 fois mieux que ces petits réglages. Mais oui c'est un plus et ça se ressent clairement sur l'affichage dans le navigateur pour le visiteur. Et finalement, vu la faible complexité de mise en oeuvre de cette solution, autant ne pas s'en priver. Pour ton cas, la réponse est dans ton énoncé : Si tu as bien créé tes sous-domaine et qu'ils pointent bien vers le dossier de ton installation prestashop, tu ne peux pas mettre de .htaccess à tes sous-domaines ! (puisque leur htaccess est celui de ton dossier prestashop). Hors toi, visiblement tes sous domaines redirigent vers des dossiers sur ton ftp et non vers le dossier de ton install prestashop ! C'est pourquoi tu as été obligé de créer un .htaccess pour tes sous-domaines pour les rediriger vers ton domaine principal. Dans ton cas tu as monsite.com qui pointe vers le dossier www cdn1.monsite.com pointe vers le dossier cdn1 qui redirige ensuite (.htaccess) vers monsite.com qui lui même pointe vers www cdn2.monsite.com pointe vers le dossier cdn2 qui redirige ensuite (.htaccess) vers monsite.com qui lui même pointe vers www cdn3.monsite.com pointe vers le dossier cdn3 qui redirige ensuite (.htaccess) vers monsite.com qui lui même pointe vers www C'est bien et c'est pas bien : - Bien car vu que tu as un .htaccess propre à tes sous domaines, tu peux en profiter pour mettre tes 2 lignes pour le blocage des cookies. - Pas bien car tu créer plein de redirections pour chaque média chargé, et ça augmente le nombre de requête et annulé tout ou partie des gains de rapidité recherchés par la mise en place de cette solution. La redirection dilue aussi le poids de tes médias (je pense aux images) dans le référencement. C'est pour cela que tes sous-domaine doivent tout simplement pointer vers ton dosser d'install prestashop (www la plupart du temps). Pour configurer correctement tes sous-domaines sur OVH, tu vas sur l'onglet multisite de ton hébergement. Et tu peux changer le dossier racine de tes sous domaine (en veillant bien, je me répète, à les orienter vers le même dossier racine que ton install prestashop).

Bonjour à tous, Je me permets de poster un truc (même si le sujet est ancien). Ayant moi-même eu des difficultés à comprendre et surtout paramétrer mes "serveurs de media" pour mon site https://www.leds-boutique.fr ... J'ai lu les 8 pages de ce topic et également pleins d'autres sujets sur ce forum et ailleurs... Ca cafouille un peu et personne n'a donné une solution concrète lorsque les images ne s'affichent plus après avoir configuré les serveurs de média. Déjà il y a un abus de langage au sujet des CDN, beaucoup appellent cela CDN, mais un CDN ce n'est pas tout à fait ça. Le principe du CDN est de dupliquer les éléments statiques (les médias) sur d'autres serveurs à travers le monde afin de pouvoir avoir des serveurs avec son contenu au plus proche des internautes, quelque soit leur position géographique. OVH propose cela, inclus avec ces hébergements Performance (sauf que c'est tout le site qui est dupliqué, pas seulement les médias, mais peu importe ça fonctionne bien et c'est utile surtout si l'on vends à l'étranger, à fortiori sur d'autres continents). D'ailleurs en parlant d'OVH et pour faire un petit hors-sujet, là aussi on parle des offres performances comme des serveurs mutualisés classiques mais c'est plutôt une sorte de VPS infogéré car les hébergements performances sont gérés sur une infrastructure cloud et avec des ressources dédiées... comme les VPS... bref fin du hors-sujet. -- Alors oui, si on utilise un hébergeur indépendant pour ses médias (comme MaxCDN), on se rapproche de vrais CDN (c'est le cas pour mon exemple avec MaxCDN sui semble lui aussi dupliquer le contenu synchronisé sur d'autres serveurs à travers le monde. Il suffit alors de renseigner les url du, ou des serveurs dans l'onglet performance de prestashop. -- Mais la plupart d'entre vous utilise la méthode alternative aux CDN (proposée d'ailleurs dans la doc prestashop), qui consiste à créer des sous domaines redirigés vers son répertoire prestashop et à les renseigner dans l'onglet performance comme s'il s'agissait de vrais serveurs de média externes. Ca fonctionne et même plutôt très bien je trouve. Mais ce n'est pas du tout du CDN, c'est de la parallelisation de téléchargement. (alors oui, par principe un CDN fait aussi de la parallelisation de téléchargement, mais son intérêt est surtout la multiplication géographique des serveurs citée plus haut). Alors pour cette solution, j'ai lu tout et n'importe quoi... comme le dit la doc prestashop, les sous domaines ainsi créés doivent pointer vers le répertoire de son installation prestashop. Et non vers des dossier cdn1, cdn2 ou je ne sais pas quoi... Donc, lorsque vous crééz les sous domaines, il ne faut pas faire une redirection vers le domaine principal de votre boutique, ni vers un dossier qui contiendra un .htaccess pour rediriger la requête sur l'url principale (oui j'ai lu ça plus haut...). et ni copier le contenu des dossier css, images et js ou quoi que ce soit... (j'a lu ça aussi...). Les sous domaines doivent absolument pointer au même endroit que le domaine principale (dans mon cas le dossier www de mon hebergement, là ou est installé prestashop). Donc je résume : monsite.com pointe vers le dossier www sousdomaine1.monsite.com pointe vers le dossier www sousdomaine2.monsite.com pointe vers le dossier www sousdomaine3.monsite.com pointe vers le dossier www D'ailleurs vous donnez bien le nom que vous voulez à votre sous domaine, j'ai appelé les miens media1, media2, ... (de préférence éviter de les appeler CDN car on rentre comme je le disais plus haut dans l'abus de langage). Par ailleurs lorsque vous créez les sous domaines, si vous êtes en SSL sur votre prestashop, pensez à activer le SSL sur vos sous domaines pour éviter le contenu mixé. Ensuite bon, vous avez tous compris qu'il fallait renseigner ces 3 url dans prestashop. OK voilà c'est tout. Il n'y a rien à modifier dans le code, ni à ajouter manuellement quelque chose dans le .htaccess. Alors oui le truc c'est que le .htaccess est censé se mettre à jour tout seul afin de transférer le pouvoir intergalactique de la réécriture d'url aux serveurs de media, mais parfois (souvent ? ou toujours ?), ça ne fonctionne pas, les images n'apparaissent plus... Dans ce cas c'est que le .htaccess ne s'est tout simplement pas régénéré. -- Voici donc la solution pour le régénérer (puisque le bouton pour le regénérer a disparu sur les dernières versions de prestashop) : - Vous allez dans préférences => SEO & URLs et vous désactivez la réécriture d'url. Une fois fait et enregistré, vous la réactivez puis enregistrez de nouveau. (si vous n'utilisiez pas la réécriture d'url, faites l'opération inverse, activez puis désactivez). Et bimm ! le images réapparaissent. Petite information supplémentaire, pour ceux qui comme moi essayent d'améliorer leur note Yslow chez GTMetrix. Il est précisé qu'il faut que les sous-domaines des serveurs de media (qui peuvent également être des domaines d'ailleurs) doivent être "cookiesless", c'est à dire sans cookies. La solution avancées par beaucoup (et qui est juste) est d'utiliser un second domaine que celui de vote boutique (le même en .fr ou en .com ou avec une lettre de plus.... bref un autre). De ce fait le transfert de cookies ne se fait pas et donc on gagne des requêtes serveur donc du temps. Alors oui c'est vrai mais pas chez OVH (sauf dédié et VPS) qui balance un cookies sur toutes les requêtes serveur, même pour une image. il est donc impossible d'être "cookiesless", donc autant garder les sous-domaines de son domaine principal pour les serveurs de média. Voilà, j'ai fini mon romans.

J'allais poser la même question ! Le site est plutôt rapide ! Au final avez-vous été satisfait de page-cache ? Avez-vous fait autre chose pour améliorer vos performances ?

Bonjour, Ayant le même souci sur une version 1.6.1.4, je suis tombé sur ce sujet. Je tiens à remercier Johan Walter pour "l'astuce" qui fonctionne à merveille. En revanche (pour l'aspect philosophique du truc), pour moi on ne contourne pas le problème, je pense que c'est vraiment la solution prévue par prestashop pour répondre à ce besoin. Merci encore.