[v2.0] Module ATOS/Sips gratuit pour Prestashop : Tgg_ATOS

[jeckyl]

Merci, par contre pour le blocage d'adresses IP j'ai trouvé ceci http://www.countryipblocks.net/continents/, ce qui me fait économiser 50 euros ^^

Tout à fait, mais notre outil s'appuie sur une base de données mise à jour mensuellement ce qui permet de faciliter l'intégration rapide des informations, mais bien entendu qu'il existe des méthodes gratuites pour arriver au même résultat, c'est juste un module pour faciliter le travail surtout sur des installations fermées comme prestabox par exemple.

[graphee]

salut a tous,Salut Damien,

 

j'essaye désespérément de l'installer sur un prestashop 1.4.3 (j'ai pris la rc4)

 

mais impossible d'arrivé a mes fins :

--------------------------------------------------------------------------------

-PREMIER CAS : si je coche : "Mon serveur détient les binaires ATOS dans ses dossiers d'inclusion :"

 

j'ai ce message d'erreur : "Le paiement par carte est indisponible jusqu'à demain, nous vous prions d'accepter nos excuses pour cet inconvénient"

avec cette erreur :

 

array(2) {

["cmd"]=>

string(608) "request "amount=6000" "automatic_response_url=http://www.kalihair.fr/modules/tgg_atos/front-ctrl/payment-autoresponse.php" "cancel_return_url=http://www.kalihair.fr/modules/tgg_atos/front-ctrl/payment-return.php" "capture_day=0" "capture_mode=AUTHOR_CAPTURE" "currency_code=978" "customer_id=2" "[email protected]" "customer_ip_address=88.165.175.184" "language=fr" "merchant_id=082584341411111" "normal_return_url=http://www.kalihair.fr/modules/tgg_atos/front-ctrl/payment-return.php" "order_id=16" "transaction_id=42" "pathfile=/homez.373/kalihair/www/modules/tgg_atos/param/pathfile" 2>&1"

["status"]=>

int(127)

}

 

sh: request: command not found

 

---------------------------------------------------------------------

 

Si je ne coche PAS cette case, j'arrive a simuler mon paiement avec la carte de test (mercanet) mais quand je clic sur retour boutique j'ai cette erreur :

 

array(2) {

["cmd"]=>

string(1250) "/homez.373/kalihair/www/modules/tgg_atos/bin/response "message=(centaines de lignes en hexadecimal" "pathfile=/homez.373/kalihair/www/modules/tgg_atos/param/pathfile" 2>&1"

["status"]=>

int(0)

}

 

 

et ca en bas de page

 

!082584341411111!fr!6000!47!CB!20110801093053!113120!

20110801!00!1312191080!191080!978!4974.00!1!4D!00!!!!!!fr!

[email protected]!88.165.175.184!0!AUTHOR_CAPTURE!

!02!SSL!!201204!!!!!!!9!0Fatal error

 

avec page blanche.....

 

bref je sais plus quoi faire

 

 

pour info, j'ai bien récupéré le dossier MERCANET pour linux 32 bits (j'ai un hebergement ovh pro), j'ai bien remplacé les fichier dans bin par ceux de mercanet, idem pou 4 fichiers de param.

 

merci pour ton aide!

[graphee]

Bon ba après moulte essais, j'en reviens a un seul et unique souci :

 

- La commande n'est validée QUE lorsque l'on clique sur "retour a la boutique" après le paiement

- J'ai une grosse page d'erreur lorsque je clic sur ce bouton

- Pas de commande en backoffice, panier non vidé...

 

je me tire les cheveux

[petitbiston]

@ Graphee : réinstalle le tranquillement, lis bien le readme. Ce module tourne bien.

 

Vérifie bien tes chmod, tes dossiers bin, normalement tu recois les messages d'erreurs par email.

 

Bon courage

[kimzey]

Bonjour,

 

je galère un peu avec ce module, en effet après le bug des 54 caractères, l'erreur 127, je bloque sur l'erreur -1.

 

Je tourne sur un prestashop 1.4.1.0, le module (Tgg_Atos) Version 2.0 BETA 4 RC4 et c'est pour une utilisation de mercanet.

 

Merci d'avance pour vos idées et pistes de réflexion.

[kimzey]

Personne ?

[pppplus]

pas facile avec juste l'erreur -1 comme info.

Ce module marche très bien, il faut bien suivre les instructions d'installation.

 

Par contre, lorsqu'on a une erreur, c'est vrai que le code n'est pas clair. Ce serait top d'avoir un message en clair.

 

A quel moment se produit votre erreur ? Ca pourra nous aider à vous aider...

[kimzey]

Le soucis apparaît lorsque je sélectionne le module de paiement par carte, ainsi en lieu et place des icônes des cartes j'ai ce message :"Le paiement par carte est indisponible jusqu'à demain, nous vous prions d'accepter nos excuses pour cet inconvénient."

Si j'active le débogage, j'obtiens ce message:

 

array(2) {
 ["cmd"]=>
 string(618) "../modules/tgg_atos/bin/request"amount=065" "automatic_response_url=http://www.agelyance.com/modules/tgg_atos/front-ctrl/payment-autoresponse.php" "cancel_return_url=http://www.agelyance.com/modules/tgg_atos/front-ctrl/payment-return.php" "capture_day=0" "capture_mode=AUTHOR_CAPTURE" "currency_code=978" "customer_id=3" "[email protected]" "customer_ip_address=195.XXX.XX.XX" "language=fr" "merchant_id=XXXXXXXXXX" "normal_return_url=http://www.agelyance.com/modules/tgg_atos/front-ctrl/payment-return.php" "order_id=7136" "transaction_id=5" "pathfile=../modules/tgg_atos/param/pathfile" 2>&1"
 ["status"]=>
 int(-1)
}

 

J'ai un soucis uniquement sur la version en ligne de mon site, en local sur xampp ça fonctionne normalement.

 

Merci pour votre aide.

[pppplus]

Je n'ai jamais eu ce message :

Le paiement par carte est indisponible jusqu'à demain, nous vous prions d'accepter nos excuses pour cet inconvénient.

 

Mais je sais que certains l'ont eu. Regardez dans les précédents messages sur ce module, la réponse doit y être.

Ou sur le blog du module.

[kimzey]

Merci pour ces conseils mais j'ai déjà lu et relu ce topic et je n'y ai rien trouvé pour mon soucis, tout comme sur le blog de TrogloGeek.

[pppplus]

Ah mince alors ! Je suis pourtant quasiment sûr d'avoir lu la réponse quelque part.

 

=> avez-vous bien mis les 2 fichiers request et response en chmod 755 ?

=> au niveau du chemin complet vers les fichiers, êtes-vous sûr de ne pas dépasser les 54 caractères (depuis la racine du serveur, qq chose comme /home ou /www )

=> vos fichiers parcom et certif sont-ils exacts ?

[TrogloGeek]

Par contre, lorsqu'on a une erreur, c'est vrai que le code n'est pas clair. Ce serait top d'avoir un message en clair.

Bonjour, je suis un peu (beaucoup) débordé en ce moment.

Pour ce qui est des messages d'erreur, ceux-ci viennent de votre serveur d'hébergement, il serait possible de mettre en place une traduction des messages les plus courants, mais comme cela en fait déjà énormément, je doute que quelqu'un soit prêt à payer les centaines d'heures de travail que cela représente ? ;-)

Je n'ai jamais caché le fait que ce module nécessite l'intervention d'un technicien connaissant l'environnement d'hébergement... Cela est dû à la manière dont la passerelle ATOS fonctionne.

[TrogloGeek]

Le soucis apparaît lorsque je sélectionne le module de paiement par carte, ainsi en lieu et place des icônes des cartes j'ai ce message :"Le paiement par carte est indisponible jusqu'à demain, nous vous prions d'accepter nos excuses pour cet inconvénient."

Si j'active le débogage, j'obtiens ce message:

 

array(2) {
 ["cmd"]=>
 string(618) "../modules/tgg_atos/bin/request"amount=065" "automatic_response_url=http://www.agelyance.com/modules/tgg_atos/front-ctrl/payment-autoresponse.php" "cancel_return_url=http://www.agelyance.com/modules/tgg_atos/front-ctrl/payment-return.php" "capture_day=0" "capture_mode=AUTHOR_CAPTURE" "currency_code=978" "customer_id=3" "[email protected]" "customer_ip_address=195.XXX.XX.XX" "language=fr" "merchant_id=XXXXXXXXXX" "normal_return_url=http://www.agelyance.com/modules/tgg_atos/front-ctrl/payment-return.php" "order_id=7136" "transaction_id=5" "pathfile=../modules/tgg_atos/param/pathfile" 2>&1"
 ["status"]=>
 int(-1)
}

 

J'ai un soucis uniquement sur la version en ligne de mon site, en local sur xampp ça fonctionne normalement.

 

Merci pour votre aide.

Le message d'erreur "Le paiement par carte est indisponible jusqu'à demain, nous vous prions d'accepter nos excuses pour cet inconvénient." est un message générique front-office qui sert à masquer le message d'erreur réel par sécurité et par propreté.

La véritable erreur est le code retour (-1) retourné par le shell de votre serveur.

Très probablement soit:

=> un refus d'exécuter basé sur une restriction PHP (safe_mode ?) ou sur une mauvaise configuration des droits et propriétaires du dossier bin/.

=> des binaires incompatibles avec votre système (32 ou 64 bits ? quelle version du noyau ?).

[Nicolas.C]

Serait il possible d'avoir les chmod exacts pour le fichier bin svp.

Je rencontre le même genre d'erreur , j'ai tout essayé et toujours le même message.

 

De plus j'ai ceci => API ERROR :Error in call parameters structure (payment_means,block_order)

 

et même chose je ne trouve aucune solution pour me défaire de cette erreur

 

mes chemins sont bons, ils font - de 54 caracteres, j'utilise sherlock en mode démo

[pppplus]

Bonjour

 

Il faut absolument que les 2 executables de la banque soit en 755

/bin/request et /bin/response

 

Et il faut que le fichier /param/pathfile soit ouvert en écriture

Là, ça va dépendre de votre hébergeur 644 peut suffire, mais il faudra peut-être le mettre en 666.

C'est surtout ce fichier qui provoque les messages d'alerte en admin, lorsqu'on change la configuration

 

Il me semble qu'il n'y a pas besoin de modifier le reste

[Nicolas.C]

Merci de ton aide

[TrogloGeek]

Il faut absolument que les 2 executables de la banque soit en 755

/bin/request et /bin/response

 

Et il faut que le fichier /param/pathfile soit ouvert en écriture

Là, ça va dépendre de votre hébergeur 644 peut suffire, mais il faudra peut-être le mettre en 666.

C'est surtout ce fichier qui provoque les messages d'alerte en admin, lorsqu'on change la configuration

 

Il me semble qu'il n'y a pas besoin de modifier le reste

Un CHMOD de 0644 pour les exécutable est trop élevé dans la plupart des cas. Souvant un 0700 suffit, à condition de bien paramétrer les propriétaires du fichier. A défaut essayer 0750 et en dernier recourt 0755. Cela dit ce n'est pas un drame que cet exécutable puisse être lancé par n'importe qui, l'important est qu'il ne soit modifiable par le moins de personnes possible.

 

Pour le pathfile (idem parmcom et certif), idéalement 0600, 0660 si nécessaire, 0666 uniquement si absolument nécessaire !! 0666 est très dangereux sur un serveur mutualisé qui n'est pas cloisonné par des CHROOT sur tous les services et par l'open_basedir de PHP, car cela permet à un autre site/utilisateur de ce serveur de lire et modifier vos paramètres.

 

@pppplus : attention, 755, 644 et 666 ne sont pas des CHMODs valides, à contrario de 0755, 0644 et 0666 qui le sont. En effet un CHMODs est une notation octale, signalée par le préfixe 0.

 

755(10) = 01363(8)

644(10) = 01204(8)

666(10) = 01232(8)

 

0755(8) = 493(10)

0644(8) = 520(10)

0666(8) = 438(10)

 

L'intérêt de la notation octale est qu'elle code ses chiffres sur 3 bits, ce qui correspond bien au 3 bits de droits (rwx). Il est facile de traduire 0755 en rwxr-xr-x de tête, ce serait beaucoup plus dur avec sa notation décimale 493.

[mobi1970]

bonsoir,

 

excellent le module ,je ne suis pas un pro en programmation et je dois dire que ça a marché du premier coup ,demain je fais un test en temps réel par contre je trouve la page de paiement de BNP laide ça ne donne pas envie de payer ,c'est normal ou c'est moi qui divague ....si vous avez une info elle sera la bienvenue ..

je penserai au paypal de damien des que le test final sera concluant..

 

bien cordialement,

[pppplus]

à TrogloGeek : pour les chmod, il me semble que sur les softs FTP, on n'a souvent que les 3 derniers chiffres, sans le 0 initial, d'où mon raccourci.

 

Chez moi /bin/request et /bin/response en 700, ça ne marche pas. Il faut bien 755 pour que le fichier soit exécutable. (avec le 0 en plus devant, évidemment )

 

à mobi1970 : on peut créer son propre template de page de paiement. Ca doit être expliqué dans votre doc CB fournie par la banque. Une fois votre template fait et testé, il faut l'envoyer à la banque, pour qu'il le mette à la place de la page par défaut.

 

[TrogloGeek]

Oui, le 0700 ne fontionne pas partout, mais dire qu'il faut systématiquement appliquer un 0755 est faux.

 

Effectivement, on peut utiliser des templates, la prochaines version du module a paraître intègre un système de fichier XML pour définir des variables supplémentaires à ajouter à l'appel de request, la variable "templatefile" par exemple.

 

Cela dit vous trouvez la page moche, peut-etre, mais il faut prendre en compte le fait que l'acheteur potentiel connait probablement déjà cette page pour l'avoir déjà vue ailleurs, ce qui peut être une bonne chose en terme de confiance.

[Samantha66]

Bonjour,

 

J'utilise le module Tgg Atos depuis plusieurs versions déjà, c'est un super module, aucun soucis...sauf avec la dernière version la 2.1.6 et ma version Prestashop 1.4.5.

Les commandes sont bien payées, j'ai le retour "Paiement accepté" dans le back office et la somme est bien sur le compte bancaire, mais sur certaines commandes, quelques jours ou heures plus tard, elles passent en "Annulé", sans intervention dans le back office.

 

Je ne sais pas si ça provient de la banque (SG) ou du module.

 

Merci d'avance pour ton aide et merci pour ce super module.

[TrogloGeek]

Bonjour,

j'ai déjà été confronté à ce problème sur une boutique osCommerce à fort traffic (une commande par minute pendant les période de forte affluence), il s'agissait de la banque (je tairai le nom de la banque, il ne s'agissait pas de SG, mais de toutes façons tout se

passe chez ATOS quelque soit la banque avec laquelle vous avez souscrit le contrat VAD), le serveur ATOS renvoyait des informations contradictoire (transaction acceptée, puis transaction refusée ou annulée... alors que le paiement avait bien été effectué)

Vous pouvez aisément savoir s'il s'agit d'un comportement erratique du serveur bancaire en vérifiant les logs générés par le module, cherchez toutes les réponses correspondant à l'ID de transaction des commandes problématiques, ID que vous trouverez dans le message de logs que laisse le module sur chaque commande, ces logs sont tirés de la première réponse reçue, qu'elle soit dues au retour client ou à une réponse directe du serveur bancaire.

[TrogloGeek]

Désolé, j'ai répondu un peu vite la dernière fois : ce problème ne peut pas venir du serveur bancaire puisque mon module ne crée pas de commande annulée en cas de refus bancaire ou d'annulation pour permettre à l'utilisateur de valider son panier via une autre méthode de paiement.

En fait, le module ne peut pas être responsable de ceci s'il n'a pas été modifié car aucune de ses fonctions n'implique une mise à jour du statut de commande (il affecte un statut uniquement à la création de la commande).

Il faut chercher ailleurs l'origine de ce problème.

[binou-ze]

Bonjour,

le module marche bien en étape de démo, mais je n'arrive pas a le faire marcher en prepros.

J'ai envoyé le certificat, mis l'id marchant.

Et après pour l'étape de la commande ca me met :

Le paiement par carte est indisponible jusqu'à demain, nous vous prions d'accepter nos excuses pour cet inconvénient.

 

Je recois sur mon mail :

Error reading certificate data at line (FE8D14DE85C220865B165B228AAA1B326A83563A3C239122DC85DFBC57C1A7CF9F )

 

Merci d'avance

Cordialement

Robin

(félicitation pour le module)

[binou-ze]

Bonjour,

je suis arrivé à résoudre le problème en chargant un certificat classique et non en php sur l'extranet de la BNP.

Je met au cas ou des gens avait le même problème.

[FAP]

Bonjour,

 

Je voulais tout d'abord remercier TrogloGeek de mettre à disposition ce module.

 

Bon maintenant, moi je rencontre un soucis qui doit être tout con mais bon étant un peu novice, je dois pas chercher au bon endroit pour résoudre mon problème. Puis surtout, je ne sais ce qu'il faut que je fasse....

Je n'ai aucune devise proposée dans la section "devise par défaut" et pourtant quand je vais voir sur le fichier tgg_atos.php, j'ai bien les devises.

je suis chez OVH et la version de mon presta : 1.4.6.2

 

Merci pour ceux qui liront (et surtout qui répondront )

[TrogloGeek]

Bonjour,

Vérifiez premièrement sur la page de configuration des méthodes de paiement Prestashop la liste des devises autorisées pour ce module. C'est un oubli courant.

[Melusine]

Bonjour

 

Le site donc je m’occupe tourne actuellement sous Presta 1.4.6.2 et j’utilise la version 2.0-beta4-rc-4 de votre module. Je souhaiterais savoir s’il était possible de rajouter la possibilité de payer avec la carte American Express. Mon client tient à cette possibilité.

 

Merci d’avance,

Julie

[Melusine]

Je me suis penchée sur les fichiers à l'intérieur du module et j'ai vu comment on pouvait rajouter American Express. Dans la configuration du module, dans les moyens de paiement acceptés, il faut rajouter AMEX tout simplement ! J'avais essayé "American Express" ce matin mais ça ne fonctionnais pas, avec AMEX ça fonctionne à merveille ^^

Voilà

Bonne fin de journée

[Melusine]

Autre problème, si un client fait une commande par CB et que cette commande est refusée par la banque (plafond trop élevé, code fait trop de fois, ....), la commande en question passe en annulée et se supprime du backoffice (onglet commande). Quelqu'un a t'il déjà eu ce soucis ? Et si oui, comment l'avez-vous réglé ?

 

Petite précision, s'il s'agit d'une commande faite par chèque, virement bancaire, kwixo ou paypal et qu'on l'annule manuellement, elle reste en place dans le BO.

 

Je suis sous presta 1.4.6.2 et j’utilise la version 2.0-beta4-rc-4 du module tgg_atos.

 

Merci d'avance.

Mélusine

[plvd13]

Salut, à tous !

 

J'utilise le module TGG ATOS depuis 1 an à peut prêt sur un petit site spécialisé...

Jusqu'à maintenant tout ce passé pour le mieux mais depuis mi-mars, toutes les commandes passées sont en banque mais pas dans le backoffice, donc pas d'alerte de commande... je suis un peu désœuvré !

 

Version presta :

1.4.0.17

 

Module TGG ATOS :

2.0-beta3-rc-3

 

Merci d'avance

[petitbiston]

@ Plv13 : tu peux déjà effectuer la mise à jour du module ;o)

[Melusine]

Petit up de mon soucis please ?!

[plvd13]

@ Plv13 : tu peux déjà effectuer la mise à jour du module ;o)

 

Bien ce qui m'étonnes c'est que tout fonctionné jusqu'à maintenant sans faire de mise à jour... peut être je vais attendre une réponse du dev.

 

Merci

[TrogloGeek]

Autre problème, si un client fait une commande par CB et que cette commande est refusée par la banque (plafond trop élevé, code fait trop de fois, ....), la commande en question passe en annulée et se supprime du backoffice (onglet commande). Quelqu'un a t'il déjà eu ce soucis ? Et si oui, comment l'avez-vous réglé ?

 

Petite précision, s'il s'agit d'une commande faite par chèque, virement bancaire, kwixo ou paypal et qu'on l'annule manuellement, elle reste en place dans le BO.

 

Je suis sous presta 1.4.6.2 et j’utilise la version 2.0-beta4-rc-4 du module tgg_atos.

 

Merci d'avance.

Mélusine

Bonjour, ce module ne crée pas de commande en cas d'échec de paiement pour que le panier du client reste intact et qu'il puisse repartir directement en paiement (via ce module après avoir corrigé les informations ou avec un autre module de paiement).

 

La version 2.1.7 actuellement en bêta-test privés propose une alternative à cela, cf changelog

http://prestashop.blog.capillotracteur.fr/2012/04/07/tgg_atos-version-2-1-7-prete-pour-les-beta-tests/

[TrogloGeek]

Salut, à tous !

 

J'utilise le module TGG ATOS depuis 1 an à peut prêt sur un petit site spécialisé...

Jusqu'à maintenant tout ce passé pour le mieux mais depuis mi-mars, toutes les commandes passées sont en banque mais pas dans le backoffice, donc pas d'alerte de commande... je suis un peu désœuvré !

 

Version presta :

1.4.0.17

 

Module TGG ATOS :

 

2.0-beta3-rc-3

 

Merci d'avance

J'ai répondu directement à votre commentaire sur le blog.

[TrogloGeek]

@ Plv13 : tu peux déjà effectuer la mise à jour du module ;o)

Les mises à jours ne sont pas forcément une solution à appliquer systématiquement, en effet chaque ajout de fonctionnalité peut apporter ses propres problèmes, même si chaque release subit des tests avant de sortir.

Le mieux étant de consulter le changelog pour savoir si des bugs ont été corrigés et si l'on est concerné par ces bugs.

En l'occurence c'est vrai que la 2.0.3 date un peu et que quelques bugs mineurs ont été corrigés dans la 2.0.4. Il me semble aussi que j'en ai corrigé dans la 2.1.6 mais je n'en suis pas certain car je n'ai pas tenu de journal des modifications durant son développement et qu'à la fin de celui-ci j'avais oublié une bonne partie des modifications effectuées pour améliorer la solution et que par conséquent sont changelog est plus qu'incomplet.

[alex69]

Bonjour,

 

Je vous pris de m'excuser par avance si cette question a déjà été traitée dans ce fil, j'ai lu plus de la moitié des discussions et j'ai mal au crane :-)

 

Je suis sous en train de développer un site avec une version de presta 1.4.6 et pour le paiement je vais avoir besoin d'utiliser un module gérant Atos.

 

J'ai donc téléchargé le module de TrogloGeek, lu la doc, modifier les permissions de fichier et mis à jour le fichier 'request' et 'response' par rapport à ceux fournit par ma banque.

 

Lorsque j'installe le module, j'ai une erreur dans le journal de log : "Installation standard du module (parent::install()) échouée."

Mais cette erreur ne gêne à priori ni l'installation, ni le bon fonctionnement du module puisqu'en mode démo et préproduction, j'arrive à passer mon paiement.

 

Je voulais remonter cette info et vous en faire part afin de savoir si cela avais une incidence sur le bon fonctionnement de l'ensemble.

[TrogloGeek]

Lorsque j'installe le module, j'ai une erreur dans le journal de log : "Installation standard du module (parent::install()) échouée."

Mais cette erreur ne gêne à priori ni l'installation, ni le bon fonctionnement du module puisqu'en mode démo et préproduction, j'arrive à passer mon paiement.

C'est généralement signe que la boutique a un soucis (l'échec vient de Prestashop et non du module), cela peut ne jamais poser de problème tout comme être signe d'une défaillance majeure de Prestashop.

Si vous ne constatez aucun problème à priori tout va bien, mais ouvrez l'oeil.

[alex69]

ok, merci pour votre réponse.

 

Je vais installer votre module sur un prestashop tout neuf et essayer ensuite d'installer tous les autres modules que je souhaite utiliser pour voir si je rencontre le même problème.

 

Merci encore pour votre module, je n'ai pas encore eu le temps de tout tester mais il me semble vraiment très complet et très simple d'utilisation.

[binou-ze]

Bonjour,

j'ai essayé plusieurs manipulations,

je suis sous un ovh pro

j'en arrive la :

Merci d'avance

Robin

TGG_ATOS DEBUG OUTPUT

 

Tgg_Atos: Erreur durant l'appel de l'exécutable request

 

L'exécutable request a retourné une erreur.

 

(139):

TGG_ATOS DEBUG OUTPUT

array(3) {

["cmd"]=>

string(680) "/homez.333/imprimen/www/4x4-ProAccess/atos/bin/request "amount=2770" "automatic_response_url=http://www.pro-access4x4.biz/modules/tgg_atos/front-ctrl/payment-autoresponse.php" "cancel_return_url=http://www.pro-access4x4.biz/modules/tgg_atos/front-ctrl/payment-return.php" "capture_day=0" "capture_mode=AUTHOR_CAPTURE" "currency_code=978" "customer_id=47" "[email protected]" "customer_ip_address=213.41.191.101" "language=fr" "merchant_id=013044876511111" "normal_return_url=http://www.pro-access4x4.biz/modules/tgg_atos/front-ctrl/payment-return.php" "order_id=444" "transaction_id=11" "pathfile=/homez.333/imprimen/www/4x4-ProAccess/atos/param/pathfile" 2>&1"

["status"]=>

int(139)

["system_result"]=>

string(0) ""

}

[RADIOTECH]

Bonjour,

Ayant voulu installer le module, j'ai le même soucis

erreur 139 sans autre commentaire.

Comme benou-ze, je suis sous OVH-Pro.

J'ai pensé au départ que les URL étaient trop longues,

je les ai donc descendues d'un répertoire pour être en dessous de 54 caractères.

mais j'ai la même erreur.

Merci de votre aide

[RADIOTECH]

J'ai trouvé ça dans la doc,

mais je comprend pas bien

 

Le mode débug indique un code de retour 139 lors de l'appel à l'un des exécutables, qu'estce

que cela signifie ?

Là, même Google aurait pu vous répondre ;-)

Il est fort vraisemblable que vous n'ayez pas la version des binaires ATOS correspondant à votre

système d'exploitation. Mettez votre hébergeur et votre banque en relation pour obtenir les binaires

adaptés à votre hébergement.

[alex69]

Bonjour,

 

ça signifie que tes fichiers request et response ne sont pas à jour.

Normalement ta banque te donne des un pack comprenant des documentations (à lire) et des fichiers permettant de faire fonctionner leur solution de paiement.

 

En fonction des banques certains fichiers changent par contre chaque banque fournit un fichier request et un fichier response fonctionnant avec leur système. C'est ces fichiers là qu'il faut copier dans le répertoire /bin/ du module de Trologeek.

 

De même, la banque fournit un fichier parcom et un fichier certif à jour, vous pouvez les copiers dans le répertoire /param/ du module, ça vous évitera des erreurs de retour.

 

Pensez à bien modifier les permissions de ces fichiers en suivant la doc de TroloGeek pour que cela fonctionne.

[RADIOTECH]

Merci pour votre aide..

J'ai donc transféré les fichiers correspondants dans le dossier BIn etc....

J'ai des fichiers nommés request_2.6...., request_2.4....

Faut il les renommer?

[alex69]

normalement oui. Les fichiers que vous avez sont sans doute pour des versions 32 bits ou 64 bits de linux, certaines banques fournissent des fichiers différents. Essayer les fichier 32 bits (x86) ils sont censés marcher sur tous les serveurs linux.

 

Si les noms de fichiers ne sont que 2.6, 2.4..., ce sont sans doute des versions, prenez le plus récent et renommer le.

 

De toute façon, si ça ne fonctionne pas vous verrez une erreur lors du test de paiement. en fonction, changer les permissions ou le fichier.

[binou-ze]

Bonjour,

merci pour ta réponse,

il faut même les mettre quant on est en mode démo ?

 

Merci d'avance

Binou-ze

[alex69]

Bonjour,

 

les fichiers request et response oui,

les fichiers certif et param non.

[binou-ze]

Bonjour,

j'ai essayé de faire plusieurs teste, avec du linux 32 et 64.

Mais j'en arrive toujours à la même erreur.

Si vous avez des manipulations à me conseiller, des choses que je puisse vérifier..

 

Cordialement

Robin

[TrogloGeek]

Bonjour,

 

ça signifie que tes fichiers request et response ne sont pas à jour.

Normalement ta banque te donne des un pack comprenant des documentations (à lire) et des fichiers permettant de faire fonctionner leur solution de paiement.

 

En fonction des banques certains fichiers changent par contre chaque banque fournit un fichier request et un fichier response fonctionnant avec leur système. C'est ces fichiers là qu'il faut copier dans le répertoire /bin/ du module de Trologeek.

Ce n'est pas une question d'être à jour ou de provenir de la même banque, les banques exploitent ATOS en version 600 depuis la nuit des temps (oui oui, vous payez une fortune pour un système obsolète) et en réalité quelque soit la banque ce sont les même exécutables puisqu'au final tout arrive sur les serveur ATOS/SIPS, pas ceux de la banque. La banque ne fait quasiment que vous revendre le service fournit par ATOS/SIPS.

C'est tout simplement une question de compatibilité entre votre système d'exploitation et le binaire. Si vous ne comprenez-pas laissez votre hébergeur s'en occuper, je rappelle qu'installer une passerelle de paiement publique par quelqu'un n'étant pas techniquement qualifié porte un nom, cela s'appelle de la négligence criminelle. Raison pour laquelle je ne suis pas censé apporter de support aux personnes non qualifiées ne souhaitant pas être qualifié de "complice".

Edited May 29, 2012 by TrogloGeek (see edit history)

[TrogloGeek]

J'ai des fichiers nommés request_2.6...., request_2.4....

Si les noms de fichiers ne sont que 2.6, 2.4..., ce sont sans doute des versions, prenez le plus récent et renommer le.

Absolument pas, il s'agit de versions kernel pour laquelle l'exécutable a été compilé. Vous devez choisir le fichier ayant une version kernel et une largeur de bus compatibles avec le système d'exploitation de votre hébergement.

Edited May 29, 2012 by TrogloGeek (see edit history)

[webasun]

Bonjour,

 

Je m’excuse par avance si la question que je vais poser à déjà été traité (difficile d'effectuer une recherche sur un topic comportant plusieurs centaine de posts )

 

Sur la boutique que je met en place je n'utilise que le paiement par carte bleu donc le module tgg_atos.

J'aimerai sauter l'étape consistant à cliquer sur le logo de la banque et intégrer directement le choix de la carte de paiement dans le hook.

 

Cela est il possible ? Si oui comment me conseillez vous de faire ?

 

J'ai quelques notions en développement php mais ne connaissant pas l'architecture du projet je préfère vous demander votre avis avant de faire n’importe quoi.

 

Par avance merci.

Edited June 7, 2012 by Olivier Webasun (see edit history)

[Dev On Web]

Bonjour,

 

Oui tout à fait, j'ai déjà réalisé cela.

 

Il faut overrider la fonction _assignPayment() du contrôleur OrderController.php puis adapter le TPL ensuite.

[TrogloGeek]

Bonjour,

 

Je m’excuse par avance si la question que je vais poser à déjà été traité (difficile d'effectuer une recherche sur un topic comportant plusieurs centaine de posts )

 

Sur la boutique que je met en place je n'utilise que le paiement par carte bleu donc le module tgg_atos.

J'aimerai sauter l'étape consistant à cliquer sur le logo de la banque et intégrer directement le choix de la carte de paiement dans le hook.

 

Cela est il possible ? Si oui comment me conseillez vous de faire ?

 

J'ai quelques notions en développement php mais ne connaissant pas l'architecture du projet je préfère vous demander votre avis avant de faire n’importe quoi.

 

Par avance merci.

C'est effectivement possible, il faut appeler getPaymentForm() depuis le hookPayment lorsque le paiement est autorisé puis transmettre le résultat au template pour afficher le formulaire.

 

Par contre ce n'est pas recommandé pour des raisons de performance et de volume (vous consommerez plus d'ID de transaction par jour), surtout si vous souhaitez proposer différents modes de paiement (simple ou en plusieurs fois).

[TrogloGeek]

Bonjour,

 

Oui tout à fait, j'ai déjà réalisé cela.

 

Il faut overrider la fonction _assignPayment() du contrôleur OrderController.php puis adapter le TPL ensuite.

Réponse intéressante mais Il faudrait peut être préciser qu'il s'agit d'une alternative à ce qui est demandé : vous proposez de sauter l'étape de choix de la méthode de paiement alors qu'il demande à afficher directement le formulaire ATOS depuis cette page, conservant ainsi la possibilité d'avoir plusieurs méthodes de paiement et le récapitulatif avant paiement.

[webasun]

Bonjour,

 

Oui tout à fait, j'ai déjà réalisé cela.

 

Il faut overrider la fonction _assignPayment() du contrôleur OrderController.php puis adapter le TPL ensuite.

 

Réponse intéressante mais Il faudrait peut être préciser qu'il s'agit d'une alternative à ce qui est demandé : vous proposez de sauter l'étape de choix de la méthode de paiement alors qu'il demande à afficher directement le formulaire ATOS depuis cette page, conservant ainsi la possibilité d'avoir plusieurs méthodes de paiement et le récapitulatif avant paiement.

 

C'est effectivement possible, il faut appeler getPaymentForm() depuis le hookPayment lorsque le paiement est autorisé puis transmettre le résultat au template pour afficher le formulaire.

 

Par contre ce n'est pas recommandé pour des raisons de performance et de volume (vous consommerez plus d'ID de transaction par jour), surtout si vous souhaitez proposer différents modes de paiement (simple ou en plusieurs fois).

 

 

Je précise au passage que je suis en mode " One page checkout "

Il n'y a donc pas de page entre la validation du panier et le choix de la méthode de paiement, de plus je veux garder la possibilité de proposer un jour d'autre méthodes de paiement comme le disais TrogloGeek.

 

Je vais donc essayer la méthode de TrogloGeek qui correspond plus à ce que je désir faire.

Je vous tiens au courant de ce que ça donne.

 

Merci à vous et merci pour ce module.

Edited June 7, 2012 by Olivier Webasun (see edit history)

[Dev On Web]

Ok effectivement. Néanmoins, j'avais quand même tester le nombre de moyens de paiements proposés :

 

 

Si ATOS était le SEUL, alors on passe l'étape, sinon, on affiche les différents moyens de paiements

[TrogloGeek]

Ok effectivement. Néanmoins, j'avais quand même tester le nombre de moyens de paiements proposés :

 

 

Si ATOS était le SEUL, alors on passe l'étape, sinon, on affiche les différents moyens de paiements

Je me doute bien, mais passer l'unique page du One Page Checkout me semble une mauvaise idée, enfin, sauf erreur de ma part ;-)

[Dev On Web]

Hihi oui carrément

[webasun]

Je me doute bien, mais passer l'unique page du One Page Checkout me semble une mauvaise idée, enfin, sauf erreur de ma part ;-)

 

TrogloGeek winner .

Mais ta proposition était intéressante "Dev On Web".

 

Bon j'ai fais les petites modifs comme TrogloGeek me la suggéré et ça à l'aire de fonctionner très bien.

 

Pour ceux que ça intéresse voila ce que j'ai modifié.

J'invite Troglogeek à contrôler et valider mes modifications car je ne suis pas très expérimenté en php . Je ne voudrais pas ouvrir une faille de sécurité par inadvertance.

 

Dans le fichier tgg_atos.php modification de la fonction hookPayment :

 

public function hookPayment($params){
 /* @var $smarty Smarty */
 global $smarty;
 /* @var $cart Cart */
 $cart = $params['cart'];

// ------modif--------
 $Tgg_Atos = new tgg_atos();
 $splitted = Tools::getValue('splitted', FALSE);
 if ($Tgg_Atos->canProcess($cart, $splitted) !== TRUE)
 {
  Tools::redirect('order.php?step=3');
  die();
 }
// ------fin modif-------

 $payment_currency = null;

//-------modif------
 $atos_form = $Tgg_Atos->getPaymentForm($amount, $payment_currency, $splitted);
 $smarty->assign(compact(
  'atos_form',
  'amount',
  'payment_currency',
  'splitted'
 ));
//------fin modif----------

 $smarty->assign(array(
  'controller' => _MODULE_DIR_.$this->name.'/'.'front-ctrl/payment-redirect.php',
  'bank' => $this->_get('BANK'),
  'willSwitchCurrency' => $this->_willSwitchCurrency($cart),
  'canProcess' => $this->canProcess($cart),
  'fees' => $this->getCartFeesStr($cart, $payment_currency),
  'total' => Tools::displayPrice($cart->getOrderTotal() + $this->getCartFees($cart, $payment_currency), $payment_currency),
  'canProcess2t' => $this->canProcess($cart, 2),
  'canProcess3t' => $this->canProcess($cart, 3),
  '2t_allowed' => $this->_get('BOOL_2TPAYMENT'),
  '2t_fees' => $this->getCartFeesStr($cart, $payment_currency, 2),
  '2t_total' => Tools::displayPrice($cart->getOrderTotal() + $this->getCartFees($cart, $payment_currency, 2), $payment_currency),
  '3t_allowed' => $this->_get('BOOL_3TPAYMENT'),
  '3t_fees' => $this->getCartFeesStr($cart, $payment_currency, 3),
  '3t_total' => Tools::displayPrice($cart->getOrderTotal() + $this->getCartFees($cart, $payment_currency, 3), $payment_currency)
 ));
 return $this->display(__FILE__, 'tpl/'.$this->name.'-front-hookpayment.tpl');
}

 

 

Dans le fichier tgg_atos-front-hookpayment.tpl ( Les modifications se passe dans les 50 première lignes j'ai donc coupé la suite du fichier pour ne pas surcharger le post) :

 

{if $willSwitchCurrency}
{capture name="willSwitchCurrency"}{l s='This payment method will use a different currency to proceed with payment. %s will be used.' mod='tgg_atos'}{/capture}
{/if}
<p class="payment_module">
{if $canProcess === TRUE}
<!-- .............. modif....... -->
   {if $atos_form}
   <p style="margin-top:20px;">
    <strong>{l s='Click on one of the payment meanings logos below to proceed on a secure bank server.' mod='tgg_atos'}</strong>
   </p>

   {$atos_form}
   {else}
   <div class="error">
    <strong>{l s='Sorry, no more CB payments can be processed today, bank server should be available again at midnight.' mod='tgg_atos'}</strong>
   </div>
   {/if}
<!-- ..............fin modif...............J'ai mis en commentaire quelques lignes ci-dessous car elles ne sont  plus utils.......... -->
<!--   <a href="{$controller}" title="{l s='Pay with a card' mod='tgg_atos'}">-->
{else}
   <a href="#" onclick="alert($(this).text());">
{/if}

   <!-- <img src="{$module_template_dir}images/bank_logo/{$bank}.gif" alt="{l s='Pay with a card' mod='tgg_atos'}" />
 {l s='Pay with a card' mod='tgg_atos'}-->
   {if $willSwitchCurrency}
 <br />
 <br />
 {$smarty.capture.willSwitchCurrency|sprintf:$willSwitchCurrency.name}
   {/if}
   {if $canProcess !== TRUE}
 <br />
 <br />
 {$canProcess}
   {/if}
   {if $fees}
 <br />
 <br />
 {l s='This payment method is subject to payment fees. If used your order amount will be increased by:' mod='tgg_atos'}<br />
 {$fees}<br />
 <strong>
  {l s='Total amount to be paid:' mod='tgg_atos'}
  {$total}
 </strong>
   {/if}
   </a>
</p>
<!--.................. suite du code .......................-->

 

Voila j’espère que j'ai pas fait de bêtise.

 

n'hésitez pas à me corriger.

 

Merci à vous

Edited June 7, 2012 by Olivier Webasun (see edit history)

[TrogloGeek]

TrogloGeek winner .

TrogloGeek always wins

 

Mais ta proposition était intéressante "Dev On Web".

 

Bon j'ai fais les petites modifs comme TrogloGeek me la suggéré et ça à l'aire de fonctionner très bien.

 

Pour ceux que ça intéresse voila ce que j'ai modifié.

J'invite Troglogeek à contrôler et valider mes modifications car je ne suis pas très expérimenté en php . Je ne voudrais pas ouvrir une faille de sécurité par inadvertance.

 

Dans le fichier tgg_atos.php modification de la fonction hookPayment :

 

public function hookPayment($params){
 /* @var $smarty Smarty */
 global $smarty;
 /* @var $cart Cart */
 $cart = $params['cart'];

// ------modif--------
 $Tgg_Atos = new tgg_atos();
 $splitted = Tools::getValue('splitted', FALSE);
 if ($Tgg_Atos->canProcess($cart, $splitted) !== TRUE)
 {
  Tools::redirect('order.php?step=3');
  die();
 }
// ------fin modif-------

 $payment_currency = null;

//-------modif------
 $atos_form = $Tgg_Atos->getPaymentForm($amount, $payment_currency, $splitted);
 $smarty->assign(compact(
  'atos_form',
  'amount',
  'payment_currency',
  'splitted'
 ));
//------fin modif----------

 $smarty->assign(array(
  'controller' => _MODULE_DIR_.$this->name.'/'.'front-ctrl/payment-redirect.php',
  'bank' => $this->_get('BANK'),
  'willSwitchCurrency' => $this->_willSwitchCurrency($cart),
  'canProcess' => $this->canProcess($cart),
  'fees' => $this->getCartFeesStr($cart, $payment_currency),
  'total' => Tools::displayPrice($cart->getOrderTotal() + $this->getCartFees($cart, $payment_currency), $payment_currency),
  'canProcess2t' => $this->canProcess($cart, 2),
  'canProcess3t' => $this->canProcess($cart, 3),
  '2t_allowed' => $this->_get('BOOL_2TPAYMENT'),
  '2t_fees' => $this->getCartFeesStr($cart, $payment_currency, 2),
  '2t_total' => Tools::displayPrice($cart->getOrderTotal() + $this->getCartFees($cart, $payment_currency, 2), $payment_currency),
  '3t_allowed' => $this->_get('BOOL_3TPAYMENT'),
  '3t_fees' => $this->getCartFeesStr($cart, $payment_currency, 3),
  '3t_total' => Tools::displayPrice($cart->getOrderTotal() + $this->getCartFees($cart, $payment_currency, 3), $payment_currency)
 ));
 return $this->display(__FILE__, 'tpl/'.$this->name.'-front-hookpayment.tpl');
}

 

 

Dans le fichier tgg_atos-front-hookpayment.tpl ( Les modifications se passe dans les 50 première lignes j'ai donc coupé la suite du fichier pour ne pas surcharger le post) :

 

{if $willSwitchCurrency}
{capture name="willSwitchCurrency"}{l s='This payment method will use a different currency to proceed with payment. %s will be used.' mod='tgg_atos'}{/capture}
{/if}
<p class="payment_module">
{if $canProcess === TRUE}
<!-- .............. modif....... -->
   {if $atos_form}
<p style="margin-top:20px;">
	<strong>{l s='Click on one of the payment meanings logos below to proceed on a secure bank server.' mod='tgg_atos'}</strong>
</p>

{$atos_form}
   {else}
<div class="error">
	<strong>{l s='Sorry, no more CB payments can be processed today, bank server should be available again at midnight.' mod='tgg_atos'}</strong>
</div>
   {/if}
<!-- ..............fin modif...............J'ai mis en commentaire quelques lignes ci-dessous car elles ne sont  plus utils.......... -->
<!--   <a href="{$controller}" title="{l s='Pay with a card' mod='tgg_atos'}">-->
{else}
<a href="#" onclick="alert($(this).text());">
{/if}

<!-- <img src="{$module_template_dir}images/bank_logo/{$bank}.gif" alt="{l s='Pay with a card' mod='tgg_atos'}" />
 {l s='Pay with a card' mod='tgg_atos'}-->
{if $willSwitchCurrency}
 <br />
 <br />
 {$smarty.capture.willSwitchCurrency|sprintf:$willSwitchCurrency.name}
{/if}
{if $canProcess !== TRUE}
 <br />
 <br />
 {$canProcess}
{/if}
{if $fees}
 <br />
 <br />
 {l s='This payment method is subject to payment fees. If used your order amount will be increased by:' mod='tgg_atos'}<br />
 {$fees}<br />
 <strong>
  {l s='Total amount to be paid:' mod='tgg_atos'}
  {$total}
 </strong>
{/if}
</a>
</p>
<!--.................. suite du code .......................-->

 

Voila j’espère que j'ai pas fait de bêtise.

 

n'hésitez pas à me corriger.

 

Merci à vous

Lol, c'est un bon début.

 

Par contre lorsque tu codes à l'intérieur d'une instance tgg_atos ce n'est pas la peine d'en instancier une nouvelle.

$Tgg_Atos = new tgg_atos();

Ceci vient du fichier controlleur retour et n'a pas sa place ici. Retire cette ligne et remplace tes $Tgg_Atos par $this.

 

Ensuite:

- soit tu utilises les paiement en plusieurs fois et il te faut un appel à getPaymentForm() par méthode (en 1, 2 ou 3 fois) avec le paramètre splitted qui va bien et tu affiches tous les formulaires en indiquant bien quel formulaire correspond à quoi

- soit tu n'utilises pas le paiement en plusieurs fois et tu vires tout ce qui y fait référence parce que là,

$splitted = Tools::getValue('splitted', FALSE);

ne te donnera jamais rien.

 

Et si tu utilises plus de devises que la banque n'en propose, vérifies que le système de fallback currency fonctionne toujours (càd le retour à une devise acceptée par la banque si la devise choisie par l'utilisateur n'est pas compatible) !

 

 

NOTE AUX LECTEURS

il faut bien comprendre que ceci est un bricolage, qu'il n'est valable que dans certains cas.

Vous pouvez vous en inspirer, mais toute tentative de copier coller sans réfléchir n'aboutira à rien d'autre qu'à des catastrophes !

Edited June 7, 2012 by TrogloGeek (see edit history)

[webasun]

TrogloGeek always wins

 

 

Lol, c'est un bon début.

 

Par contre lorsque tu codes à l'intérieur d'une instance tgg_atos ce n'est pas la peine d'en instancier une nouvelle.

$Tgg_Atos = new tgg_atos();

Ceci vient du fichier controlleur retour et n'a pas sa place ici. Retire cette ligne et remplace tes $Tgg_Atos par $this.

 

Ensuite:

- soit tu utilises les paiement en plusieurs fois et il te faut un appel à getPaymentForm() par méthode (en 1, 2 ou 3 fois) avec le paramètre splitted qui va bien et tu affiches tous les formulaires en indiquant bien quel formulaire correspond à quoi

- soit tu n'utilises pas le paiement en plusieurs fois et tu vires tout ce qui y fait référence parce que là,

$splitted = Tools::getValue('splitted', FALSE);

ne te donnera jamais rien.

 

Et si tu utilises plus de devises que la banque n'en propose, vérifies que le système de fallback currency fonctionne toujours (càd le retour à une devise acceptée par la banque si la devise choisie par l'utilisateur n'est pas compatible) !

 

 

NOTE AUX LECTEURS

il faut bien comprendre que ceci est un bricolage, qu'il n'est valable que dans certains cas.

Vous pouvez vous en inspirer, mais toute tentative de copier coller sans réfléchir n'aboutira à rien d'autre qu'à des catastrophes !

 

Merci pour cette correction. Effectivement j'ai fait un copier coller tout bête et ça reste un vieux bricolage mais qui me dépanne malgré tout. j'ai fait au mieux avec les compétences que j'ai dans ce langage.

 

A bientôt merci.

[dddd]

Bonjour,

 

J'essaie de faire fonctionner le module ATOS d'après le changelog j'ai la version version 2.1 RC 6

Je ne sais pas comment résoudre la longueur maximale de 54 caractères pour le chemin vers les fichiers de config car mon nom de domaine est long et même en mettant le dossier /param à la racine cela dépasse.

 

merci

dd

[Prestapascher]

Bonjour,

 

j'ai peut-être une demande bête mais concernant le paiement en 2/3 fois doit-on faire une demande au préalable à notre prestataire (pour moi e-transaction)?

 

Cordialement

[Agence web Cibles.fr]

Je ne sais pas comment résoudre la longueur maximale de 54 caractères pour le chemin vers les fichiers de config car mon nom de domaine est long et même en mettant le dossier /param à la racine cela dépasse.

Et avec un lien symbolique, ça ne marche pas ?

[TrogloGeek]

Bonjour,

 

J'essaie de faire fonctionner le module ATOS d'après le changelog j'ai la version version 2.1 RC 6

Je ne sais pas comment résoudre la longueur maximale de 54 caractères pour le chemin vers les fichiers de config car mon nom de domaine est long et même en mettant le dossier /param à la racine cela dépasse.

 

merci

dd

 

Bonjour, cette question fait partie des questions fréquemment posées de la documentation, la lire pourrait aider. Si vous n'avez pas les qualifications techniques requises, faites appel à votre hébergeur.

 

Bonjour,

 

j'ai peut-être une demande bête mais concernant le paiement en 2/3 fois doit-on faire une demande au préalable à notre prestataire (pour moi e-transaction)?

 

Cordialement

Seul votre fournisseur de service peut vous répondre.

Edited July 16, 2012 by TrogloGeek (see edit history)

[dddd]

Bonjour, cette question fait partie des questions fréquemment posées de la documentation, la lire pourrait aider. Si vous n'avez pas les qualifications techniques requises, faites appel à votre hébergeur.

 

Merci. j'ai lu la documentation et s'il est vrai que mon hébergeur héberge mon serveur virtuel, il ne traite pas l'arborescence des virtual hosts.

 

J'ai déplacé le dossier /param vers un autre répertoire en dehors du domaine, et je n'ai plus d'erreur.

[Uniraph]

Bonjour a tous,

Je viens de refaire mon theme en partant du theme de base prestashop et lorsque j'arrive sur la page de choix du moyen de paiement, je tombe sur:

"Aucun gabarit trouvé pour le module tgg_atos"

Ce module fonctionnais pourtant bien avant avec mon ancien theme et j'ai bien recreer le dossier "theme"/modules/tgg_atos, mais cela ne resoud pas mon problème, j'ai toujours le meme message d'erreur.

Si quelqu'un a une idée je suis preneur car cela fait maintenant 2 heures que je cherche en vain.

Merci d'avance.

 

PS: Sinon super module, je n'ai jamais été embeté avec

[julien.oliver]

Bonjour,

 

J'ai essayé d'installer (non sans mal vu mes compétences...) tgg_atos sur mon site marchand, mais j'ai une erreur 137 lorsque je teste le paiement. Qui pourrait m'aider. Ci-dessous le texte de la log....

Merci d'avance les experts ;-)

Julien.

 

TGG_ATOS DEBUG OUTPUT

array(3) {

["cmd"]=>

string(672) "/mnt/webg/d3/48/52924348/htdocs/bin/request "amount=4000" "automatic_response_url=http://www.dreambijoux.fr/boutique/modules/tgg_atos/front-ctrl/payment-autoresponse.php" "cancel_return_url=http://www.dreambijoux.fr/boutique/modules/tgg_atos/front-ctrl/payment-return.php" "capture_day=0" "capture_mode=AUTHOR_CAPTURE" "currency_code=978" "customer_id=1" "[email protected]" "customer_ip_address=88.163.56.3" "language=fr" "merchant_id=038862749811111" "normal_return_url=http://www.dreambijoux.fr/boutique/modules/tgg_atos/front-ctrl/payment-return.php" "order_id=4" "transaction_id=3" "pathfile=/mnt/webg/d3/48/52924348/htdocs/param/pathfile" 2>&1"

["status"]=>

int(137)

["system_result"]=>

string(0) ""

}

[ab2zen]

Bonjour,

J'ai pas bien compris si la 2.1 RC 7 était toujours en béta ou pas, je viens donc d'installer la 2.1 RC 6

sur ma boutique 1.4.8.2 en suivant la doc de tgg et sherlock's et tout fonctionne impec pour le moment (test et pré-prod).

Seul souci rencontré avec l'exe Atos pour générer le certificat de production qui ne fonctionne que sur win 32bits

(j'ai appelé leur support, il n'existe pas de version 64bits !), pas grave j'avais un vieux pc qui trainait.

[TrogloGeek]

Bonjour,

J'ai pas bien compris si la 2.1 RC 7 était toujours en béta ou pas, je viens donc d'installer la 2.1 RC 6

sur ma boutique 1.4.8.2 en suivant la doc de tgg et sherlock's et tout fonctionne impec pour le moment (test et pré-prod).

Seul souci rencontré avec l'exe Atos pour générer le certificat de production qui ne fonctionne que sur win 32bits

(j'ai appelé leur support, il n'existe pas de version 64bits !), pas grave j'avais un vieux pc qui trainait.

 

C'est pire que ce que vous pensez, l’exécutable windows fourni est en 16bits (donc conçu pour Windows 3.x, ça fait un baille hein ? Qui a encore un Windows 3.1 qui traîne, levez le doigt ?). Un processeur standard est capable d'exécuter en mode compatibilité des exécutables d'une largeur de bus de la moitié de celle du système d'exploitation, donc on peut encore utiliser leur vieil exécutable sur des version 32bits de windows, mais ceux-ci étant en phase d'obsolescence avancée... Personnellement, je suis obligé d'utiliser une machine virtuelle sous XP ou Windows 98 quand je veux exécuter leurs *saleté* d'archive autoextractible périmée depuis seulement 10 bonnes années... Mais après tout, une banque ça n'a pas les moyens de re-développer cela pour le mettre à jour, d'ailleurs c'est bien connu : ils sont obligés de payer leurs traders au smic... (lol)

 

Concernant le statut de la version 2.1.7 beta 2, j'aurais pensé que le

Oui, cette version est stable.

Ajouté juste sous le lien de téléchargement était assez clair, mais il faut croire que non...

Edited October 13, 2012 by TrogloGeek (see edit history)

[Morgz]

Bonjour à tous !

 

Déjà merci beaucoup pour ce module !

 

Je rencontre un petit soucis, lorsque je clique sur le bouton "retour à la boutique" après un paiement valide, je suis redirigé sur la page www.monsite.com/modules/tgg_atos/front-ctrl/payment-return.php qui est vide. Je ne reçois aucun message d'erreur par mail et la commande n'est pas prise en compte.

Est ce que quelqu'un a une idée ?

 

Pour info

Prestashop : 1.5.1

Module Atos : 2.0 RC1

Mode : test/démo

 

Merci d'avance !

Edited October 22, 2012 by Morgz (see edit history)

[TrogloGeek]

Bonjour à tous !

 

Déjà merci beaucoup pour ce module !

 

Je rencontre un petit soucis, lorsque je clique sur le bouton "retour à la boutique" après un paiement valide, je suis redirigé sur la page www.monsite.com/modules/tgg_atos/front-ctrl/payment-return.php qui est vide. Je ne reçois aucun message d'erreur par mail et la commande n'est pas prise en compte.

Est ce que quelqu'un a une idée ?

 

Pour info

Prestashop : 1.5.1

Module Atos : 2.0 RC1

Mode : test/démo

 

Merci d'avance !

 

Bonjour, la 2.0 RC1 est très sérieusement dépassée... Dans les communautés de développement libre il est d'usage de tester la dernière version avant de demander de l'aide...

Cela dit, aucune version actuelle de tgg_atos n'est compatible avec la branche 1.5.x qui nécessite un réarchitecturage en profondeur pour que le module s'intègre proprement, je n'ai pas vraiment le temps de en ce moment de faire du dèv bénévole.

La dernière version peut fonctionner à condition d'ajouter une ligne au début du constructeur du fichier de classe tgg_atos.php

public function __construct() {
 if (!defined('_USER_ID_LANG_')) define('_USER_ID_LANG_', Context::getContext()->language->id); //nouvelle ligne
 $this->name = 'tgg_atos';

Cela fonctionnera, mais ce n'est pas ce qu'il y a de plus propre, certains contextes sont obsolètes dans le code du module.

Solutions propres :

• Utiliser le module avec une version antérieure de Prestashop
  
• Utiliser un autre module Atos compatible 1.5.x (il y en a plusieurs disponibles sur Prestashop AddOns)
  
• Faire pression sur les banques utilisant Atos et/ou sur Atos Worlwide Sips pour qu'elles financent et maintiennent à jour un module gratuit en leur rapelant que l'indisponibilité d'un module gratuit propre et maintenu pour leur solution est un sacré désavantage commercial quand il s'agit de choisir sa solution bancaire.
  
• Changer de système de paiement et/ou banque
  
• Attendre que j'ai du temps et la motivation pour le portage
  
• Faire appel à un autre professionnel pour un portage (évitez les débutant tout de même pour les passerelles de paiement, pas très complexe mais une erreur peu lourdement porter à conséquence)
  
• Vous réunir à plusieurs eCommerçants et financer le portage (c'est ça aussi le développement communautaire !), ce qui coûterait moins cher à chacun qu'une licence pour le module officiel et mettrait à disponibilité de tous le module tgg_atos et toutes ses fonctionnalités en 1.5.1 (et potentiellement 1.5.x si la Team Prestashop ne nous réserve pas trop de surprise dans cette branche).
  

Edited October 22, 2012 by TrogloGeek (see edit history)

[rafal96]

bonjour , j'ai cette erreur

 

TGG_ATOS DEBUG OUTPUT

Tgg_Atos: Erreur durant l'appel de l'exécutable request

 

L'exécutable request a retourné une erreur.

 

(139):

 

pouvez vous m'aider

[TrogloGeek]

bonjour , j'ai cette erreur

 

TGG_ATOS DEBUG OUTPUT

Tgg_Atos: Erreur durant l'appel de l'exécutable request

 

L'exécutable request a retourné une erreur.

 

(139):

 

pouvez vous m'aider

je ne suis pas expert en la matière, mais puisqu'un des titres du sommaire de la documentation est : "Le mode débug indique un code de retour 139 lors de l'appel à l'un des exécutables, qu'est-ce que cela signifie ?", je suis prêt à parier que la lire peut aider (et pas forcément que cette section !)

[Ambigua]

 

public function __construct() {
 if (!defined('_USER_ID_LANG_')) define('_USER_ID_LANG_', Context::getContext()->language->id); //nouvelle ligne
 $this->name = 'tgg_atos';

Cela fonctionnera, ..

 

Salut !

 

J'ai mis le module sur la 1.5.2, modifier la ligne .. et ca marche pas

 

j'ai un:

403 forbidden

You don't have permission to access /boutique/modules/tgg_atos/front-ctrl/payment-return.php on this server.

 

j'ai verifier mes CHMOD, désinstalleé, réinstallé le module,

désintallé, supprimer le module, recharge le module

reparametrer le schilmblik..

et PAREIL !!

[TrogloGeek]

Salut !

 

J'ai mis le module sur la 1.5.2, modifier la ligne .. et ca marche pas

 

j'ai un:

403 forbidden

You don't have permission to access /boutique/modules/tgg_atos/front-ctrl/payment-return.php on this server.

 

j'ai verifier mes CHMOD, désinstalleé, réinstallé le module,

désintallé, supprimer le module, recharge le module

reparametrer le schilmblik..

et PAREIL !!

 

Bonjour, comme dit auparavant, aucune version du module n'est actuellement réellement compatible avec Prestashop 1.5.x et personne ne veut participer au financement de la refonte pour cette branche de Prestashop, donc si vous n'êtes pas techniquement capable de comprendre la manière dont fonctionne le module et Prestashop, il vaudrait sérieusement mieux pour vous que vous vous tourniez vers une solution simple et compatible avec votre instance de Prestashop et votre hébergement, cela vous évitera probablement quelques catastrophes...

Par exemple le message d'erreur que vous obtenez est très sibyllin, provient de votre hébergement et signale que vous avez très probablement un problème de droit/propriétaire sur les fichiers controleurs front du module ou les dossiers parents, ou une restriction qui pose problème dans la configuration de votre démon HTTP. Si cela vous semble flou ou totalement incompréhensible, faites appel à un professionnel (à commencer par le service technique ATOS et votre hébergeur que vous payez déjà tous deux à priori) ou du moins à quelqu'un de techniquement qualifié avant de commettre une erreur que vous regretterez plus tard.

Si vous avez les compétences techniques, pensez à jeter un petit coup d'oeil aux logs HTTPD, ils servent à cela, configurez-en la génération si ce n'est pas le cas et augmentez le niveau de verbosité s'ils ne contiennent pas les réponses à votre problème, cela devrait vous débloquer.

[Ambigua]

Salut !

 

Merci TrogoGeek de la réponse !

 

Pour le niveau, je suis pas un débutant, ni un expert ..

 

La nouvelle structure de Prestashop 1.5.2 m'a laisser un peu perplexe, mais je commence un peu a comprendre ...

 

Pour mon erreur, j'ai tenter de modifier les CHMOD de diverses facon sans succès ..

 

Ceux mis en place d'origine ( a l'installation du module) ne fonctionnent pas mieux..

 

Quels seraient les CHMOD idéaux sur ce fichier par exemple ? ( chez OVH )

[florent60]

Bonjour à tous

 

je vais faire le boulet, mais je ne trouve pas ou il faut modifier le fichier pour que le module fonctionne en 1.5 j'ai essayé plein de truc mais niet ! si quelqu'un veut bien me filer un tuyau, suis preneur merci

[TrogloGeek]

Salut !

 

Merci TrogoGeek de la réponse !

 

Pour le niveau, je suis pas un débutant, ni un expert ..

 

La nouvelle structure de Prestashop 1.5.2 m'a laisser un peu perplexe, mais je commence un peu a comprendre ...

 

Pour mon erreur, j'ai tenter de modifier les CHMOD de diverses facon sans succès ..

 

Ceux mis en place d'origine ( a l'installation du module) ne fonctionnent pas mieux..

 

Quels seraient les CHMOD idéaux sur ce fichier par exemple ? ( chez OVH )

 

Pour un fichier frontal PHP sur un mutualisé OVH normalement un mode (on parle en réalité de mode, chmod est le nom de l'utilitaire permettant de modifier rapidement le mode, contraction de change-mode) de 0700 est suffisant. Cependant sur beaucoup d'autres hébergements un 0704 ou 0705 sera nécessaire. Par pseudo-convention, on utilise généralement 0705 pour ce type de rôle de fichier.

A mon avis votre problème vient plutôt d'un droit d'exécution pour tous manquant sur un des dossiers au dessus du fichier (à priori sur le dossier du module ou front-ctrl).

[Ambigua]

SAlut !

 

J'ai tenté plein de mod de 700 a 777 et pareil !

 

en testant divers truc, j'ai vu que en commentant la ligne de paiement-return

$payment_ok = $Tgg_Atos->processResponse($Response, $Customer, $Order, $Currency, $amount, $mode);

 

en mettant un ! devant le if(!payment_ok), ca marche !

 

c'est donc la processResponse qui merde ....

[TrogloGeek]

SAlut !

 

J'ai tenté plein de mod de 700 a 777 et pareil !

 

en testant divers truc, j'ai vu que en commentant la ligne de paiement-return

$payment_ok = $Tgg_Atos->processResponse($Response, $Customer, $Order, $Currency, $amount, $mode);

 

en mettant un ! devant le if(!payment_ok), ca marche !

 

c'est donc la processResponse qui merde ....

Mauvaise interprétation, la négation de la condition du if n'empêche pas l'appel à processResponse, cela change donc juste l'aiguillage dans le if (je ne vais pas être méchant et éviter de parler du registre CS du processeur ;-)). tgg_atos::processResponse() peut retourner TRUE ou FALSE et cela est tout à fait normal. Avez-vous consulté la phpDoc du module avant de commencer à bricoler à l'aveugle ?

Plutôt que de bricoler vous perdriez moins de temps à faire un débugage pas à pas avec xdebug par exemple...

Avez-vous au forcé l'écriture des logs PHP et Apache à haut niveau de verbosité et consulté ceux générés lorsque le problème se produit ?

 

A ne pas vouloir prendre le temps de faire les choses correctement vous en perdez beaucoup plus...

[Ambigua]

...

en testant divers truc, j'ai vu que en commentant la ligne de paiement-return

$payment_ok = $Tgg_Atos->processResponse($Response, $Customer, $Order, $Currency, $amount, $mode);

J'ai précisé que je commentait //$payment_ok....

 

et donc $payment_ok devient "false" par defaut ..

d'ou le if(!$payment... ) pour faire comme si s'était true ..

[TrogloGeek]

J'ai précisé que je commentait //$payment_ok....

 

et donc $payment_ok devient "false" par defaut ..

d'ou le if(!$payment... ) pour faire comme si s'était true ..

Désolé lecture trop rapide...

Peut être un module accroché à un des hooks de confirmation de commande ou changement de statut.

Encore une fois, le meilleurs moyen d'être fixé est un débugage pas à pas.

http://xdebug.org/

[Ambigua]

Salut !

 

Bon, après deux jour de recherche.. je pense que j'ai trouvé le coupable ..

 

le .htaccess ..

il spécifiait un php version 5 ..

SetEnv PHP_VER 5

 

il faut lui dire plus précisement version 5.3

SetEnv PHP_VER 5_3

[Griffith]

Cher Troglogeek

 

Merci pour ce magnifique module. J'ai rencontré des difficultés avec la version 1.5.0.17 de prestashop, mais avec la 1.5.1 et la 2.1.7 R2 (et le tgg_atos.php enrichi de la ligne de code additionnelle), tout fonctionne bien du moins en mode test.

Edited November 16, 2012 by Griffith (see edit history)

[Griffith]

Avec la 1.5.2 ça marche bien aussi (d'ailleurs)

[gemelos]

Bonjour,

 

j ai installé le module de paiement sur presta 1.5.2, tout est fonctionnel sauf le retour a ma boutique.

 

http://maboutique.fr/e-shop/modules/tgg_atos/front-ctrl/payment-return.php

 

ca me renvoie vers la page 404 alors que ce lien est correct

 

avez vous une idée pour résoudre cela ? probleme htaccess ?

 

merci

[TrogloGeek]

Bonjour,

 

j ai installé le module de paiement sur presta 1.5.2, tout est fonctionnel sauf le retour a ma boutique.

 

http://maboutique.fr...ment-return.php

 

ca me renvoie vers la page 404 alors que ce lien est correct

 

avez vous une idée pour résoudre cela ? probleme htaccess ?

 

merci

 

Bonjour, comme indiqué plusieurs fois auparavant : la branche 2.x du module n'est pas compatible avec Prestashop 1.5...

J'ai déjà pas mal avancé sur la version 3 à venir mais il reste encore pas mal de boulot étant donné que la branche 3 est une réécriture totale du module pour l'améliorer en plus de monter son architecture sous celle de Prestashop 1.5.

[Griffith]

Cher Troglogeek

 

En effet, après des tests plus poussés, il subsiste quand même quelques incompatibilités entre le module v2.x et Prestashop 1.5.2. (Ceci dit, le module paypal déconne aussi). Les principaux problèmes sont la redirection du client vers la boutique et le passage de l'état de la commande à "payé" dans le back office). Je pense que beaucoup d'entre nous (dont moi) seront heureux d'apprendre que tu as bien avancé sur la v3. En conséquence je viens de participer à l'effort par un don de 20 euros à cette adresse :

https://www.paypal.com/fr/cgi-bin/webscr?cmd=_flow&SESSION=_nfwUlfAhtxLTtMAkYxT1jmCXHh6zOnYI1bjC2amjXQpACOwDFrLm_wfzHq&dispatch=5885d80a13c0db1f8e263663d3faee8d0b7e678a25d883d0fa72c947f193f8fd

J'espère que d'autres contributeurs en feront autant afin que l'on dispose de la v3 dans un futur proche. La qualité de ton travail le justifie amplement (à mon humble avis).

 

Cordialement

[petitbiston]

@ Griffith : super initiative / reconnaissance. Nous avons nous aussi remercier vivement Damien pour son travail, et participer avec un don

 

J'ai hâte également que la V3 sorte car j'aimerai migrer sur la version PS 1.5.2. qui est pas mal du tout

Edited November 23, 2012 by petitbiston (see edit history)

[poms32]

Bonjour !

 

Moi j'utilise ce module dpeuis un petit moment et tout fonctionne parfaitement ! juste je n'ai pas les remontés dans Google Analytics et c'est bien domage, il faut faire un paramétrage spécial pour que ça les remontes ? ou c'est le module qui ne le permet pas ?

 

merci

[Denisbourgoin]

Il en va de même en ce qui me concerne , ayant testé le module sous la 1.4 de PS , aucun soucis , les paiements sont acceptés , rien à dire à part que tout fonctionne correctement , j'ai été un peu deçu qu'au niveau de la 1.5 de PS il y ai des soucis après les paiements , les commandes ne s'enregistrent pas. Mais voyant qu'une V3 du module est en préparation je trouve ça simplement génial , je ferai aussi un don pour récompenser le travail accomplit.

 

Passez une bonne journée , au revoir.

[TrogloGeek]

Bonjour !

 

Moi j'utilise ce module dpeuis un petit moment et tout fonctionne parfaitement ! juste je n'ai pas les remontés dans Google Analytics et c'est bien domage, il faut faire un paramétrage spécial pour que ça les remontes ? ou c'est le module qui ne le permet pas ?

 

merci

 

Bonjour,

 

pour les problèmes de retour Analytics vous pouvez essayer la version 2.1.8-early1 :

http://www.capillotracteur.fr/downloads/tgg_atos-2.1.8early1.tar.gz

[Griffith]

Alors déjà pour mon problème de module paypal Mr_Paypal m'a conseillé de passer les permissions de 777 à 755 sur le module et effectivement ça marche comme ça.

 

Pour le module tgg_atos j'ai essayé la même chose (j'avais mis 777 au départ). Alors là c'est différent, la première commande s'est validée et enregistrée nickel, mais pas les suivantes (paiement non validé et commande signalée par l'icone mais non présente dans le menu commande, redirection vers history.php ok). En fait ce qui me surprend le plus c'est que ça ait marché une fois...

 

@Troglogeek : j'ai lu la doc mais je ne comprends pas bien à quel CHMOD correspondent les droits necessaires.

 

En attendant la v3 je vais aller tester la 2.1.8 early...

Edited November 29, 2012 by Griffith (see edit history)

[TrogloGeek]

Alors déjà pour mon problème de module paypal Mr_Paypal m'a conseillé de passer les permissions de 777 à 755 sur le module et effectivement ça marche comme ça.

 

Pour le module tgg_atos j'ai essayé la même chose (j'avais mis 777 au départ). Alors là c'est différent, la première commande s'est validée et enregistrée nickel, mais pas les suivantes (paiement non validé et commande signalée par l'icone mais non présente dans le menu commande, redirection vers history.php ok). En fait ce qui me surprend le plus c'est que ça ait marché une fois...

 

@Troglogeek : j'ai lu la doc mais je ne comprends pas bien à quel CHMOD correspondent les droits necessaires.

 

En attendant la v3 je vais aller tester la 2.1.8 early...

 

Les modes numériques à appliquer dépendent de différents éléments :

- utilisateur et groupe propriétaire des fichiers

- utilisateur et groupe apache pour le site

- utilisateur et groupe PHP pour le site

 

La documentation sur les droits à appliquer est faite pour être lue par le technicien d'exploitation du serveur.

 

Appliquer un CHMOD identique à tous les fichiers constitue une faille sévère de sécurité. N'appliquez JAMAIS un CHMOD de 0777 à l'aveugle (les cas dans lesquels un mode numérique de 0777 sont à appliquer sont EXTREMEMENT rares et sont généralement le signe d'un serveur mal configuré). Mr_Paypal ne sait visiblement pas de quoi il parle.

 

J'ai du mal à comprendre l'intérêt de faire des économies de bouts de chandelles en faisant faire l'installation par quelqu'un de non qualifié si c'est pour au final avoir ses paiements détournés. (Bien-sûr, en cas de détournement du paiement vous devrez honorer les commandes puisque le client a bien payé en suivant la procédure proposée par vous, il sera alors à votre charge d'attaquer le pirate en justice pour récupérer votre argent ou faire appel à votre assurance, à supposer que vous en ayez une...).

 

Si vous n'avez pas de technicien disponible et que faire appel à un technicien freelance est trop cher, prenez un hébergement avec infogérance et maintenance votre hébergeur se chargera de ces manipulations pour vous.

 

N'oubliez pas que vous serez légalement responsable de toute exposition des données personnelles de vos clients (en plus de perdre toute crédibilité et la confiance de vos clients).

 

Je vous suggère de faire un tour ici : http://www.cnil.fr/e...ctions-penales/

Il s'agit ici de peine légales à caractère générique, quand il s'agit de données bancaires on peut facilement supposer que les peines sont bien plus élevées.

 

Concernant la non validation de commande les principales pistes :

- vous êtes en 1.5.x et n'avez pas corrigé le problème des statuts de commande ou vous n'avez pas revalidé la configuration du module après correction du problème.

- vous avez supprimé le statut de commande configuré dans le module

- un module inscrit sur un hook de validation de commande ou de changement de statut a fait planter la validation (c'était l'année dernière la spécialité du module So-Colissimo, possiblement à cause d'une mauvaise configuration de l'utilisateur, j'ai vu aussi certains modules d'analyse ROI causer la même chose; il s'agit généralement d'un appel CURL ou fopen d'un fichier / service distant mettant plus de temps à répondre que la durée d’exécution allouée dans PHP ou dans le wrapper CGI).

Dans tous les cas la consultation des logs d'erreur PHP, apache et de l'éventuel wrapper CGI permet généralement d'identifier rapidement le problème.

Edited November 29, 2012 by TrogloGeek (see edit history)

[Denisbourgoin]

Que dire à part un grand MERCI TrogoGeek.

Avec la 2.1.8 le module fonctionne correctement sous versions 1.5.X de Prestashop.

Tout simplement parfait.

 

J'acheterai la 3.0 sans faute , vous méritez amplement salaire pour tout ce travail.

Passez une agréable journée , encore merci.

[TrogloGeek]

Que dire à part un grand MERCI TrogoGeek.

Avec la 2.1.8 le module fonctionne correctement sous versions 1.5.X de Prestashop.

Tout simplement parfait.

 

J'acheterai la 3.0 sans faute , vous méritez amplement salaire pour tout ce travail.

Passez une agréable journée , encore merci.

 

Bonjour,

 

la 2.1.8 se comporte effectivement mieux sous PS 1.5.x mais elle n'est pas tout à fait compatible (elle n'a pas été prévue pour), elle risque principalement de poser des problèmes sur les hooks graphiques (en-tête, colonnes gauche et droite, pied de page) si ma mémoire est bonne. Sinon je suis content qu'elle est résolu votre problème.

[Griffith]

@Troglogeek : Tout d'abord merci pour ce rappel qui a son importance. En effet je ne voudrais pas voir mes paiement détournés par le premier hacker venu.

Ceci dit bien que n'étant pas expert en administration serveur, je me doute que le CHMOD777 représente une grosse faille de sécurité. Il ne s'agit que de tests de ma part en mode démo le temps de finaliser le site.

J'ai quelqu'un qui va m'aider à configurer correctement les permissions, sinon j'avais pensé à cette solution si elle est toujours d'actualité :

 

Extrait de la doc :

"La tarball contient les droits utilisés lors du développement sur une offre mutualisée pro OVH, si

vous souhaitez les conserver extrayez directement son contenu sur le serveur (tar -xzf

nomdufichier.tar.gz)."

[Griffith]

Bon ben je crois que tout est bien configuré maintenant.... C'était pas si dur en fin de compte...