PhenixTweet

herve_02 @herve_02

3 h.

oui j'ai refait ma phrase en cours de rédaction et celui qui passe devant à changé. je m'en suis aperçu bien après (il était tard) et il n'y avait plus moyen de corriger.
maintenant j'ai accroché mon code au fameuw hook actionOrderHistoryAddAfter , mais lors d'une commande il n'est pas activé, je log dans un fichier et le code ne s'active pas.

1 jour

a répondu au Message de herve_02 il y a 1 jour

Non, il passe AVANT (regardez les IDs)

1 jour

a répondu au Message de herve_02 il y a 1 jour

étant donné qu'on est dans le même process d'ajout de statut (qui s'empilent) ajoutez un sleep(1); (1 seconde) dans votre code avant de changer le statut pour être sûr que votre enregistrement se fera la seconde suivante.

herve_02 @herve_02

2 jours

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

ps oui un seul hook...

herve_02 @herve_02

2 jours

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

et donc statistiquement impossible que ce soit du hasard dans l'ordre d'enregistrement.
On loupe un truc dans le mécanisme des hook.
Mais je suis un noob.(pour le moment). Disons un noob niveau 2.

herve_02 @herve_02

2 jours

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

ou alors il s'écrit __après__ (mais en même temps dans le cache à la même date_time ) MAIS le fait d'avoir un date_time en secondes plutôt qu'un timestamp en milliseconde(et donc les deux sont 'en même temps') fait que mariadb ne sait pas dans quel ordre le mettre et poufff pas de bol ???
Ou alors je délire... (ce qui est bien possible - faire de l'objet dans un monde deconnecté est un poil schizophrène.
Mais en même temps commande enregistrée (bien qu'au même date_time) est enregistré avant (logique)
je suis perdu.
Et c'est _tout le temps_ dans l'autre sens, .../...

herve_02 @herve_02

2 jours

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

Peut être (c'est une figure de style) que je ne comprends pas la philosophie phenix/prestashop1.6
Et comme prestashop est un empilement de modifications/ajouts pendant presque 20 ans...
Il y a 2 fois la même requête pour chaque page chez moi si je trace le contoleur produit il "spits" 2 fois sur une page produit. (peut être ma faute) et le système de module, plutôt que de modifier les requêtes (la maniere "simple", mais overrride et donc diversion et donc perte des écolutions) écrit une requête supplémentaire. le curseur entre facilité de faire modules et performance.

herve_02 @herve_02

2 jours

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

Mais en même temps, je ne suis pas assez (pas du tout pour le moment) expert de phenix peut être qu'il y a une sorte de queue d'instructions (des objets, dans des objets, dans des objets, un truc entre genre sql et sql_slave) (il y a au moins 4 requêtes de recherche (elles même partagées en 3 ou 4 chemins de requêtes, ajax pas ajax,requete directe puis requête par pondération des mots - une sorte d'enfer Et la requête par ref (super intelligent ad-on eola) : produit, recherche, catégorie, fournisseurs) et peut être que lorsque les requêtes remontent dans les objets, il y a une race condition.

herve_02 @herve_02

2 jours

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

oui dans la table le statut 32 (le mien) pass après le statut 2 (statut paiement accepté)
53351 | 0 | 22325 | 2 | 2026-09-29 15:52:59

53350 | 0 | 22325 | 32 | 2026-09-29 15:52:59 |

J'aurais tendance à suspecter une sorte de "cache" des instructions update mariadb qui "flush"(ent) à un moment et comme les 2 instructions arrivent "au même moment" (suivant la granularité de l'interface de "vidage" du cache

herve_02 @herve_02

2 jours

a répondu au Message de Eolia - 2 jours

j'ai bien réalisé que ce n'était pas logique puisque mon code se place _après_ le changement en payé. mais il y a peut être un décallage entre le changement d'état et l'écriture de l'historique. et ce que j'écris se place juste entre les deux.
peut être que ce n'est pas le bon hook.
il manque vraiment un carte géographique des hook dans un processus complet de navigation. quand j'aurais le temps (en 2090) je me lancerais bien dans un truc comme ça, genre un poster A2 avec les enchainements de tout les hook.
D'ailleurs cela faisait pareil avec mon premier code sur hookActionOrderStatusUpda

2 jours

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

Ben ce n'est pas logique alors.
Dans la table ps_order_history votre statut est enregistré avant l'autre ?

herve_02 @herve_02

2 jours

Ce qu'il manque : un shéma complet de la base de donnée (j'avais commencé un bout au tout début, je dois avoi qqpart un fichier .svg.
ET une doc avec tous les hooks et les ordres de passages et "objects" concernés. même le livre de j'avais acheté est plus une sorte de cookbook que de la documentation.
Maintenant les programmeurs on a tendance à dire qu'il suffit de lire le code, mais du coup le ticket d'entré est compliqué surtout avec les objets et les enfers des héritages (et des overrides par dessus le tout.
Et je ne parle pas de l'enfer des modules, chacun réécrivant ce qui lui plait.

herve_02 @herve_02

2 jours

a répondu au Message de Eolia - 2 jours

$history = new OrderHistory();
$history->id_order = (int) $order->id;
$history->changeIdOrderState(
Configuration::get('FORMO_LIVRE_PDF_ID'),
(int) $order->id
);

$history->addWithemail(true);

2 jours

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

Vous passez l'history comment ?
Et vous avez bien désactivé l'autre hook ?

2 jours

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

un d($params); dans le hook vous donnera ce qu'il contient (à utiliser dans un environnement de test, pas en prod !)

herve_02 @herve_02

2 jours

a répondu au Message de Eolia - 2 jours

Ca fait la même chose. l'history que je donne passe avant l'history originale....

Il doit y avoir une sorte de race condition, peut être un cache ? car cela passe à la même seconde...

herve_02 @herve_02

2 jours

a répondu au Message de Eolia - 2 jours

merci, je ne suis pas encore super a l'aise avec les objets phenix et lorsque je lis les classes je n'arrive pas toujours à voir "facilement" qui donne quoi.

2 jours

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

Dans l'objet $order_history vous avez l'id_order donc à partir de là,
$order = new Order($order_history->id_order);
$order->getProducts(); vous donnera la liste des produits de la commande.

herve_02 @herve_02

2 jours

a répondu au Message de Eolia - 2 jours

Mais du coup je n'ai plus accès a la commande avec son panier

3 jours

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

Ah ok. C'est normal car le statut n'a pas encore été enregistré, c'est la fonction OrderHistory::addWithemail() qui l'enregistre et elle est appliquée après.
Dans ce cas, préférez le hook

CODE
        Hook::exec('actionOrderHistoryAddAfter', 
            array('order_history' => $this), 
            null, false, true, false, $order->id_shop
        );

qui se déclenche après l'enregistrement du statut en cours.

herve_02 @herve_02

3 jours

a répondu au Message de Eolia - 3 jours

dans l'historique (et en fait dans le statut du coup)

3 jours

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

il l'écrit où ???

herve_02 @herve_02

3 jours

a répondu au Message de Eolia - 3 jours

ok, j'ai fait le changement, mais pourquoi phenix ecrit paiment confirmé __après__ mon statut ? alors que mon statut se déclenche après la confirmation ?

5 jours

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

Normal ces 2 hooks n'ont pas du tout le même contenu dans $params.
Vous devriez utiliser le hook actionPaymentConfirmation qui se déclenche justement sur ces 2 statuts. ses paramètres sont:

CODE
        if(in_array($new_os->id, array(
            Configuration::get('PS_OS_PAYMENT'), 
            Configuration::get('PS_OS_WS_PAYMENT')))
        ) {
            Hook::exec('actionPaymentConfirmation', 
                array('id_order' => (int)$order->id), 
                null, false, true, false, $order->id_shop
            );
        }

herve_02 @herve_02

5 jours

J'ai essayé de contruire un micro module pour changer le statut lorsque des conditions sont atteintes. Cela fonctionne lorsque tout se passe dans un transit "autonome" (le client paye en ligne)
mais cela ne fonctionne pas lorsque je change de statut à la main en BO.
est-ce que j'ai loupé un truc ?

changement_statut.txt

9 jours

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

Paramètres avancés => Performances et sécurité

herve_02 @herve_02

9 jours

où on peut voir ces ip bannies ? et ou sont elles stockées pour pouvoir les supprimer si jamais l'admin est bannie et ne peut plus se connecter.

10 jours

a répondu au Message de nelson - 10 jours

zut je dérange pour rien je vais remonter les messages du coup

10 jours

a répondu au Message de chris il y a 10 jours

Oui cela m'arrive aussi, même en tant qu'admin.
Eolia m'a dit que ce serait corrigé dans la v47.

En attendant, Eolia m'a dit que l'on peut commenter/supprimer ce bloc dans /classes/FrontController.php:

10 jours

Bonjour à tous, j'ai eu un souci semaine dernière deux anciens clients me disaient ne plus pouvoir accéder à mon site, en regardant de plus près leurs adresses IP étaient bannies, j'ai désactivé "activer la protection contre les attaques". Ça m'embête un peu mais pas le choix quelqu'un a une piste ? A savoir que l'un des deux clients je lui avais enlever son adresse une première fois mais elle a été de nouveau bannie....