Topic fantôme (reloaded) - Page 1

Bon alors c'est remarquable, j'ai découvert le moyen de reproduire un bug en tapant le post qui décrivait les conséquences du bug

Ce topic apparaît dans "Derniers sujets publics actifs non suivis", ainsi que dans la listes des topics du forum matériel info, mais donne une erreur 404 quand on essaie de le lire :
topics/187782/0#post-0

En tapant ce post, j'ai validé par erreur l'envoi du formulaire alors qu'il n'y avait que le champ Sujet rempli. J'ai bien eu un message d'erreur disant que le texte du post était trop court, mais ça a créé un topic quand même, et il est inaccessible de la même façon :
topics/187783-topic-fantome

L'autre topic inaccessible a pour titre "*", touche qui est juste à côté d'Entrée, donc j'imagine qu'il est arrivé la même chose à celui ou celle qui l'a posté.
EDIT : apparemment c'est Folco, lui aussi a des gros doigts ^^

Ah oui, pas cool, il manque un équivalent de transaction ici (yN utilise toujours myisam donc c'est un peu du bricolage). Je viens de corriger avec un bout de sparadrap, j'essaierai de trouver plus propre

Merci

ghost in the topic reloaded

Je ne sais pas si c'est le retour du même bug, mais ça y ressemble :
topics/188513-rgc-2017-ventes-fei/0#post-0
topics/188514-rgc-2017-ventes-fei/0#post-0
topics/188515-rgc-2017-ventes-fei/0#post-0
topics/188516-rgc-2017-ventes-fei/0#post-0

Ces 4 topics sont visibles dans ce forum, mais donnent une erreur 404 quand on clique dessus.

D'après les logs, le serveur MySQL est mort chaque fois au moment de sauvegarder le message, juste après avoir sauvegardé le sujet. Je suppose que le temps écoulé entre les deux était trop long et que le serveur est assez susceptible, mais comme c'est à nouveau un paramètre sur lequel je n'ai pas la main, je ne peux pas faire grand-chose :/

La seule suggestion que j'ai pour les gens qui veulent créer un sujet avec des messages un peu riches, c'est de poster dans un premier temps avec très peu de contenu puis d'éditer ensuite. C'est moche, mais sans avoir un serveur MySQL plus performant je n'ai pas beaucoup mieux à proposer.

Merci d'avoir regardé

Je viens d'ajouter un peu plus de logs pour mieux comprendre ce qu'il se passe quand ce problème se produit, mais je viens également de vérifier et Infomaniak désactive volontairement toutes les options de reconnexion automatique de MySQL (et n'autorise pas leur changement), donc ça n'est pas tellement étonnant que ça arrive de temps à autres quand une page met un moment à s'afficher :/

Si (ou plutôt quand) ça arrive encore, prévenez-moi et je regarderai si je trouve d'autres informations utiles, on sait jamais.

Tu peux pas en JS couper un post en deux si trop long et le poster en deux fois?

Ça risque de demander beaucoup de boulot pour un cas qui ne se présente que rarement, non ?

Je sais pas c'est juste une idée

Hmm bof : ça voudrait dire remonter côté client quelque chose qui se produit côté serveur (une déconnexion SQL), or le client ne pourra pas y faire grand chose de plus que le serveur. Par ailleurs ça veut dire ajouter du JS pour poser des messages, ce que j'évite de faire à moins que ça n'apporte un avantage qui contrebalance cette dépendance supplémentaire.

La seule solution que je vois serait d'implémenter la reconnexion SQL automatique à la main, pour palier au fait qu'Infomaniak n'autorise pas cette fonction, mais c'est quand même particulièrement idiot de devoir coder ce genre de chose (et probablement moins fiable que l'équivalent builtin) :/

Zeph (./6) :
La seule suggestion que j'ai pour les gens qui veulent créer un sujet avec des messages un peu riches, c'est de poster dans un premier temps avec très peu de contenu puis d'éditer ensuite. C'est moche, mais sans avoir un serveur MySQL plus performant je n'ai pas beaucoup mieux à proposer.

C'est ce que j'ai fait. Ça ne marchait pas, même en coupant la moitié du contenu...
D'ailleurs, j'ai même copié-collé à partir d'un post identique sur une autre partie du forum et ça ne voulait pas non plus...

J'ai retravaillé toutes les photos pour qu'elles soient plus petites, et ça a marché.

Merci en tout cas d'avoir regardé.

En effet les grosses images ralentissent fortement l'envoi de messages puisque yN doit les télécharger pour vérifier qu'elles sont valides et obtenir leur dimensions. Je pourrais mettre une limite plus basse, mais ça rendrait impossible d'afficher des images de grandes tailles, c'est dommage aussi :/

Le téléchargement des différentes images est-il séquentiel ?

Si je t'avoue que yAronet est codé en PHP, tu peux en déduire la réponse ?

Est-ce qu'il n'y a pas un module qui ne téléchargerait que le début des images ? Pour récupérer la taille, on n'a pas besoin du fichier complet. On perdrait la détection des images corrompues, mais je ne pense pas que ce soit un cas si courant que ça (et l'erreur la plus courante doit être mettre l'URL de la page au lieu de l'URL de l'image, ce qui ne nécessite pas non plus d'avoir plus que les premiers octets).

Si l'idée est vraiment juste de savoir si c'est une image et son type, au lieu de télécharger toute l'image pourquoi ne pas prendre les 1-2 premiers Ko, et en verifier l'entête ?

PNG, JPEG, GIF ont leur entête en debut de fichier

Je ferai des essais, mais rien dans la documentation n'indique que les fonctions que j'utilise supportent des fichiers partiels (imagecreatefromstring puis imagesx/y, ou getimagesize). Peut-être que d'autres sont disponibles nativement et n'auraient pas ce défaut.

Quant à recoder à la main la lecture des headers de tous les formats nécessaires, je passe mon tour ^^

Ça tombe bien, quelqu'un s'en est déjà chargé semble-t-il ^^ :
https://github.com/tommoor/fastimage

Hmf le code est pas top, ça utilise fopen & co pour accéder à des URLs. Je regarderai si c'est facile à adapter, mais pas utilisable tel quel dans yAronet.

Heu, tu compte faire comment? fopen est la seule methode pour ouvrir un fichier distant en PHP que je sache

(et la facon de faire est plutot propre en faite, c'est d'ailleurs la seule facon sans utiliser de librairie complete qui de toute maniere refusera si le fichier n'est pas complet)

Zeph (./16) :
Si je t'avoue que yAronet est codé en PHP, tu peux en déduire la réponse ?

Ça fait un bail que je n'ai pas fait de PHP ^^

./22 : Loin de là, le support des URLs dans fopen est un hack pratique pour ouvrir un flux HTTP avec très peu de code, mais je ne l'utiliserais pas pour autre chose que des tests. Entre autres, ça ne permet pas de contrôler le téléchargement, de configurer des timeouts de connexion et de réception, de spécifier des headers (par exemple user-agent sans lequel certains sites refuse de livrer leur contenu), etc. Pour yAronet j'utilise cURL.

oui j'allais dire que la solution naturelle était curl

Bon, à défaut d'avoir quelque chose de fiable pour les images, je fais un essai avec ce que je ne voulais pas implémenter au message ./12. J'ai regardé la configuration Infomaniak : ils ont des serveurs MySQL qui ferment les connexions inactives au bout de 30 secondes, or il peut exceptionnellement arriver que poster un message prenne davantage de temps s'il contient des grosses images et/ou qu'elles sont hébergées sur un serveur lent. Comme je n'ai pas la main sur cette configuration, je tente un bout de scotch qui effectue une reconnexion manuelle quand c'est nécessaire, on verra à l'usage si c'est mieux.

Je n'oublie pas la suggestion d'utiliser fastimage, il faudra juste que je prenne le temps d'adapter cette bibliothèque pour utiliser cURL à la place de fopen.

[edit] En fait si, je vais l'oublier pour le moment, si jamais la rustine de reconnection MySQL fonctionne j'aime autant garder une vérification complète sur les images pour éviter d'insérer du contenu corrompu.

Si on compare les solutions dans l'absolu (sans tenir compte du boulot nécessaire pour intégrer fastimage), j'aurais tendance à penser le contraire. Je vois trois situations possibles :
1) le contenu est valable : c'est le cas normal
2) le contenu est invalide de façon flagrante (page HTML au lieu d'une image, 404, etc.) : ça arrive de temps en temps
3) le contenu est corrompu de façon subtile : c'est rarissime

Si on intègre fastimage :
- c'est bénéfique dans le cas 1 : ça diminue le temps pour qu'un post soit effectué, de manière significative quand il y a beaucoup d'images
- c'est sans incidence sur le cas 2
- il y a une régression dans le cas 3 ; mais est-ce vraiment grave que ça affiche une image corrompue quand on poste une image corrompue ?

Bref si tu fais le produit probabilité x bénéfice, ça me semble plus judicieux que le bout de scotch.

Mais le bout de scotch résout davantage de problèmes que celui des images, il fonctionne aussi pour insertions de musiques, de vidéo youtube, ou de n'importe quel autre contenu qui pourrait ralentir l'envoi d'un message. Mais bon dans tous les cas je n'ai pas la moindre envie d'adapter fastimage pour le moment, donc à moins que l'un d'entre vous le fasse je me contenterai de voir ce que donne la solution actuelle donne.

Oh le fait que ça te gonfle c'est autre chose, je ne parlais que sur le plan théorique ^^
(après, rien n'interdit d'utiliser fastimage pour les images et d'avoir un fallback pour le reste )