Pour ma part, dans Paramètres/Légal, l’URL vers une page de FAQ hébergée séparément (et vraisemblablement les URL vers les pages des Conditions d’utilisation et de la Politique de confidentialité également) semblent avoir cessé de fonctionner sur la page d’accueil du forum.
J’ai essayé plusieurs URLs de test pointant vers d’autres pages web, mais aucune ne semble désormais avoir d’effet. Sur la page d’accueil de mon forum, le texte login_required.welcome_message s’affiche systématiquement, alors que jusqu’à récemment, c’était la FAQ située à l’URL désignée qui apparaissait à la place.
Je peux toujours insérer un lien manuel vers les mêmes pages personnalisées dans la boîte de dialogue « Connexion requise », à condition qu’elles soient publiées sous forme de messages dans Discourse et définies comme publiques.
Ce problème a-t-il été résolu pour vous ? Sur mon site de test, je constate que je peux configurer les paramètres tos url et privacy policy url pour qu’ils pointent vers un site externe. Je ne remarque aucun problème lié à l’ignorance des liens externes, ni dans la fenêtre modale d’inscription du site, ni sur la page À propos du site.
Bonjour Simon,
Ce problème n’a jamais été résolu pour moi, j’ai donc fini par copier-coller depuis la FAQ (qui est en réalité une page publique « publiée » au sein du site) directement dans le texte de la fenêtre de bienvenue. Ce n’est pas très efficace, mais cela fonctionne.
Curieusement, en cliquant pour s’inscrire, les liens vers les CGU et la politique de confidentialité (également des pages publiques publiées) fonctionnaient toujours depuis la fenêtre d’inscription. Mon problème semble donc être limité à la page d’accueil.
Voulez-vous dire que votre page FAQ est un sujet Discourse que vous avez publié en tant que page ? Si c’est le cas, ce n’est pas quelque chose que j’ai essayé de faire.
Je n’avais pas le choix, car tous les sujets pré-initialisés ont disparu pour moi lors d’une mise à niveau. Tout fonctionnait correctement, jusqu’à ce qu’une mise à niveau plus récente empêche leur affichage depuis la page d’accueil.
Oh non. Je allais demander pourquoi vous utilisiez des pages publiées pour les pages CGU et FAQ, mais cela a du sens maintenant. Utiliser des pages publiées pour ces sujets semble cependant peu idéal. Je suis assez certain qu’il est possible de recréer les sujets pré-initialisés. Ils sont définis par certains paramètres de site cachés. Les paramètres suivants peuvent être utilisés pour réinitialiser les sujets Conditions d’utilisation et Confidentialité :
tos_topic_id
privacy_topic_id
Je ne connais pas le nom du paramètre pour définir l’ID du sujet FAQ, mais nous pouvons retrouver ce paramètre pour vous si vous souhaitez apporter cette modification. À ma connaissance, vous devriez créer les nouveaux sujets dans votre catégorie Équipe, puis définir les paramètres de site cachés sur ces IDs de sujets.
Si vous pouvez retrouver l’ID du sujet FAQ, ce serait idéal, ne serait-ce que pour toute autre personne confrontée au même problème de sujets pré-initialisés défectueux.
Concernant le problème de la page d’accueil, il y a quelques jours, j’ai transformé ce problème en un atout en créant une version beaucoup plus courte de la FAQ (principalement pour les personnes incertaines de se trouver au bon endroit), avec des liens en bas vers le sujet complet du personnel sur la FAQ, le sujet du personnel sur les CGU et le sujet de la politique de confidentialité.
Auparavant, ma FAQ constituait l’intégralité de la page d’accueil (remplaçant le texte de la fenêtre de bienvenue).
Il serait préférable de vérifier d’abord si les anciens sujets relatifs aux CGU, à la politique de confidentialité et à la FAQ existent toujours. Vous pouvez le faire en vérifiant la valeur de chacun de ces paramètres du site depuis la console Rails, puis en recherchant les sujets supprimés via l’interface utilisateur :
tos_topic_id
privacy_topic_id
guidelines_topic_id
Avec l’ID renvoyé par chaque paramètre, vous pouvez tenter de retrouver le sujet supprimé en accédant à /t/-/<id_du_sujet_provenant_de_la_valeur_du_paramètre>. Si le sujet existe, il devrait être possible de le restaurer via l’interface utilisateur. Si les sujets n’existent pas, je suppose que de nouveaux sujets peuvent être créés dans la catégorie « Équipe ». Vous pourrez alors définir ces ID de sujet comme valeur pour chacun des paramètres que j’ai listés ci-dessus. Je n’ai pas essayé cela moi-même, mais je peux le tester sur mon site de développement local si vous hésitez à effectuer cette modification sur votre site.
Comment ça s’est passé, Paul ? Je me souviens que c’était un problème pour toi il y a longtemps.
Je viens de devoir faire cela moi-même après avoir accidentellement utilisé delete_all dans le sujet FAQ/Lignes directrices et ne l’avoir découvert que bien plus tard. Ce post m’a été d’une grande aide :
Je serais heureux de t’aider si tu as besoin d’un coup de main.
Je n’ai jamais trouvé ces sujets pré-remplis manquants, mais je suis toujours satisfait de ma solution de contournement, donc je n’ai pas été motivé à essayer très fort - essentiellement, ce sont maintenant des sujets du personnel modifiables de manière conventionnelle, marqués comme publics, que je peux et mets à jour de temps en temps.
En supposant que vous ayez un accès root à votre serveur, la correction prendra littéralement 5 minutes et vous ne perdrez aucun de ces éléments pratiques de sujet de personnel.
Tout ce qu’elle fait, c’est d’identifier ces sujets comme ceux à utiliser.
J’avoue que je n’y connais rien à l’utilisation de Rails, mais j’ai pu confirmer que les sujets d’origine avaient bien disparu en utilisant des requêtes data-explorer (sur suggestion d’un autre utilisateur, que je n’arrive pas à retrouver pour le moment).
Pour autant que je puisse en juger, ma configuration semble maintenant “savoir” quels sujets du personnel sont ceux à utiliser, même si la méthodologie que j’ai suivie pour y parvenir (que je n’arrive pas non plus à retrouver pour le moment !) était un peu moins “hardcore” que la route d’édition Rails.