PhenixTweet

Information importante

9 jours

INFO: Pensez à migrer vers PhenixPaypal pour ceux qui utilisent le module Paypal de base (ou ps_checkout) car l'API est devenue obsolète et ne sera plus maintenue en 2027.
De plus ce module offre beaucoup plus de fonctionnalités.

2 h.

a répondu au Message de herve_02 il y a 2 h.

Pour quel mail envoyé ?
Si c'est lors d'un changement de statut, ajoutez
{infos_liv} dans les templates d'emails de votre thème concernés par cette information.

Ensuite faites un override de OrderHistory sur la fonction sendMail():

CODEpublic function sendEmail($order, $template_vars = false)
{
    $template_vars['{infos_liv}'] = '';
    $carrier = new Carrier($order->id_carrier);
    if(Validate::isLoadedObject($carrier)) {
        if($carrier->id_reference == ***** X) { // ***** X est l'id_reference de votre transporteur magasin
            $template_vars['{infos_liv}'] = 'bla bla bla enlèvement en magasin...etc';
        }
    }

    return parent::sendEmail($order, $template_vars);
}

2 h.

a répondu au Message de BigM - 2 h.

C'est implémenté.

herve_02 @herve_02

5 h.

Question un peu technique. Est-ce qu'il y a un moyen de personaliser les mails envoyés suivant le __transporteur__ choisi ? Parce que nous aimerions rappler aux gens qui ont choisi retrait en boutique que ce sera un... retrait en boutique. Je n'ai pas vu qqpoart la possibilité de lier le transporteur à un statut automatiquement.

2 jours

a répondu au Message de yoyo64 - 2 jours

Concernant cette fonction, il serait impératif qu'elle reste uniquement une option activable et non un comportement par défaut.

En effet, nous préparons les colis 7 jours sur 7, mais les expéditions réelles n'ont lieu que du lundi au vendredi. C'est d'ailleurs pour cette raison que j'ai déjà demandé à Eolia d'implémenter une option permettant de désactiver globalement l'envoi du numéro de suivi (email de suivi) lors de sa saisie, au lieu de devoir le faire individuellement pour chaque commande.

2 jours

a répondu au Message de Eolia - 2 jours

Oui bonne idée !

2 jours

a répondu au Message de Eolia - 2 jours

ah oui c'est vrais peut être une option activable ou pas

2 jours

HELLO petit problem avec bannissement ip

Duplicate entry '3.239.255.135' for key 'ip'
INSERT INTO ps_ban_ip ...
Un script ou module essaie d’insérer une grande liste d’IP dans ps_ban_ip, mais ip est unique et 3.239.255.135 est déjà présente. L’insertion complète échoue à ce moment-là.
À corriger dans le script qui alimente cette table : utiliser INSERT IGNORE ou INSERT ... ON DUPLICATE KEY UPDATE ip = VALUES(ip), ou déduplique
Oui, ps_ban_ip est la table des IP banniesL’erreur signifie simplement que l’IP 3.239.255.135 est déjà bannie et que le script essaie de la bannir une seconde f

2 jours

a répondu au Message de yoyo64 - 2 jours

Qu'en pense le reste de la communauté ?
Ou alors suivant une option paramétrable en BO

(je connais des commerçants qui préparent leurs colis l'après-midi mais qui ne sont expédiés que le lendemain)

2 jours

a répondu au Message de herve_02 il y a 2 jours

La norme depuis 10 ans est d'insérer le type dans le nom du hook (display ou action). Cependant Prestashop utilise la table hook_alias pour assurer une rétro compatibilité.
Donc oui il est préférable d'utiliser HookDisplayHeader() pour tout nouveau module.
petite coquille dans le addCSS => $this->_path contient déjà le slash final donc inutile de le rajouter

2 jours

a répondu au Message de herve_02 il y a 2 jours

Oui vous pouvez utiliser les 2 en même temps, ce n'est pas la même API.
Vous activez le nouveau uniquement pour le groupe Test pour effectuer vos essais.

herve_02 @herve_02

2 jours

Je profite d'être là. je suis perdu. J'ai fait un module il y a quelques temps et j'ai un front.css
$this->registerHook('header')
public function hookHeader()
{$this->context->controller->addCSS($this->_path.'/views/css/front.css');
Et cela fonctionne. je veux en faire un autre et avec les même infos, cela ne marche pas. La "doc" (??) dit que le hook devrait être displayHeader.. comment le hook header arrive à fonctionner du coup ?
pourquoi pour un module et pas l'autre ?

herve_02 @herve_02

2 jours

a répondu au Message de Eolia - 2 jours

cela va fonctionner en 1.6.2.39 ? je suis toujours avec paypal v15 /o
J'ai lu qu'on pouvait activer seulent avec un groupe test. Est-ce à dire que l'on peut activer les 2 modules en même temps ? j'utilise v15 - by 202-ecommerce debug by Eolia

2 jours

Pour le version 1.6.2.49 ca serais bien d'avoir si possible dé que l'on rentre un suivi le statut passe en envoyer

4 jours

a répondu au Message de Eolia - 4 jours

Très propre merci !

5 jours

a répondu au Message de Yoann - 5 jours

Normalement oui. Commencez par l'installer en mode test et ne l'activez que pour le groupe Test (s'il n'existe pas créez-le et associez votre compte client à ce groupe pour pouvoir le voir en BO)

5 jours

a répondu au Message de Eolia - 5 jours

Salut, je suis en 1.6.2.28 je peux faire la mise à jour sans risque ? Merci

5 jours

a répondu au Message de Eolia - 5 jours

Merci d'avoir trouvé cela.
C'est corrigeable ?
C'est un module que tu avais "debuggé" il y a 2 ou 3 ans.

6 jours

a répondu au Message de Eolia - 6 jours

J'ai testé le module et il fonctionne maintenant comme prévu, ou du moins comme j'en avais l'habitude avec l'ancien module PayPal. Merci pour la rapidité de votre aide concernant un problème qui, apparemment, ne concernait que moi.

6 jours

a répondu au Message de Eolia - 6 jours

Oui, tout à fait, c'était et c'est bien mon intention. Pour les paiements via PayPal, il est important pour moi qu'ils soient effectués entièrement dans la devise par défaut de la boutique, indépendamment de la devise affichée sur le site (c'est d'ailleurs la raison pour laquelle je ne propose PayPal que comme option supplémentaire et que je préfère Stripe).

6 jours

a répondu au Message de Eolia - 6 jours

Version 1.3.2 qui devrait répondre à votre demande

phenixpaypal-1.3.2.zip

6 jours

a répondu au Message de BigM - 6 jours

Ok, donc ce que vous voulez, si je comprends bien, c'est que toute la commande du client passe en Yen lorsqu'il choisit le paiement Paypal, c'est bien ça ?

6 jours

a répondu au Message de Eolia - 6 jours

Lors du passage à PayPal, 1 yen s'affiche. Si je fais un test, 1 yen apparaît aussi dans le BO.
De plus, le réglage visible sur votre capture me pose problème. Si une commande en USD est payée en EUR, la commande et la facture doivent aussi être en EUR (sinon, le montant facturé diffère du montant payé).

6 jours

a répondu au Message de Eolia - 6 jours

En fait non, Paypal est encore moins cher (France au moins) https://www.paypalobjects....

6 jours

Pour ceux qui se posent la question:
https://www.putler.com/blo...

6 jours

a répondu au Message de BigM - 6 jours

Hum ça m'étonne. J'ai testé avec une commande en $ (devise par défaut €) et le paiement est bien passé en €

6 jours

a répondu au Message de Eolia - 6 jours

J'ai testé la mise à jour : ce n'est plus la devise affichée qui est transmise à PayPal, mais la devise par défaut de la boutique (Shop Default), ce qui est correct. Cependant, la valeur transmise est incorrecte : c'est toujours la valeur 1 qui est envoyée.

6 jours

a répondu au Message de Pilou - 6 jours

Vous avez le module Mollie, à priori c'est lui qui fait crasher le js. Ce module n'est pas compatible PHP 8.2+

6 jours

a répondu au Message de BigM - 6 jours

Pouvez-vous tester en effectuant la mise à jour du module et me dire si tout est ok avec votre configuration ?
De mon côté cela semble fonctionner comme vous le souhaitez.

phenixpaypal-1.3.1.zip

6 jours

a répondu au Message de Eolia - 6 jours

Bonjour eolia,
Non, pas d'override.
Pour les logs, je ne vois pas où chercher, désolé.

7 jours

a répondu au Message de BigM - 7 jours

Oui, il faut mettre des conditions dans plusieurs fichiers pour pouvoir vraiment utiliser la devise par défaut. Dès que j'ai terminé la nouvelle option je vous l'enverrai.
Pour l'erreur, effectivement il manque une virgule ligne 98:
'.(int)$cart->id.',