Vais m’abstenir de rouler cette semaine, je pense, pas la peine que je risque une glissade sur un sol potentiellement gelé vu qu’il n’est (pour l’instant) franchement pas très sec et que les températures sont pas loin du zéro, surtout en petite banlieue où je me rends.
Et puis j’ai une vis dans le pneu arrière, qu’il va falloir que je dévisse doucement pour voir si ça vaut une réparation, un remplacement, voire rien du tout si la vis est franchement petite…
Sinon je me casse la tête depuis pour comprendre pourquoi la session PHP n’est pas toujours synchronisée dans la base sur un changement de page. Le scénario est le suivant et est reproductible, en tout cas en local sur mon Mac :
- Création nouveau billet, titre et contenu bidon puis validation → on revient sur la page d’édition, normalement, avec une notice qui indique que le billet a bien été créé.
- Suppression du-dit billet avec le bouton idoine en bas du formulaire et validation du message de confirmation → on revient à la liste des billets avec une notice qui indique encore que le billet a bien été créé !
Et c’est bien la même notification, horodatée de manière identique.
J’ai un peu tracé ce que je pouvais, la variable globale $_SESSION qui contient la liste des notices à afficher est bien « dépilée » de la notice affichée à la création du billet (au moment de l’affichage de la page d’édition du billet nouvellement créé), par contre pas de synchronisation dans la base quand je lance la suppression avec retour ensuite vers la liste des billets, comme si la session n’était pas écrite et fermée au moment de la redirection, alors que d’après le code, elle l’est — il y a un session_write_close() juste avant la redirection côté Clearbricks :
public static function redirect($page)
{
…
# Close session if exists
if (session_id()) {
session_write_close();
}
header('Location: '.$redir);
exit;
}J’avoue en perdre un peu latin !
D’ailleurs si quelqu’un a une idée du pourquoi du comment ? Mais en même temps, qui parmi mes lecteurs fait encore du PHP, à part un ou deux ? Pas que ce bug soit gênant, mais c’est un poil agaçant d’avoir des messages d’information répétés, quant il ne sont pas doublés…
1 De JcDenis -
J’avoue que ce bug a tendance à m’énerver, j’y ai jeté un coup d’œil, et à plusieurs reprises, sans succès. Pourtant ça doit pas être grand chose…
Et sinon, avec des pneus cloutés, tu peux prendre la route sans peur :p
2 De Pep -
2 pistes, mais vraiment à la louche :
Sorti de ça, c’est le flou total pour moi.
Mais c’est normal, hein… ;-)
3 De Franck -
Et bien sûr, ce que j’ai oublié de mentionner, c’est qu’en mettant des breakpoints et en suivant le code à la trace… tout se passe à merveille, sinon ça serait trop simple !
4 De Nicolas -
Je n’arrive pas à reproduire ton scénario. J’ai testé sur la version courante et sur la version de développement. J’ai raté quelque chose ?
J’ai le premier message “billet créé” mais je n’ai pas de message lorsque je supprime le billet : ni message de création comme toi, ni message de suppression
5 De Franck -
Nicolas PostrgreSQL ou MySQL ? Je pense qu’il y a une piste de ce côté…
6 De Nicolas -
J’y ai pensé aussi mais j’ai testé avec les deux et ça ne change rien. Enfin ce n’est pas mysql mais mariadb.
7 De Franck -
Ok. D’ailleurs ici-même c’est mariaDB qui tourne derrière et je n’ai pas non plus ce problème, c’est assez étrange ; pour tout dire je soupçonne une optimisation côté base de données qui, dans certains cas, est contre-productive, ce qui serait conforté par mes expériences quand je place des points-d’arrêt, ce qui laisse le temps au moteur derrière de faire ce qu’il a à faire côté base de données…
Mais ce n’est qu’une supposition.
8 De saymonz -
En faisant le test sur mon installation de production (php-fpm + nginx + mariadb sur archlinux à jour, dotclear à jour) :
- j’ai bien la notice de création du billet
- aucune notice lors de la suppression depuis la page d’édition
- notice normale si suppression depuis la liste des billets
Si ça peut aider.
9 De Franck -
saymonz ça confirme mes tests (ubuntu/apache/php-fpm/mariadb)