J’explore la possibilité de créer un forum partagé pour deux sites web distincts, mon blog et mon portfolio. L’idée est d’avoir une seule base de données de forum qui serve les deux sites, permettant aux utilisateurs et aux sujets d’être partagés entre les deux communautés. Cependant, j’aimerais que le forum soit stylisé différemment selon le site que l’utilisateur visite, afin que chaque communauté se sente distincte tout en faisant partie d’un espace partagé plus large.
J’ai une formation en développement web, bien que je n’aie pas travaillé sur un projet d’une telle envergure depuis un certain temps. Je suis prêt à me replonger et à apprendre ce qui est nécessaire pour que cela fonctionne, mais j’apprécierais des conseils sur la faisabilité de ce projet avec Discourse.
Plus précisément, je me demande :
Discourse peut-il supporter des thèmes ou des styles distincts en fonction du domaine ou de l’URL de référence ?
Est-il possible de configurer Discourse pour afficher une image de marque personnalisée (logos, couleurs, etc.) tout en maintenant une base d’utilisateurs et un pool de sujets partagés ?
Existe-t-il des plugins ou des extensions qui pourraient faciliter la mise en œuvre ?
Des conseils sur les défis ou les limitations à considérer lors de la poursuite de ce type de configuration ?
Ce projet est encore en phase conceptuelle, et je prévois de commencer la construction vers la fin de l’année. Je veux m’assurer que Discourse est la bonne plateforme pour cette vision avant de m’engager.
Merci d’avance pour vos éclaircissements, suggestions ou ressources !
Je ne suis toujours pas très clair.
Donc le domaine a pointe vers le forum, et le domaine b pointe vers le même forum / un forum différent avec la même base de données ? Si c’est le cas, peut-être un forum différent avec la même base de données ? Alors le style peut être différent.
Peut-être que ce guide aidera ?
Alors les deux forums pourraient pointer vers là ?
En faisant une recherche rapide, je ne suis pas sûr que cela puisse être fait facilement.
Une approche peut-être plus simple serait d’utiliser un commutateur lié au groupe principal et d’avoir 2 groupes qui, en passant du groupe A au groupe B, changent les thèmes et utilisent peut-être quelque chose comme le composant Theme pour une page d’accueil personnalisée pour les groupes ? Ou peut-être utiliser Modern Category+group boxes installés deux fois (utilisés dans le thème air) avec des personnalisations basées sur le thème/groupe principal.
Bien que je ne le sache pas moi-même. Je me demanderais si avoir 2 installations de discourse pourrait risquer de corrompre la base de données ? Bien que certains aient des sites de staging, mais je pense que le site de staging est sauvegardé régulièrement sur le site principal ?
Donc, si un utilisateur ouvre le site A, accède au forum depuis le site A, le thème A est appliqué.
Ensuite, le même utilisateur ouvre le site B, accède au forum depuis le site B, et voit le thème B ?
Et si l’utilisateur a le thème A appliqué, accède au site B, et rafraîchit la page du forum ? Est-ce que le thème B est appliqué, ou est-ce que le thème A est conservé ?
Mon hypothèse est que vous pouvez exécuter plusieurs moteurs (installations Discourse) sur la même base de données (vous avez donc besoin d’une base de données séparée). Je n’exécuterais qu’un seul sidekiq, cependant. Sinon, deux d’entre eux commenceraient à se battre pour les tâches. Sinon, je pense que Discourse est une application sans état, donc cela ne devrait pas importer combien vous en exécutez.
Maintenant, une question à la racine du problème : Pourquoi ? Et n’est-ce pas contre les règles de référencement ? Je pense que Google n’aimait pas s’il trouvait le même contenu sur plusieurs sites.
En fait, certaines choses pourraient ne pas fonctionner comme prévu – par exemple, les mises à jour de l’interface utilisateur en temps réel (si quelqu’un met à jour un article pour qu’il se re-rende magiquement pendant que vous lisez). Je pense que les deux sites ne se le diraient pas, vous devriez donc vous fier à l’utilisateur qui rafraîchit son navigateur. Il pourrait y en avoir d’autres. Comme si vous modifiez les paramètres du site sur un site, je suppose que l’autre site ne le remarquerait pas non plus et que vous devriez redémarrer l’autre.
D’après Scaling up and sidekiq, il me semble que c’est en fait résoluble. Sidekiq semble gérer cela et le reste serait une question de configuration correcte de Redis.
C’est un peu hors sujet, et je ne veux pas dévier la conversation, mais j’aimerais ajouter ma simple appréciation.
Je pense que nous sommes à une époque d’Internet où il faut penser au référencement ou à ses utilisateurs.
Et je n’ai aucun doute que Discourse auto-hébergé sera utilisé par ceux qui choisissent leurs utilisateurs.
Je cherchais cette fonctionnalité car j’ai des projets personnels avec le même public et la même cible. Multisite avec SSO était le plus proche mais je n’aboutissais nulle part car c’est lent et peu pratique.
Je soutiens l’idée de l’OP et je commence à suivre ceci
Discourse n’est pas sans état, et toutes les informations se trouvent dans la base de données. Donc, si vous exécutez plusieurs instances sur une seule base de données, elles se ressembleraient automatiquement et les changements dans l’une se refléteraient immédiatement dans l’autre.
Il s’agirait “juste” de changer de thème. Peut-être exploiter la logique existante de prévisualisation des thèmes et avoir un plugin qui regarde simplement le nom d’hôte au lieu du paramètre d’URL.
Héberger le même forum sous deux URL pourrait être la partie la plus difficile ici, surtout en ce qui concerne le référencement. Cela vous entraînerait dans toutes sortes de problèmes de contenu dupliqué et d’URL canoniques.
Pouvez-vous clarifier cela ? Il serait vraiment intéressant d’en savoir un peu plus sur le fonctionnement. Je pense que vos deux phrases se contredisent ? Je pense que refléter tout est en fait ce que l’OP a demandé. Mais comment cela pourrait-il se produire si l’autre instance n’est pas informée d’un changement effectué par la première instance ? C’est stocké dans la base de données, oui, mais il n’y a pas de notification.
Donc, juste une base de données = sans état. Chaque fois que vous faites une requête, vous interrogez à nouveau la base de données - il n’y a pas d’état en mémoire. Ou bien ?
Sinon, j’aime beaucoup l’idée d’un plugin. Je suis d’accord que ce serait la voie à suivre et je pense toujours que le SEO n’est pas quelque chose que l’on choisit de faire, mais que l’on doit faire d’une manière ou d’une autre pour attirer du public. La duplication serait un moyen d’y parvenir. Même du point de vue de l’utilisateur, il pourrait être suspect de voir quelque chose que j’ai écrit sur un site peut-être lié sur un autre site dont je n’avais aucune idée, je serais vraiment dérangé. La duplication de contenu est généralement une méthode utilisée par les sites de faible qualité. C’est pourquoi elle subit une dégradation du SEO. Mais ce serait plutôt un sujet pour la catégorie Community.
Je pense que nous sommes dans une confusion de définitions ici. Le code côté serveur de Discourse est (en quelque sorte*) sans état, mais l’instance entière de Discourse (client Web, code côté serveur, Redis, fichiers mis en cache, base de données) ne l’est pas.
L’autre côté de cette médaille est que - étant donné que le code côté serveur est sans état - cette configuration ne peut pas accomplir ce que l’OP souhaite, car il n’y a pas d’endroit pour stocker les informations sur l’URL et le thème qui devraient être servis. La configuration que vous décrivez est en fait ce qui se passe dans une configuration d’équilibrage de charge où il y a plusieurs conteneurs Web et une seule instance de base de données/Redis. C’est un site unique.
Je dis “en quelque sorte” car il existe de nombreuses couches de mise en cache à divers endroits.
Je vois. L’URL du site principal est-elle également stockée dans la base de données ? Ce n’est donc pas une question de configuration d’une instance locale ? Dans ce cas, il serait clair que les deux instances essaieraient toujours de servir la même chose.
Et vous avez raison, une configuration à deux serveurs n’aide toujours pas Discourse à choisir le bon thème.
Cela me rappelle qu’il y aurait aussi un problème avec le contenu. Si vous collez un lien dans Discourse, il publie l’URL entière. Ainsi, quelqu’un lisant un sujet rédigé par l’autre site serait dirigé vers celui-ci en cliquant sur un lien. Idem pour les téléchargements, voir Uploads Path Should Update When URL Changes in app.yml During Container Rebuild.
Un autre problème pourrait être les e-mails ? De quel domaine proviendraient les e-mails de notification ? Un autre problème – les plugins sociaux (Facebook, etc.) ou la connexion Google redirigeraient vers un mauvais site (ou refuseraient peut-être la connexion).
Venant de nulle part, une solution beaucoup plus simple serait d’avoir une seule instance avec 2 catégories - une pour chacun des sites parents. Cela contournerait tous les problèmes mentionnés ci-dessus.
Il y a amplement de possibilités pour styliser les catégories et les sujets qui se trouvent dans cette catégorie via un simple CSS en utilisant la classe category-category_slug.
Si vous voulez faire de l’un ou l’autre le « par défaut » ou la page d’accueil pour un groupe d’utilisateurs, alors Custom Homepage for Groups serait l’outil dont vous avez besoin.
