PhenixTweet

9 h.

a répondu au Message de Atchworks - 9 h.

Je teste avec un navigateur pas trop vieux (mais un linux quand même :-)). Cela ne le fait pas sur toutes les pages. Il doit trainer un bug quelque part.

MrR @mrr

11 h.

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

Oui, j’ai rencontré un cas un peu similaire il y a quelques jours.

Un client a réussi à passer commande en utilisant un code promo qui avait expiré en décembre 2025.

En regardant de plus près, je me suis aperçu que son panier avait effectivement été créé avant cette date, mais que la commande n’avait été finalisée que récemment.

Ce code promo avait carrément été supprimé du BO en janvier 2026 !

Il semblerait donc que certaines informations enregistrées dans un ancien panier puissent rester actives au moment de sa validation, même si les paramètres de la boutique ont changé entre-te

Eolia @eolia

13 h.

a répondu au Message de yoyo64 - 13 h.

Regardez l'error.log de votre serveur pour en savoir plus sur l'erreur.

Atchworks @atchworks

13 h.

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

J'ai constaté la meme chose. Mais pour la meme page, selon le navigateur, c'est un click ou 2 clicks.
J'ai un vieux PC avec un vieux firefox = 2 clicks
PC W11 avec Firefox à jour = 1 click

Pilou @pilou

13 h.

Bonjour,
Phenix .48
En Php 8.2 et supérieur, l'affichage en front d'un article en promo beugue. Le prix promo s'affiche une seconde puis revient au prix normal.
Je suis repassé en Php 8.1, plus de soucis.

BigM @bigm

22 h.

a répondu au Message de Eolia - 22 h.

Merci pour l'indication. Des recherches ont montré que le client avait créé le panier le 13 octobre sur son smartphone sans commander. Le 27 octobre, le panier a été commandé directement sur le téléphone (je suppose que la page n'a jamais été fermée). J'ai retiré l'article du site le 19 octobre, le stock étant à 0.

BigM @bigm

22 h.

a répondu au Message de Tanguy JACQUET - 22 h.

Merci pour la remarque concernant les paniers. Cela permet de réduire considérablement le problème, mais ne le résout pas entièrement, car il faudrait théoriquement vider les paniers chaque jour ou encore plus rapidement. Je sais que les cas sont rares (en repensant à ces dernières années, je ne me souviens que d'un autre cas de commande mystérieuse d'un article en rupture de stock), mais cela pourrait poser problème pour l'un ou l'autre.

yoyo64 @yoyo64

23 h.

bonjour jai un problème impossible de réinstaller mon module jai
Temps de chargement 0.874s
PhenixTweet / Bug Tracker / Forum - PhenixSuite©
500 Server Error

Oops, something went wrong.

Try to refresh this page or feel free to contact us if the problem persists.

herve_02 @herve_02

1 jour

a répondu au Message de Eolia - 1 jour

Je regarderais, mais cela ne semble pas aussi simple. les liens sont formés dans paginaltion.tpl href="{$link->goPage($requestPage, $pages_nb)
et le paramètre p=2 est bien dans le lien. il est bien respecté dans le 1er passage (si on log la requete) mais disparait dans le 2ème passage (celui qui affiche la page) . la classe est appelée 2 fois. sur un seuk click en front office
Il me semble ne pas être en ajax.

Eolia @eolia

1 jour

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

history.back est vidé par défaut dans le BO pour éviter les erreurs ajax ou repostage involontaire de formulaires.

Pour votre pagination, à priori les liens a ne sont pas chargés au départ sur les 2 premières pages. Si cela peut vous aider recherchez "setPagination" dans le module productcomments pour vous donner une idée de la mise en œuvre d'une pagination en ajax.

herve_02 @herve_02

1 jour

J'ai un problème. J'ai l'impression que phenix "double" les (certaines) pages. Par exemple lorsque je suis sur le back-office et que je veux revenir à la page précédente (oui je sais c'est mal) il faut 2 clics back.
Maintenant dans mon module de recherche) en local (pas encore en production du coup lorsque je click sur la page 2 ($p=2) d'une recherche (theme default-bootstrap-enfant) il demande 2 fois la page et perds des paramètres en cours de route. Mais cela ne le fait pas à la page 3. Cela le fait aussi pour la page 1.
Je me demande ou je m*rde

j'utilise les smarts url

Eolia @eolia

1 jour

a répondu au Message de BigM - 1 jour

C'est possible si le client s'est arrêté à la page de paiement et a conservé son onglet ouvert sans rafraichir et a directement lancé le module de paiement.

Eolia @eolia

1 jour

a répondu au Message de Tanguy JACQUET - 1 jour

L'option de nettoyage des paniers est native dans PhenixSuite 😊

Tanguy JACQUET @mediacom87

1 jour

a répondu au Message de BigM - 1 jour

Bonjour,
Certains m'ont expliqué utiliser mon module de nettoyage de base de données sur les paniers sur des délais d'une semaine pour justement éviter ce genre de cas. Je ne me souviens plus quelles versions de PrestaShop ils utilisaient, mais cela peut, à défaut de corriger le problème, en minimiser les effets.
https://www.prestatoolbox....

BigM @bigm

1 jour

v.46

Je viens de recevoir une commande contenant un article dont le stock était à 0 et qui est hors ligne depuis une semaine. De plus, les paramètres de la boutique prévoient par défaut de rejeter les commandes en rupture de stock.

Remarque rapide : le panier avait déjà été créé il y a environ un mois (mais la commande n'a été validée que maintenant).

Est-ce que quelqu'un a déjà vécu ou vu quelque chose de similaire ?

Tanguy JACQUET @mediacom87

2 jours

Merci à @Pilou pour son retour de bug sur mon module d'analyse de serveur sur PhenixSuite que je viens de corriger dans la version 3.0.1 de mon module dont je parle pour analyser les serveurs et vérifier que la mise à jour de PHP fut faite : https://www.mediacom87.fr/...

Faille PHP octobre 2026 : vérifier le correctif PrestaShop

Deux failles critiques PHP menacent les sites web. Découvrez comment vérifier les correctifs de votre serveur PrestaShop avec notre module gratuit.

https://www.mediacom87.fr/faille-php-octobre-2026-verifier-correctif-prestashop/

Eolia @eolia

2 jours

@yoyo64 :
Vous ne devez pas avoir vu mon message:

Remplacez la ligne 1492 de /classes/Tools.php par celle-ci:

$file = Module::CACHE_FILE_DEFAULT_COUNTRY_MODULES_LIST;

Votre serveur continue d'envoyer des requêtes toutes les 5 secondes

Eolia @eolia

2 jours

a répondu au Message de Abo - 2 jours

Avez-vous désactivé les notifications dans le BO ?

yoyo64 @yoyo64

3 jours

a répondu au Message de Eolia - 3 jours

ok je vais voir

Eolia @eolia

3 jours

a répondu au Message de yoyo64 - 3 jours

Donc vous avez un module qui utilise la mauvaise fonction de traduction dans l'un de ses controleurs.

Si vous voulez savoir lequel ajoutez ce debug à la ligne 156:

CODE
if($source === null) {p($string);d($module);}

yoyo64 @yoyo64

3 jours

hello je suis passé en php 8.3
jai Unknown error à la ligne 223 du fichier /home/site4265/web/www/classes/Translate.php
[8192] substr(): Passing null to parameter #1 ($string) of type string is deprecated

Eolia @eolia

3 jours

a répondu au Message de Abo - 3 jours

Connection smartphone, votre IP change régulièrement ?
Si vous avez l'entrée PS_COOKIE_CHECKIP dans la table configuration, supprimez-la.
Autrement c'est peut-être une sécurité de votre navigateur.

Abo @abo

4 jours

je suis très souvent déco du BO (clic sur un menu, une commande...) même en cochant la case "rester connecter" (qui se décoche à chaque fois). QQ a déjà eu le soucis ?
1.6.2.48 + php 8.4, pas de module particulier en BO, connexion partagée smartphone depuis chez moi

Abo @abo

5 jours

Bonjour ! "Juste" un merci en passant pour PhenixSuite, MaJ depuis un presta 1.6 hier vers php 8.4 et tout s'est passé nickel. Merci pour le taff de dev :)

chris @chris

5 jours

a répondu au Message de nelson - 5 jours

Merci !

nelson @nelson

6 jours

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

OVH a installé patch officiel à partir de 7.4 oui

chris @chris

6 jours

a répondu au Message de nelson - 6 jours

Bonjour, et pour un serveur dédié en PHP 7.4 chez ovh svp ?

Pilou @pilou

6 jours

a répondu au Message de Eolia - 6 jours

Merci beaucoup Eolia !

BigM @bigm

6 jours

a répondu au Message de Eolia - 6 jours

In this case, please check and, if necessary change, the CustomerMessage.php of the actual version because at least in v.46 it is 'validate' => 'isMessage'

Eolia @eolia

6 jours

Ca chauffe dans les services admin server^^

La cellule Sûreté m'a appelé ce matin à 6h12.

« Patchons immédiatement tous les serveurs PHP. »

J'ai demandé ce qui s'était passé.

« Deux vulnérabilités critiques. Exécution de code à distance. Aucune authentification requise. »

Génial.

Combien de serveurs PHP avons-nous ?

Selon l'inventaire : 12

Selon la réalité :

Personne ne le sait.

Nous en avons trouvé un qui fait tourner WordPress.

Trois qui gèrent d'anciens outils internes.

Un sous le bureau de quelqu'un.

Deux dans des appareils de fournisseurs.

Un répertoire d'employés oublié de 2016.

Et un serveur nommé :

PHP-OLD-DO-NOT-TOUCH

Bien sûr, c'est celui qui gère la paie.

Ensuite, nous avons trouvé une machine PHP-5.6.

J'ai demandé à qui elle appartenait.

La documentation indiquait :

BRIAN.

Brian est parti en 2019.

Nous avons appelé Brian.

Il a dit :

« Oh putain, il tourne encore ? »

Excellent.

À 8 heures du matin, la direction a rejoint l'appel d'incident.

PDG :

« Les hackers peuvent vraiment entrer ? »

Sûreté :

« Potentiellement oui. »

PDG :

« Sans mot de passe ? »

Sûreté :

« Oui. »

PDG :

« Pourquoi on a besoin de MOTS DE PASSE, nous, alors ? »

Belle leçon.

Le département financier a demandé si on ne pouvait pas attendre le week-end pour appliquer les correctifs, parce que les pannes affectent le chiffre d'affaires.

La cellule Sûreté a expliqué que l'alternative consistait à laisser des étrangers exécuter du code sur nos serveurs.

Le département financier a exigé un comparatif des coûts.

À 9h17, quelqu'un a proposé de mettre temporairement hors ligne les sites vulnérables.

Le marketing a refusé.

« Notre campagne est en direct. »

Donc, l'entreprise a officiellement décidé dans l'heure suivante que le maintien d'une landing page pour 20 % de réduction sur les inscriptions aux webinaires était plus important que la prévention d'une prise de contrôle à distance des serveurs.

Nous avons finalement patché tout ce que nous avons pu trouver.

Puis notre scanner a détecté un autre serveur PHP.

Nom d'hôte :

TEMP-PHP-2014

Durée de fonctionnement :

4 512 jours.

Personne ne sait ce qu'il fait.

Personne ne le possède.

Personne ne peut l'éteindre.

Mais à chaque fois qu'on bloque l'accès réseau, l'entrepôt arrête d'imprimer les étiquettes d'expédition.

La cellule Sûreté l'a classé comme infrastructure critique.

Il tourne sous PHP 5.4.

La vulnérabilité existe depuis plus longtemps que la moitié de nos employés.

Le correctif d'urgence a pris quatre heures.

Comprendre ce que PHP fait vraiment a pris onze heures.

Internet n'est pas tenu ensemble par du code.

Il est tenu ensemble par des serveurs que tout le monde a peur d'éteindre.

S'identifier

Faille PHP octobre 2026 : vérifier le correctif PrestaShop