Passer d'une structure Wordpress + Discourse à un site Discourse uniquement ?

Général
1
Bonjour !

Avant de lire ce qui suit, vous pouvez jeter un œil à Moved from PluXml and phpBB to Wordpress and Discourse, my all-new experience 🎉, mais ce n’est pas obligatoire, je ferai un récapitulatif.

Ce que nous avons actuellement.

WP est connecté à Discourse via WP Discourse. WP est également le client DiscourseConnect, et les actualités WP sont automatiquement publiées sur Discourse dans une catégorie dédiée. C’est tout ce que fait le plugin pour nous.

  • Le site WP est principalement axé sur les actualités et les pages d’information statiques.

  • Le forum Discourse est… Un forum. Où la communauté se rencontre, discute et s’organise parfois.

La Question

Je me suis demandé : “Quel est vraiment le but du site web ? La valeur ajoutée est faible, et une grande partie des fonctionnalités du site pourrait être réalisée dans Discourse. Alors, pourquoi s’embêter avec deux plateformes ?”

Notez que je ne fais que commencer ma réflexion. Mais je commence à penser que ce pourrait être une bonne idée de se débarrasser de WordPress dans notre cas.

Alors, quels sont les avantages du site web ? Il a une mise en page épurée, axée sur les actualités. Il a de petites fonctionnalités qui semblent sympas mais sont peut-être inutiles. L’iframe Facebook de la fédération sportive. Un bouton magazine. L’activité récente du forum. Le calendrier des événements (une solution personnalisée). Et de nombreuses pages d’information statiques sur le monocycle.

Qu’est-ce qui ne peut pas être fait dans Discourse ? Pratiquement rien.

La principale préoccupation serait de rendre les actualités plus visibles sur notre forum. Il n’y a pas de nouvelles informations chaque semaine, mais elles sont importantes dans la communauté française du monocycle et devraient être visibles.

J’en ai discuté avec deux personnes impliquées dans ce forum/site. Ils pensent que se débarrasser de WP pourrait être une bonne idée si nous ne perdons rien d’important que le site web nous apporte.

Les aspects techniques.

  • L’en-tête Discourse personnalisé resterait tel quel.

  • Les actualités pourraient utiliser News Plugin 📰. Pas comme page principale, car le contenu du forum ne serait pas disponible avant de cliquer sur un bouton “forum” (comme Elektronauts) et nous voulons également mettre l’accent sur l’activité de la communauté en ligne. Je n’ai pas encore essayé le plugin d’actualités cependant.

  • Cependant, nous aimerions avoir des actualités sur la page d’accueil du forum. Je me souviens avoir vu un plugin ou un composant de thème qui affichait certains messages dans une bannière en haut des sujets, mais je me trompe peut-être. Existe-t-il une solution existante pour cela ? La meilleure utilisation pour nous, je pense, serait d’avoir quelque chose comme les 3 dernières actualités avec une miniature et un extrait en haut de la page d’accueil, sous l’en-tête, et que nous puissions basculer cette bannière afin qu’elle ne nous dérange pas si nous avons déjà lu ces sujets.

  • Les pages statiques du site web pourraient être des sujets ou des pages publiées.

  • Le wiki pourrait utiliser la fonctionnalité wiki de Discourse.

  • Nous n’avons pas besoin de la newsletter (le résumé de Discourse la remplacerait), et mon co-administrateur ne voit pas de réel intérêt au flux de publications Facebook intégré de la fédération sportive, ainsi qu’à d’autres choses.

  • Nous avons une catégorie d’événements (solution personnalisée), qui est un peu vide ces jours-ci, mais qui a son utilité, et nous aimerions conserver le type de catégorie d’événements avec des fonctionnalités spécifiques.

J’ai vu et essayé plusieurs plugins d’événements/calendrier par le passé :

Certains étaient un peu difficiles à comprendre ou à configurer, et mes besoins étaient un peu différents lorsque je les ai essayés, donc je devrais réessayer.

Avantages et inconvénients de ne garder que Discourse

Avantages

  • Fini les problèmes potentiels avec WP, ses nombreuses extensions/thèmes/code personnalisé maladroit [^code] et la compatibilité WP/Discourse lors de la publication de messages.

[^code] : vous ne voulez pas le regarder ; n’essayez même pas d’y penser, j’ai déjà honte

  • Une seule plateforme à considérer et sur laquelle se concentrer

  • Toutes les données seront organisées dans une seule base de données, ce qui simplifiera les choses si nous devons un jour déplacer toutes nos affaires (même Discourse n’est pas éternel… Ou l’est-il ? :face_savoring_food:)

Inconvénients

  • Un peu de travail pour “déplacer” certaines choses de WP vers Discourse

  • Besoin de trouver des solutions appropriées pour quelques fonctionnalités

  • Nécessité de configurer des redirections 301

Votre avis, réflexions, conseils

Je pense avoir bien expliqué ce que je vise. Je serais ravi d’entendre toutes suggestions, conseils, etc., concernant cette possible transition de WP+D vers D.

6 « J'aime »
2

Je pense que cela se résumerait probablement à la quantité de trafic générée par chaque site et à votre budget.

Discourse peut absolument faire tout ce qui précède, mais si vous servez une tonne de contenu à des utilisateurs anonymes sur le site WordPress, votre coût par vue de page est considérablement plus bas.
Un VPS à 5 configuré correctement peut servir des millions de vues de pages en lecture seule sans effort, c'est là que WordPress excelle. Le même trafic nécessiterait considérablement plus de ressources s'il était servi via Discourse. WordPress reste un outil incroyablement efficace si vous vous souciez de telles choses. Configurée correctement, elle est également très performante pour organiser le contenu que vous proposez aux moteurs de recherche. J'ai un client qui paie actuellement DO environ 100 /mois pour les deux. Lorsque nous avons envisagé de déplacer les choses en gros vers Discourse, les coûts d’exploitation auraient été d’un ordre de grandeur supérieur, il est sûr de dire que ce travail n’a pas eu lieu.

3 « J'aime »
3

De grandes inquiétudes. J’aurais dû mentionner des informations à ce sujet.

Ce site web est très spécialisé. Le trafic est faible par essence. Il ne coûte rien en bande passante, en espace disque ou autre. Les deux sites fonctionnent sans problème sur mon VPS avec d’autres choses web et je fais tout cela bénévolement. :slight_smile:

L’aspect SEO serait intéressant à étudier cependant. Je n’y avais pas pensé. :thinking:

2 « J'aime »
4

utilise actuellement un backend CMS headless Strapi + un frontend Next.js hébergé sur Vercel.

Il dispose également d’un forum Discourse :
https://forum.monerochan.news/
J’envisage également de supprimer complètement le backend Strapi et d’utiliser simplement Discourse comme CMS headless.

donc ce problème pourrait être résolu en hébergeant la “page de destination” / les pages les plus visitées de manière headless sur quelque chose comme Vercel.
Même sous sa forme actuelle, Discourse pourrait presque fonctionner comme un CMS headless : nous pouvons simplement ajouter .json à l’URL du sujet et obtenir les données brutes / markdown du message.

Le seul problème serait les liens permanents, les listes de sujets organisées et un système de publication + permissions pour les auteurs et les éditeurs. Une partie pourrait être réalisée avec des groupes et des catégories, mais ce serait bien s’il y avait juste une catégorie d’article / d’aperçu d’article.

Peut-être devrions-nous créer un plugin pour cela :thinking:

@Canapin merci pour le sujet ! Excellente lecture :grinning: :+1:

4 « J'aime »
5

Cela suppose qu’il n’y a que la page d’accueil qui sert du contenu semi-statique. Dans mon exemple ci-dessus, le site compte plus de 10 000 articles et pages.

1 « J'aime »
6 
export const getStaticProps: GetStaticProps = async ({params}) => {
  // Run API calls in parallel
  const id = params?.id

  if (!id) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }
  const qs = require('qs');
  const query = qs.stringify({
    populate: '*',
  }, {
    encodeValuesOnly: true, // prettify URL
  });
  const article = await fetchAPI("/api/articles/" + params.id + "?" + query)
  if (!article.data) {
    return {
      redirect: {
        destination: '/',
        permanent: false,
        // statusCode: 301
      },
    }
  }

  return {
    props: { article },
    revalidate: 1,
  }
}

J’utilise ce code dans le frontend nextjs pour récupérer les articles. Il mettra donc en cache l’article pendant 1 seconde, puis le réactualisera. L’instance discourse ne recevrait donc qu’une seule requête par seconde si nous utilisions cette méthode.

Il est imaginable de faire cela non seulement pour une catégorie spéciale gérée par un groupe spécial d’utilisateurs auteurs et éditeurs.
Cela pourrait être fait pour tout le contenu. Le backend strapi de monerochan.news fournit également du markdown (tout comme discourse). Nous pourrions donc utiliser exactement le même code pour récupérer les données des articles (il suffit d’ajouter .json à l’URL normale du sujet) et les afficher.
Évidemment, les fonctionnalités interactives de discourse manqueraient dans ce cas. Mais nous pourrions simplement y mettre un bouton qui dirait quelque chose comme : commenter ! et cela redirigerait vers la page discourse. Les pages Nextjs se chargent également très rapidement et sont optimisées pour le référencement.

donc je suppose qu’il existe deux situations : 1. Un site d’actualités avec une catégorie spéciale qui est organisée par des auteurs et des éditeurs. 2. Un forum discourse normal avec du contenu généré par les utilisateurs.
Il pourrait également y avoir un mélange des deux cas.

Dans les deux cas, la construction d’un frontend headless pourrait présenter de nombreux avantages.

1 « J'aime »
7

Si vous rencontrez des difficultés pour effectuer l’une des opérations ci-dessus à l’aide du plugin News, du plugin Landing Pages ou du plugin Events, vous pouvez toujours me le faire savoir. Je serai heureux de vous aider.

Concernant le plugin Events, vous devriez nous contacter car nous recherchons actuellement d’autres cas d’utilisation à implémenter pour notre v2 qui sortira bientôt. Remplissez cet assistant :

2 « J'aime »
8

C’est une idée intéressante si je comprends bien. En gros, vous conserveriez votre forum tel quel, et en plus, vous auriez un site web fait maison dont le contenu proviendrait des données du forum via l’API de Discourse. C’est bien ça ?

@Stephen, WordPress a en effet des arguments valables.

WP se charge très rapidement, surtout si vous utilisez un système de cache, alors que Discourse doit charger toute l’application, ce qui prend toujours un certain temps à l’ouverture.

Mon site https://monocycle.info se charge rapidement et la navigation d’une page à l’autre est quasi instantanée.

L’idée de supprimer WordPress vient de plusieurs raisons que j’ai énumérées, mais j’ai oublié d’ajouter que j’aimerais rendre le forum plus visible, et plus évident. Je veux que les gens voient qu’il y a une communauté active dès qu’ils atterrissent sur le site.
L’inscription et la publication sur Discourse sont une expérience agréable et sans douleur, tant sur ordinateur que sur mobile.

Je pourrais conserver WP pour la page d’accueil uniquement (ou pas beaucoup plus), et déplacer la plupart du contenu vers les sujets/pages publiées de Discourse.

Super ! Je dois jeter un autre coup d’œil à votre plugin avant de remplir votre assistant afin de savoir exactement quelles fonctionnalités il propose et comment il fonctionne globalement. :+1:

1 « J'aime »
9

Qu’en est-il d’intégrer davantage de contenu communautaire sur le site WordPress ? Augmenter la visibilité de cette façon.

10

Une idée plus précise ? Lorsque nous arrivons sur la page d’accueil, nous avons un lien « Discussions » et une liste des derniers sujets créés.

image
image1173×1128 379 KB

11

Oui ! C’est exactement ce que je veux dire ! Il n’y a pas grand-chose à faire du côté de Discourse non plus ! Si vous ajoutez .json à n’importe quel lien de sujet, vous avez déjà l’API !
Regardez le sujet dont nous parlons actuellement, par exemple :
https://meta.discourse.org/t/go-from-a-wordpress-discourse-structure-to-a-discourse-site-only/247273/8.json?include_raw=true

Remarquez le .json et include_raw=true à la fin. C’est ainsi que vous pouvez même obtenir le markdown du message en plus du HTML “cuit”.

Strapi utilise également un éditeur markdown, je peux donc littéralement utiliser le même code qu’auparavant.

Screenshot 2022-12-12 at 13-05-29 https __meta.discourse.org
Screenshot 2022-12-12 at 13-05-29 https __meta.discourse.org1315×933 138 KB

2 « J'aime »
12

Cela m’a littéralement fait sauter de ma chaise. D’après ce que j’ai compris en utilisant : .json et include_raw=true avec une sorte d’automatisation (n8n), nous pourrions techniquement réacheminer tout Discourse vers un Hugo en poussant la balise meta et le markdown directement dans un dépôt git ??

1 « J'aime »