Actuellement, les commentaires de Discourse et WordPress sont synchronisés. Il serait formidable d’avoir une synchronisation bidirectionnelle entre le contenu principal afin que la communauté Discourse puisse modifier (modifier et enrichir considérablement) le contenu de l’instance Discourse. Ainsi, la communauté pourrait participer à l’amélioration du site WP (ce pour quoi la communauté est conçue - participer à la création et à l’amélioration du contenu), et pas seulement les éditeurs à temps plein. Les articles seraient meilleurs et les informations plus précises et à jour, sans impliquer de personnel supplémentaire. Pour ce faire, vous devez entrer un troisième paramètre : synchroniser les sujets entre les instances.
2 « J'aime »
Salut Volanar,
Si votre site Discourse doit refléter votre site Wordpress, avez-vous nécessairement besoin des deux ?
La façon dont leur demande est formulée, voici comment je vois leur flux :
flowchart
WP <--> Post
Discourse <--> Post
Community --> Discourse
Editors --> WP
D’accord, mais quel est l’avantage d’avoir deux interfaces d’édition pour le même contenu ?
Bien que WordPress puisse gérer le markdown et le fasse, ce n’est pas le défaut pour la plupart des sites, et à moins que le comportement n’ait changé, le markdown est converti en HTML lors de la sauvegarde de l’article. Tout style CSS spécifique est également perdu. Le résultat est que les articles WordPress attrayants perdent une partie de leur fidélité visuelle lorsqu’ils sont visualisés sur un site Discourse.
Permettre à Discourse de remplacer le contenu d’un article WordPress entraverait bon nombre des fonctionnalités de présentation de WordPress. Il y a aussi la question de la gestion des versions et des changements simultanés - le dernier rédacteur gagne, présumons-nous ?
Si vous souhaitez que les éditeurs et les membres de la communauté contribuent à la qualité des mêmes contenus, pourquoi ne pas les modifier au même endroit ?
1 « J'aime »
Parce que le contrôle de qui voit quoi et ne peut pas faire d’autres choses est beaucoup mieux contrôlé sur Discourse, mais du côté de WordPress, il peut y avoir d’autres publications aussi.
Cela pourrait être une raison. Je ne prends parti ni pour le bien, ni pour le mal, ni pour la neutralité.
(Pour moi du moins) il semble qu’ils ne veuillent pas ajouter tout le monde de leur communauté à l’instance WP :
Bien que vous ayez un argument, la modification d’un côté ou de l’autre est probablement préférable à la modification des deux côtés.
Salut @volanar, je vois ce que tu essaies de faire.
Cela ne fera pas partie du plugin WP Discourse dans un avenir prévisible, en partie parce que ce plugin se concentre sur la synchronisation des commentaires Wordpress par opposition au contenu des articles Wordpress, et en partie parce que rendre le plugin WP Discourse bidirectionnel pose des défis difficiles à résoudre dans le cadre de ce plugin et de la manière dont il fonctionne avec Discourse. @Stephen a mentionné certains de ces défis. Il y en a d’autres.
Cela dit, il est potentiellement possible que vous puissiez atteindre votre objectif grâce à l’utilisation du plugin Wordpress ActivityPub et du plugin Discourse ActivityPub, qui, combinés, pourraient, sur le papier, faire ce que vous souhaitez, c’est-à-dire une synchronisation bidirectionnelle du contenu (articles Wordpress et articles Discourse).
Il y a deux grosses mises en garde. Les fonctionnalités bidirectionnelles du plugin Discourse ActivityPub n’ont pas encore été fusionnées dans la branche principale du plugin (la PR est actuellement en cours de révision), et je n’ai jamais testé ce plugin avec le plugin Wordpress ActivityPub. Mais ce que vous suggérez est potentiellement possible en combinant les deux.
En effet, le scénario que vous avez décrit est celui pour lequel le protocole ActivityPub a été développé. Pourquoi est-ce plus possible dans ce contexte par opposition au contexte WP Discourse ? Il y a de nombreuses raisons que je n’aborderai pas ici, mais il suffit de dire que si tel est votre objectif, c’est la voie que vous devriez envisager.
Parce que WordPress prend en charge WPML et que le contenu est traduit en plusieurs langues. WPML est idéal pour suivre les modifications de contenu. Ensuite, WP publie le contenu sur le blog et l’application mobile. C’est-à-dire que WP peut être utilisé comme un CMS headless.
Le sujet principal sera créé dans WP, mais la communauté pourra apporter des corrections et des ajouts au contenu. Il s’agit d’informations techniques et la beauté du contenu n’est pas importante, vous pouvez donc installer le plugin markdown dans WP par défaut pour un format de contenu unique. Idéalement, il est préférable d’utiliser Ghost, Strapi, Squidex ou une autre plateforme, mais cela coûtera de l’argent et ne conviendra pas à tout le monde. La solution doit être universelle pour tous.
J’ai trouvé une bonne option. À la fin du sujet, spécifiez un lien pour modifier côté frontend sur WP. De cette façon, les utilisateurs pourront modifier le contenu eux-mêmes, et le modérateur pourra accepter ou rejeter les modifications.
1 « J'aime »