PhenixTweet

5 horas atrás

En respuesta herve_02 a su Publicación 5 horas atrás

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

5 horas atrás

En respuesta Eolia a su Publicación 5 horas atrás

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

12 horas atrás

En respuesta herve_02 a su Publicación 12 horas atrás

il l'écrit où ???

herve_02 @herve_02

12 horas atrás

En respuesta Eolia a su Publicación 12 horas atrás

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 ?

2 dias atrás

En respuesta herve_02 a su Publicación 2 dias atrás

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

2 dias atrás

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

6 dias atrás

En respuesta herve_02 a su Publicación 6 dias atrás

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

herve_02 @herve_02

6 dias atrás

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.

7 dias atrás

En respuesta nelson a su Publicación 7 dias atrás

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

7 dias atrás

En respuesta chris a ella Publicación 7 dias atrás

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:

7 dias atrás

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

8 dias atrás

En respuesta Eolia a su Publicación 8 dias atrás

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.

8 dias atrás

En respuesta Eolia a su Publicación 8 dias atrás

Encore une fois , ce n'est pas important , j'ai bien d'autres choses à faire sur la boutique.

8 dias atrás

En respuesta eric a su Publicación 8 dias atrás

Bah ce n'est pas logique. L'erreur dit qu'on ne peut pas affecter une valeur à un array qui n'existe pas et ma ligne, ajoutée avant dit que si ce n'est pas un array, on ne fait rien (continue)

8 dias atrás

En respuesta Eolia a su Publicación 8 dias atrás

oui pour la ligne dans le fichier HelperList et non , je n'avais pas vidé le cache mais j'ai retesté après vidage --> idem

8 dias atrás

En respuesta eric a su Publicación 8 dias atrás

vous avez bien fait la modif dans /classes/helper/helperlist.php et vidé le cache ???

8 dias atrás

En respuesta Eolia a su Publicación 8 dias atrás

bon , non toujours la même erreur en boutique test après modif , ceci dit , ce n'est pas très important , ne vous embêtez pas avec ça . Merci

9 dias atrás

En respuesta eric a su Publicación 9 dias atrás

Juste avant la ligne 742 ajoutez ceci:

CODE

            if(!is_array($params)) {
                continue;
            }

9 dias atrás

En respuesta Eolia a su Publicación 9 dias atrás

sur la boutique de test en local , debian 13 avec php 8.2.33 , j'ai ceci dans /var/log/phenix juste après un export

9 dias atrás

En respuesta eric a su Publicación 9 dias atrás

L'export est en csv.
Que dit votre error.log sur votre serveur ?

9 dias atrás

bonjour , quel est le format/extension de fichier lors d'un export du catalogue en BO car aussi bien sur la boutique de prod que celle de test , c'est erreur 500 direct , avec le débug sur la boutique test , il ouvre atril qui est mon lecteur de pdf par défaut mais le message de atril c'est qu'il ne prend pas en charge le text/plain donc je suis un peu sec là...

9 dias atrás

En respuesta herve_02 a su Publicación 9 dias atrás

C'est la page de base, vous pouvez virer cette ligne.

herve_02 @herve_02

9 dias atrás

En respuesta Eolia a su Publicación 9 dias atrás

oiui après avoir tourner en rond pendant plus d'une journée, je viens de realiser, en relisant le tmp
{extends file='page.tpl'}

le cerveau ne suit plus les mains

Je supose que c'est une m*rde 1.7...

9 dias atrás

En respuesta herve_02 a su Publicación 9 dias atrás

file:page.tpl ? Il n'y aurait pas des includes dans ce fichier tpl ?

herve_02 @herve_02

9 dias atrás

En respuesta Eolia a su Publicación 9 dias atrás

je crois que je vais jeter à la poubelle le truc... s'il trouve bien le fichie template il m'insulte
Fatal error: Uncaught --> Smarty: Default handler: No template default content for 'file:page.tpl' -- thrown in /var/www/phenix/tools/smarty/sysplugins/smarty_internal_method_registerdefaulttemplatehandler.php on line 83

10 dias atrás

En respuesta herve_02 a su Publicación 10 dias atrás

Non, il faut le remplacer par:
$this->setTemplate($this->_path.'views/templates/front/fichier.tpl');

ou
$this->setTemplate($this->module->getLocalPath().'views/templates/front/fichier.tpl'); si vous êtes dans un contrôleur

10 dias atrás

En respuesta herve_02 a su Publicación 10 dias atrás

Hum Context::getTranslator() c'est du 1.7 pas du 1.6 donc à remplacer par
$this->l('votre trad'); ou écrit autrement suivant le fichier où vous êtes dans votre module

herve_02 @herve_02

10 dias atrás

j'ai fait un "juste return" dans les 2 fonctions impactées, on verra à l'usage. Mais là je suis perplexe, il appel son template
$this->setTemplate('module:le_module/views/templates/front/fichier.tpl');

et cela plante. J'ai bien essayé de passer
return $this->display(__FILE__, 'mon.tpl'); mais cela affiche "en double" du coup

herve_02 @herve_02

10 dias atrás

bonjour les phenixciens.

j'ai téléchargé un vieux truc prévu normalement pour prestashop 1.6 mais il y a des trucs qui n'existent pas/plus
Call to undefined method Context::getTranslator()
avant de tailler dans la bête à la serpe rouillée, je me demande si vous aviez un avis la dessus ?

11 dias atrás

La V47 est en phase finale (tests et debug) 😊