ChDUP

C'est sensible à la casse. Il faut name="SubmitLogin" avec S majuscule, exactement comme celui du button.

non, avec un input submit, ça passe

n'importe comme ça , c'est bien <p class="submit"> {if isset($back)} <input type="hidden" class="hidden" name="back" value="{$back|escape:'html':'UTF-8'}" /> {/if} <input type=“hidden” name=“submitLogin” value=“1”> <button type="submit" id="SubmitLogin" name="SubmitLogin" class="button btn btn-default button-medium"> <span> <i class="icon-lock left"></i> {l s='Sign in'} </span>

non comme dit plus haut, vous ajoutez <input type=“hidden” name=“submitLogin” value=“1”> Le value="1" n'est d'ailleurs pas nécessaire mais autant le mettre.

au dessus du button de la création de compte , vous ajoutez un <input type="hidden" name="submitAccount"/> et au dessus de celui la connexion : <input type="hidden" name="submitLogin"/>

Le problème semble du aux names des button submit qui ne sont plus envoyés en POST. passer le submitLogin dans un input hidden "règle" le souci. Mais ça n'explique pas d'où ça vient.

deterrage de 6 ans ... content de voir que ça a été pris en compte

I was trying with last php 7-fpm image I tried with Prestashop docker image but never succeeded (I don't remember the errors). But now it's ok with my method, with docker , Nginx, Traefik, like I wanted Thanks

Hi ! I try to install Prestashop 1.7.6.2 on my docker configuration. And I've always same error during the installation at the "Install theme" step. 1: HTTP 500 - error - I've also try with 1.7.6.0 and same error. Thanks for your help !

Il faut arrêter de confondre ce qui vous (et moi aussi) semble logique et les textes de loi, ce sont 2 choses totalement différentes. Paypal n'est pas un "établissement de crédit régi par les dispositions du titre Ier du livre V du code monétaire et financier". Selon les dires même de Payplug : Et eux ont des services juridiques qui épluchent ça de près. Si leur service permettait d'être exonéré de cette loi, ils seraient les premiers à le crier et à l'afficher partout, puisque ce serait un argument de vente énorme. Donc à partir du moment où une boutique utilise un moyen de paiement qui n'est pas un établissement de crédit, elle est sujette à la loi NF525. C'est à dire tout ce qui n'est pas réglement direct par CB ou virement bancaire.

@Eolia Quel rapport entre la divulgation d'informations à des tiers et la loi anti-fraude ?

fabbea vient de vous expliquer le contraire pour PayPlug et PayPal. Ce qui est donc vrai pour la plupart des solutions de paiement. En réalité, la quasi totalité des boutiques Prestashop ne sont pas conformes à la legislation, à ce jour.

Ce n'est pas parce que ça n'a pas fonctionné pour vous que c'est obligatoirement une arnaque ! Si les résultats sont mauvais, cela peut venir d'une multitude de choses : mauvais contenu, mauvais paramétrages, ou tout simplement le secteur d'activité qui n'est pas réactif à ce support ... C'etait mon cas dans mon ancienne activité, et j'ai stoppé Facebook Ads, mais je n'ai jamais considéré cela comme une arnaque.

je deterre au cas où quelqu'un fasse la même recherche. Le module chronofood est dispo ici https://www.chronopost.fr/fr/plateformes-e-commerce

Externaliser la facturation via kiwiz ou evoliz (je suis preneur d'autres noms ?) peut être une solution, ils sont certifiés. Mais rien n'empeche de modifier les données avant de leur envoyer, c'est là où je ne comprend pas si on est tout de même dans les clous.