(wink @Sebsauvage : https://sebsauvage.net/links/?-WagqA )

Je me suis aperçu que mon plugin Plinstagram faisait des trucs étranges et refusait parfois de poster. Pensant à une erreur d'identification, j'ai repris le code mais rien n'y faisait.

J'ai commencé à avoir des problèmes de redirection incompréhensibles: le header("location") ne fonctionnait pas (voir https://warriordudimanche.net/article1635/1635 )

Une fois la ruse très moche appliquée, ça semblait revenu à la normale. Puis j'ai décidé d'aller marcher un peu et j'ai pris des photos dans l'idée de tester à nouveau Plinstagram.

Et là, c'est le drame

J'ai beau tout essayer, pas moyen d'envoyer le post avec les photos... mais curieusement, j'aboutis à une erreur 404 et pas à une erreur d'exécution. Je me dis que ça doit être un problème de taille de formulaire et je me rappelle que, comme un con, j'ai omis de virer l'input files du formulaire avant envoi. J'explique rapidement comment fonctionne Plinstagram:

Côté JS

1 - l'utilisateur sélectionne des photos sur son ordinateur

2 - pour chaque image, le script js se charge de:

• récupérer les images sélectionnées,
• créer une miniature avec un canvas
• stocker l'image réduite sous forme de donnée base64 dans un input hidden (avec le nom de fichier dans un autre input hidden) créés à la volée

Ainsi on obtient un $_POST[data] et un $_POST[filename] qui contiennent chacun un tableau avec les données de chaque image pour l'un et le nom de chaque image pour l'autre.

Quand on poste, le script vire l'input file pour éviter l'upload de grosses photos.

Côté PHP

Vient ensuite le hook AdminArticlePrepend de la page core/admin/article.php vers laquelle pointe le formulaire de plinstagram: celui-ci se charge de :

1 - parcourir l'array des images redimensionnées postées en base64,

2 - récupérer le nom de chaque image

3 - sauvegarder localement chaque image dans un sous-dossier dédié à l'article

4 - générer une galerie qu'il ajoute au corps du post

5 - finaliser la création des données de l'article.

À ce moment-là pluXML reprend la main et s'occupe du stockage de ces données.

Quand je teste en distant (sur WDD)

Avec une photo, tout se passe normalement. Si j'en mets ne serait-ce que deux, pluXML me renvoie à la page 404, comme si l'URL était fausse: or, il n'en est rien ! L'URL de la barre d'adresse est la bonne, celle du formulaire aussi... pourtant, avec plus d'une photo, la requête n'arrive jamais à core/admin/article.php

Pire, une fois sur la page 404, si je clique dans la barre d'adresse puis que j'appuie sur entrée, j'arrive sans encombre à la page voulue (mais sans les données de formulaire bien entendu): l'URL est donc bonne.

J'ai pensé à une redirection foireuse mais la seule redirection qui reste est celle qui se fait AVANT le formulaire et seulement dans le cas où l'utilisateur n'est pas connecté.

Et puis ça ne semble pas être la faute de mon script PHP vu qu'on n'arrive même pas jusqu'à lui (j'ai collé des exit('moncul'); partout pour voir et rien !)

Quand je teste en local... ô surprise!

TOUT FONCTIONNE SANS PROBLEME ! (le fameux «ça marche sur mon ordi»)

• J'ai pensé à un problème de version de PHP: j'ai essayé de changer et c'est pas ça
• j'ai songé à une limite de la taille de fichiers ou la limite de taille de post... c'est pas ça (puis ça générerait une erreur, pas un pseudo 404)

Pour résumer

Conclusion

J'en suis à me dire qu'il doit y avoir un genre de restriction pour la taille des données contenues dans des inputs et que cette restriction ne doit pas être la même en local.

Une autre piste que je dois explorer est une éventuelle incompatibilité entre deux plugins... Mais je vois pas lesquels et pis là, faut que j'aille pleurer d'abord.

EDIT dix minutes plus tard:

Tiens, la différence entre le local et le distant, c'est la configuration du rewrite URL dans pluXML: activée en distant. Je mets sur OFF et là, j'obtiens une erreur 406:

Not Acceptable: An appropriate representation of the requested resource could not be found on this server.

ça progresse. Je retourne pleurer.