Il m’affiche l’erreur ci-dessous. Comment la corriger ?
Au fait, après avoir ajouté une table des matières dans un sujet, je dois actualiser la page, sinon le lien de la table des matières ne fonctionne pas. Est-ce un comportement normal ?
1 « J'aime »
Salut @Yt.w, merci pour le rapport. Je n’ai pas pu reproduire le problème que vous avez mentionné. Observez-vous toujours ce comportement ? Si oui, pourriez-vous s’il vous plaît fournir plus de détails sur les étapes pour le reproduire ?
D’après ce que je peux voir, le rafraîchissement de la page pour reconstruire le HTML est un comportement attendu. Bien qu’il soit possible de l’éviter, cela nécessiterait des modifications dans la façon dont le composant fonctionne actuellement.
1 « J'aime »
Bonjour, j’observe toujours ce comportement, et il s’est en fait produit immédiatement après l’installation de mon instance actuelle. Je n’ai apporté aucune modification.
Mon autre instance n’a pas ce problème, donc c’est assez déroutant pour moi.
D’un point de vue UX, je pense qu’il est préférable d’éviter de rafraîchir la page pour maintenir la TOC active.
1 « J'aime »
@Yt.w pouvez-vous me montrer la console de votre navigateur lorsque vous rencontrez cette erreur, s’il vous plaît ? Développez également l’erreur.
J’ai exactement la même erreur sur l’un des trois sites que j’héberge dans une configuration multisite, ce qui me fait penser qu’un des paramètres de ce site est à l’origine de ce problème. Je n’ai pas encore déterminé quel paramètre, mais lorsque je l’aurai trouvé, je reviendrai pour mettre à jour le post. Je voulais juste ajouter que je constate également cela dans la nature sur la dernière version qui a passé les tests.
Voici ce qui se trouve dans ma console et ce sont des choses auxquelles je suis habitué, pour le meilleur ou pour le pire 
1 « J'aime »
Merci, nous avons toujours du mal à reproduire exactement le problème, nous ne parvenons pas à le faire se produire sur nos sites hébergés multisites.
1 « J'aime »
Ceci peut ou peut ne pas être un leurre, je n’ai pas eu assez de temps pour creuser, mais lorsque je désinstalle et réinstalle le composant, j’obtiens systématiquement l’erreur suivante :
Le numéro du champ change, je suppose parce qu’il est installé comme un numéro de composant différent à chaque réinstallation du composant. Je vais continuer à creuser, mais cela n’arrive pas lorsque je fais la même chose avec d’autres composants…
Mes soupçons actuels sont que l’échec est en partie dû au fait que j’ai annulé certains changements S3 que j’ai apportés spécifiquement sur ce site à un moment donné. @Yt.w, y a-t-il une chance que vous ayez également utilisé S3 à un moment donné sur votre installation ?
2 « J'aime »
D’accord, j’ai réussi à faire disparaître l’erreur et à la reproduire.
TL;DR
- Revenir à une configuration S3 qui fonctionne auparavant, puis supprimer et réinstaller le composant DiscoTOC, résulte en une installation du composant sans erreur.
- Désactiver S3 en commentant toutes les directives S3 dans app.yml entraîne la réapparition de l’erreur lors de l’installation du composant, et je suppose que lors de la mise à jour l’erreur reviendra également.
- La configuration
DISCOURSE_USE_S3: falsen’empêche pas Discourse d’utiliser des chemins S3, cela ressemble à un bug ou cette option ne fonctionne pas comme je le pense.
Vue d’ensemble détaillée
Initialement, ce que j’ai fait, c’est de relancer ma configuration Minio, décommenter les options de configuration dans mon app.yml, reconstruire l’application, et m’assurer d’exécuter la tâche s3:upload_assets. Une fois le site relancé, je suis allé dans la section des composants. Le composant DiscoTOC déjà installé affichait toujours l’erreur, mais lorsque je l’ai supprimé et réinstallé, l’erreur n’est pas réapparue. Lors de l’installation du composant DiscoTOC, sprite.svg a été demandé depuis mon serveur S3.
Dans le cadre de la tentative de reproduction du problème, j’ai rencontré un problème intéressant. Il semble que lorsque je laisse toutes les directives S3 dans mon app.yml actives, c’est-à-dire non commentées, mais que je définis DISCOURSE_USE_S3: false, le frontend du site ne charge pas si Minio n’est pas en marche.
Peut-être que DISCOURSE_USE_S3: false n’est pas destiné à désactiver tout accès S3, je suppose que cela fonctionne selon le nom, mais apparemment ce n’est pas le cas. Dès que je redémarre le service Minio et actualise le frontend, tout fonctionne bien. Je peux également désinstaller et réinstaller le composant DiscoTOC sans reproduire l’erreur dans cet état. Cela semble être, au moins potentiellement, un bug.
Voici le troisième état qui m’a permis de reproduire l’erreur.
Pour faire fonctionner mon site sans que Minio soit en marche, j’ai commenté toutes les entrées qui avaient un rapport avec S3 dans la configuration. Ensuite, j’ai reconstruit l’application et maintenant, sans que Minio ne tourne, le chargement du frontend se fait sans problème. Cependant, si je désinstalle et réinstalle le composant DiscoTOC, l’erreur apparaît à nouveau. J’ai aussi essayé de lancer simplement Minio dans cet état, mais l’erreur est réapparue lors de la réinstallation. Cela est probablement dû au fait qu’il n’y a aucune directive S3 dans app.yml, donc même si l’application tente d’accéder à S3 en coulisses, elle utilise des valeurs par défaut plutôt qu’une configuration fonctionnelle. Cependant, il semble que certaines images essaient encore d’être servies depuis S3 même après un posts:rebake (par exemple 1531a70abda0d81d1a4039b6f3fa38bea79ef0de_2_180x180.png/xl.meta).
2 « J'aime »
Oui, le forum qui posait problème utilisait S3(B2), tandis que le forum sans problème n’utilisait pas S3.
1 « J'aime »