liandri

Il est difficile de donner une critique au travail des développeurs collaborateurs / partenaires, surtout si les modules sont gracieusement offerts à la communauté. Les développeurs se démènent à créer des modules, et il est intéressant de voir des contributions gratuites. Mon point de vue la dessus ne s'arrête pas à un module en particulier, mais aux modules en général. C'est pas parce que le module est proposé gratuitement qu'il n'est pas fiable à la base. Je souligne "à la base", car le fait d'exposer gratuitement le code du module aux yeux de tous, les conséquences prennent 2 situations : Une situation positive car évolutive : En effet le module est rendu disponible pour tout le monde, et est susceptible de toucher beaucoup de personnes dans le besoin, et même d'autres développeurs. Ceci génère plus facilement des rapports de bugs et favorise les corrections à apporter. Le module donc est plus facilement évolutif, car la masse d'utilisateurs est plus grande et plus pertinente. Une situation négative car risque plus grand : Si l'auteur du module n'assure pas un suivi de développement du module et laisse ce dernier dans sa version initiale, alors le module devient dangereux. Surtout si sa fonction première traite des données essentielles (base de données, accès, traitements serveur, ressources serveur, etc.). Cette analyse ne se restreint pas à PrestaShop et ses modules, mais à tous les développements de type CMS open-sources. Donc en conclusion, regarde bien le module en lui même si il est suivi réellement, malgré sa gratuité. Et c'est peut-être aussi pour ça que certain module sont plus onéreux que d'autres. Car il y a le coût du développement, le coût de l'assistance en cas de problème, mais aussi le coût du suivi du produit. A+

Bonjour, Pour le principe du paiement par carte bancaire, à moins que vous soyez une banque et que vous contrôlez vous même la transaction bancaire, je ne vois pas l'intérêt de passer en SSL. Sauf si vous souhaitez que la phase avant le paiement réel en ssl depuis le traitement de banque soit aussi sécurisée, mais sécuriser un montant ou une référence commande propre à votre système (n'engageant rien de la part du client) est un peu paranoïaque. En fait le mécanisme de paiement par carte bancaire est simple : - un client constitue son panier => inutile de sécuriser en SSL, sauf si c'est dans votre cahier des charges - le client valide son panier et passe sa commande => inutile de sécuriser en SSL, sauf si c'est dans votre cahier des charges, et que vous souhaitez sécuriser les informations qui transitent entre chaque POST de formulaires. Je pense entre autre à la création d'un compte nominatif avec ses informations postales, etc. - le client choisie son mode de paiement => inutile de sécuriser en SSL, sauf si c'est dans votre cahier des charges - si le système de paiement CB est bien conçu, le traitement redirige automatiquement le client vers un formulaire de paiement en ligne DEJA sécurisé SSL par la banque. Avant la saisie des informations importantes, le transition de la boutique vers le formulaire de paiement a posté en parallèle les informations sur le paiement (surtout la référence de votre commande, et des informations obligatoires à renseigner à la banque). - à ce stade et avant même que le client rentre quoi que se soit comme information, le formulaire de paiement est bel et bien déjà sécurisé par la banque, donc tout ce que se passera pendant le paiement, c'est la banque qui maitrise totalement ce traitement, pour ensuite vous renvoyer de façon transparente, les éventuelles codes de retour sur l'état de ce paiement. En conclusion, si votre souhait est de mettre en place un système de paiement sécurisé sur votre boutique web, alors vous n'avez pas d'intérêt à acquérir un certificat SSL, puisque c'est la banque qui gèrent déjà cette sécurisation. En revanche si vous êtes paranoïaque, et que vous souhaitez quand même sécurisé les navigations dans votre boutique (ce qui semble inutile à mon sens), alors acheté votre certificat SSL. Bien cordialement A+

Bonjour, Et la gestion de pack ? C'est le même effet ! Ajout d'un produit de type pack avec intégration d'un produit * la quantité que tu souhaites. A+

Bonjour, Il serai plus judicieux de modifier le css de ton theme. A+

Bonjour, Tu soulèves la tout simplement le problème d'utilisation privé dans des lieux publics. Pas de solution si ce n'est que de désactiver les cookies sur le navigateur du poste en question. (voir une configuration par site / domaine) A+

Avant même de traiter la quantité, je te donne juste une donnée supplémentaire qui pour le coup répond à ta question : La structure de la table _product gère les quantités sous forme d'entier ( quantity => int(10) ) Tu auras donc beau modifier quoi que se soit dans le code, il faut au préalable gérer le décimal dans la structure. De plus, j'ai peur que ça ai de fâcheuses incidences sur tous les autres calculs. A+

Bonjour, Essai de revoir toute la séquence de traitement des taxes en fonction des zones / devises dans l'onglet paiement. A+

Bonjour, Pour savoir ce genre d'information, il faut une interaction à intervalles réguliers entre le navigateur et le serveur. Seul le principe asynchrone pourrai résoudre ta demande. Ajax, ou Jquery/ajax, pas mal de possibilité pour faire cette méthode. A+

Oui, aussi ... Divine a raison C'est même plus judicieux que ma méthode brutale pour le coup !

Bonjour, Je ne pense pas que cette modification soit fonctionnelle, car le couple 1-1 par exemple est un code déterminant pour l'appartenance à un produit. Ce couple est récupérer pour faire la liaison dans les traitements associés aux gestions d'images. A+

Bonjour, Pour les catégories : Une petite modification dans ton fichier /modules/blockcategories/blockcategories.tpl Ajoute en tout début du fichier : {if $smarty.server.SCRIPT_NAME != '/index.php'} Ajoute à la fin du fichier {/if} Pour les nouveautés : Une petite modification dans ton fichier /modules/blocknewproducts/blocknewproducts.tpl Ajoute en tout début du fichier : {if $smarty.server.SCRIPT_NAME == '/index.php'} Ajoute à la fin du fichier {/if} J'ai pas testé, je te laisse faire ! A+

Dans la mesure ou la transaction commerciale de n'importe quel produit ou quelle prestation correspond à une vente, une location ou une réservation, entre un client et un vendeur, et que le vendeur est bien le gestionnaire du système, alors PrestaShop est fait pour vous.

Bonjour, Je ne pense pas car le principe même de la solution PrestaShop est la vente de produits ou services soit en b2c, soit en b2b. Un système d'annonce ne provoque pas un acte d'achat lié à la boutique en elle même, mais met en relation le vendeur du bien ou du service pour effectuer la transaction commerciale qui pour une grosse partie (sauf commissions) n'est plus du ressort de la boutique. La seule éventuelle compatibilité serai que la boutique prenne en charge intégralement la vente, et rétribue ensuite le réel vendeur de ce qui lui est dû moins une commission. C'est exactement le fonctionnement de PrestaStore par ailleurs. Sinon, je pense qu'il faut t'orienter plus vers des CMS de type catalogue d'annonces.

Entièrement d'accord avec toi. Il faut faire attention à ne pas contrer le fonctionnement principal de PrestaStore. Lister les sites de ventes de prestations pour PrestaShop est une bonne initiative, mais indirectement, j'ai dû mal à concevoir que la team Presta regarde ça d'un bon oeil. Si ta liste reste dans des produits gratuits, offerts gracieusement à la communauté, c'est une très bonne initiative. En revanche, si elle liste des produits payants sur des sites tiers et qu'ils sont aussi présents sur PrestaStore, ces sites proposent doivent obligatoirement proposer le même tarif TTC que sur PrestaStore, sinon ils rentrent en concurrence direct avec PrestaStore. Bien cordialement

A commencer par les 3suisses ! Est-tu sur Jeckyl que c'est une obligation ? Car ça semble tiré par les cheveux que l'un des plus gros vendeur en ligne français ne suivent pas la loi ! A+