après avoir utilisé la fonction “reconstruire HTML” sur certains messages et constaté qu’elle réparait le message sur mon forum de production, j’ai rebaké tous mes messages en utilisant la tâche rake.
J’ai été surpris de constater que les messages avec l’image cassée N’AVAIENT PAS ÉTÉ réparés.
J’ai donc expérimenté un rebake sur un message spécifique sur mon forum de test (même sauvegarde ; mêmes données) avec la commande rails et la tâche rake, et voici le comportement :
Les images s’affichent une seconde, mais le message revient rapidement à son état initial avec des images cassées.
Cependant, si j’utilise la fonction “reconstruire HTML”, cela fonctionne parfaitement, et les images ne reviennent pas à l’état cassé. Elles sont même correctement téléchargées sur le serveur après quelques minutes.
Alors, quelqu’un peut-il expliquer ce phénomène ? Pourquoi le rebake depuis rails ou une tâche rake a-t-il ce comportement, et quelles sont les différences entre reconstruire HTML et un rebake en ligne de commande ?
Captures vidéo :
depuis la console rails :
depuis la tâche rake :
Je suis très intrigué (et j’essaie toujours de réparer mes images dans tous mes messages par lots).
Un exemple où j’ai utilisé Rebuild HTML qui montre que les images intégrées de ce message s’affichaient correctement et étaient automatiquement téléchargées sur le serveur (évidemment, leur lien d’origine, menant à casimages, est toujours là, mais c’est le comportement attendu), il y a quelques jours : Frensh Vw Bus CHERIZET 2019 SK - #13 par buggyderby - Vos sorties - VW Camper
Je pense que la tâche rake les marque pour une nouvelle cuisson et déclenche également la reconstruction des miniatures. Avez-vous vérifié Sidekiq pour voir si des éléments sont mis en file d’attente ?
modifier :
Une tâche de rebake de râteau sur le message déclenche un PullHotLinkedImages en 4 minutes et augmente également instantanément le nombre de tâches traitées d’une unité, mais je n’ai rien vu ajouté à l’onglet de la file d’attente.
Les quelques messages sur lesquels j’ai effectué une reconstruction HTML manuelle ont vu leurs images parfaitement affichées depuis des jours (elles sont également téléchargées sur mon serveur).
<s\u003eJe crains de ne pas savoir pourquoi cela fonctionne différemment avec la clé d’administration par rapport à la console, mais j’ai trouvé ce sujet avec un problème similaire, et ils ont réussi en refaisant la cuisson via l’API :\u003c/s\u003e
Outre Jay, qui a entrevu une possible différence entre le “rebake” et le “rebuild HTML” de rake/rails, quelqu’un d’autre a-t-il une idée ?
Une réponse officielle sur la ou les différences entre ces tâches serait la bienvenue
Si nous ne pouvons pas trouver la solution, je commencerai par la voie de l’API pour “reconstruire le HTML” de mes 40000 messages contenant des problèmes potentiels avec les images… Et j’espère que cela fonctionnera pour moi
Ou s’il existe un autre moyen de “reconstruire le HTML” en utilisant Rails, peut-être ?
Reconstruire le HTML : post.rebake!(invalidate_oneboxes: true, invalidate_broken_images: true)
Rake posts:rebake : post.rebake!(**opts) où opts est généralement vide
Pour les Oneboxes, vous pouvez essayer la tâche posts:refresh_oneboxes et pour les images brisées, vous pouvez essayer la tâche posts:invalidate_broken_images. Cette dernière pourrait être la solution à votre problème.
Après un test sur quelques publications, cela semble fonctionner à merveille !
Je vais essayer sur des milliers de publications et voir comment cela se passe ! Merci beaucoup !
Après avoir essayé d’exécuter post.rebake!(invalidate_broken_images: true) sur mes 40000 publications contenant la chaîne [img], cela a fonctionné pour de nombreuses images… Mais loin de toutes, bien qu’elles soient hébergées sur le même service d’hébergement d’images externe.
Par exemple, j’ai des milliers de liens “fonctionnels” casimages (qui pointent vers des images valides et affichent les images dans l’aperçu du compositeur lors de la modification), cassés dans la version cuite des publications, qui ont été correctement affichés et téléchargés sur le serveur grâce à mon script, mais j’en ai aussi beaucoup d’autres pour lesquels cela n’a tout simplement pas fonctionné, et je ne sais pas pourquoi.
Post.where('raw LIKE ?', '%[img]%').find_each do |p|
p.rebake!(invalidate_broken_images: true)
end
J’ai également des liens d’images provenant d’autres hébergeurs d’images qui ont été téléchargés, et certains pour lesquels cela n’a pas fonctionné.
J’ai échoué à voir une différence entre ces publications et ces liens d’images. Elles avaient toutes des images fonctionnelles, et le fait qu’elles utilisaient le même hébergeur d’images m’a interpellé.
J’ai essayé l’opération à plusieurs reprises et les résultats étaient incohérents, indépendamment des services d’hébergement externes… Certaines images ont été téléchargées, d’autres non. Cela semblait aléatoire.
Je ne parlerai ici que de casimages, bien que mon forum importé utilisait divers autres hébergeurs d’images.
J’ai donc pensé que peut-être casimages bloquait temporairement mon IP si j’essayais de récupérer trop d’images de leurs serveurs. Cela pourrait expliquer à la fois le fait que cela n’ait pas fonctionné pour toutes les images et le caractère aléatoire du succès du téléchargement des images depuis mon serveur.
Il y a même eu des cas où l’option Rebuild HTML fonctionnait - d’abord seulement -, les images s’affichaient alors au lieu de montrer une icône d’image cassée, bien qu’elles soient toujours hébergées sur leur service d’hébergement externe, mais lorsque la tâche Sidekiq de récupération des images externes était déclenchée, cela cassait les images.
Idem en utilisant des scripts rail avec rebake!(invalidate_broken_images: true)
J’essaie donc actuellement une approche plus lente, où j’attends 5 secondes entre chaque commande rail rebake! :
total = Post.where('lower(raw) LIKE ?', '%[img]https:%').count
i = 0
Post.where('raw LIKE ?', '%[img]https:%').find_each do |p|
p.rebake!(invalidate_broken_images: true)
print "#{i}/#{total}"
print "\r"
i +=1
sleep(5)
end
Je verrai dans environ 60 heures si cela s’est amélioré…
J’aimerais comprendre les fondements de mon problème ici et pourquoi un rebake “normal” ne parvient pas à télécharger une image sur le serveur (si je ne suis pas temporairement bloqué par casimages).
Notez que cette fois, le certificat du serveur de casimages semble correct
Je ne comprends pas non plus ce que fait réellement invalidate_broken_images. Je ne suis pas très familier avec le code de Discourse.
J’ai regardé le code pour voir l’occurrence de invalidate_broken_images et j’ai vu ces fichiers :
Pourquoi recherche-t-il spécifiquement la chaîne <img> ? Mes publications proviennent d’une importation phpBB et la version brute ne contient que le bbCode [img], pas les balises <img> ; alors comment cela aurait-il un effet (et cela l’a eu, voir mon message précédent) sur mes publications ?
Je ne comprends pas non plus vraiment la différence entre ces deux méthodes (?) :
Il semble indiquer que rebake définit les arguments par défaut sur false, et que rebake! définit l’argument par défaut sur true.
Comment ces deux éléments sont-ils liés (je connais d’ailleurs le but du caractère ! en ruby), et pourquoi sont-ils dans des fichiers différents ?
Mon objectif est uniquement de comprendre pourquoi mes images externes sont parfois téléchargées, parfois non, et si je peux trouver un moyen fiable de les télécharger correctement et automatiquement, même si cela implique de télécharger une image toutes les heures.
Cela fait presque deux semaines que je travaille sur ce problème et cela me rend fou (ainsi que les personnes pour lesquelles j’ai migré leur serveur).
De plus, il n’y a rien dans les logs de Discourse, à part plusieurs messages Sidekiq is consuming too much memory (using: 592.25M). Notez que je travaille sur Ubuntu via WSL sous Windows 10, mais j’ai l’intention d’utiliser une solution fonctionnelle (si j’en trouve une…) sur notre VPS.
C’est plus loin là où vous voyez ce qu’il fait à la ligne 716. Il supprime ces images afin qu’il réessaie de les télécharger. (à première vue en tout cas)
Donc, je suis presque à mes 55 heures de re-cuisson de mes messages contenant [img] avec un délai de 5 secondes entre chaque itération de mes 40000 messages de mon script rails.
D’après ce que je vois, cela fonctionne beaucoup mieux qu’avant. La plupart des images valides (j’exclus Imageshack et son comportement erratique) semblent être téléchargées sur mon forum sans problème à première vue, mais je vais examiner de plus près pour être sûr à 100%. Ce qui est sûr à 100%, c’est que les résultats sont bien meilleurs et plus cohérents.
Je suspecte donc que le problème que j’ai rencontré (et peut-être le problème de @Amethi) qui était le caractère aléatoire du téléchargement d’images à distance avec invalidate_broken_images était lié à une sorte de limitation de débit de divers fournisseurs d’hébergement d’images… ? Le truc bizarre, c’est que je n’ai remarqué aucun problème avec mes autres forums importés…
Cela dit, si les résultats sont suffisamment satisfaisants et que le délai améliore réellement le téléchargement d’images à distance, j’appliquerai la même méthode sur mon forum de production, mais j’augmenterai le temps entre chaque re-cuisson de message de 5 secondes à 10 ou 15 secondes (ou même plus, nous ne sommes pas pressés, ce sont tous des messages assez anciens, et le VPS a des spécifications bien inférieures à mon propre ordinateur).
Je ne veux pas conclure trop vite, mais la solution à mon problème initial pourrait être d’appliquer à la fois la solution proposée par Richard ET d’ajouter un délai entre chaque re-cuisson de message.
\u003c/s\u003e
Je ne parlerai ici que de casimages, bien que mon forum importé utilisait divers autres hébergeurs d’images.
