PhenixTweet

17 ore fa

In risposta herve_02 al loro Pubblicazione 17 ore fa

Non, il passe AVANT (regardez les IDs)

17 ore fa

In risposta herve_02 al loro Pubblicazione 17 ore fa

é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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

ps oui un seul hook...

herve_02 @herve_02

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta Eolia al suo Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

herve_02 @herve_02

1 giorno fa

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

1 giorno fa

In risposta Eolia al suo Pubblicazione 1 giorno fa

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

$history->addWithemail(true);

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta herve_02 al loro Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta Eolia al suo Pubblicazione 1 giorno fa

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

1 giorno fa

In risposta Eolia al suo Pubblicazione 1 giorno fa

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 giorni fa

In risposta herve_02 al loro Pubblicazione 2 giorni fa

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 giorni fa

In risposta Eolia al suo Pubblicazione 2 giorni fa

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

2 giorni fa

In risposta herve_02 al loro Pubblicazione 2 giorni fa

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

2 giorni fa

In risposta Eolia al suo Pubblicazione 2 giorni fa

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

3 giorni fa

In risposta herve_02 al loro Pubblicazione 3 giorni fa

il l'écrit où ???

herve_02 @herve_02

3 giorni fa

In risposta Eolia al suo Pubblicazione 3 giorni fa

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 ?

4 giorni fa

In risposta herve_02 al loro Pubblicazione 4 giorni fa

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

4 giorni fa

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 giorni fa

In risposta herve_02 al loro Pubblicazione 9 giorni fa

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

herve_02 @herve_02

9 giorni fa

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 giorni fa

In risposta nelson al suo Pubblicazione 10 giorni fa

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

10 giorni fa

In risposta chris a lei Pubblicazione 10 giorni fa

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 giorni fa

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....

10 giorni fa

In risposta Eolia al suo Pubblicazione 10 giorni fa

bon , finalement votre modif fonctionne , ce qui ne marche pas depuis le début , c'est l'ouverture du fichier mais ils ont bien été générés.