Merci @debryc 
Je tiens à préciser que ce sont tous les membres de Pavilion, et pas seulement moi, qui entretenons notre travail. Notre coopérative est un effort collectif.
J’ajouterais également que nous venons de rendre open source notre plugin Landing Pages, qui permet de créer des pages entièrement indépendantes, soutenues par une instance Discourse ; une autre façon de répondre au besoin discuté dans ce sujet. Ce plugin sépare le frontend des pages du client Discourse (c’est-à-dire qu’il ne charge pas l’application Discourse), tout en permettant une intégration facile via un backend commun (c’est-à-dire le serveur Discourse).
Nous commençons déjà à utiliser ce plugin avec certains de nos clients pour répondre à des besoins similaires à ceux discutés ici. Nous envisageons également de développer des packages open source généralisés et faciles à utiliser, basés sur des cas d’usage courants pour un CMS associé à une communauté, utilisables avec ce plugin.
Voici la liste actuelle des cas d’usage que nous avons en tête pour bénéficier de cette approche.
-
Blog (je travaille actuellement sur celui-ci). Rédigez du contenu dans Discourse, puis présentez-le sur une page de blog entièrement indépendante, que vous pouvez personnaliser comme un vrai blog (c’est-à-dire comme WordPress ou Ghost).
-
Pages de produits, services ou fonctionnalités (comme les nôtres). Affichez des produits, des services ou des fonctionnalités qui peuvent inclure du contenu ou des données (catégories, tags, sujets, utilisateurs, etc.) provenant de votre instance Discourse.
-
Pages “Équipe” (comme les nôtres). Une page pour votre équipe, utilisant l’appartenance (et les données des utilisateurs) d’un groupe d’utilisateurs Discourse.
-
Pages d’événements, pour lister et afficher les données d’événements de votre instance Discourse sur une page d’atterrissage d’événement stylisée. Les “données d’événements” ici pourraient être une combinaison de données du plugin Discourse Calendar, de catégories, de sujets, d’utilisateurs (par exemple, les RSVP) et de lieux (en utilisant notre plugin Locations).
Nous sommes intéressés par d’autres cas d’usage généralisables que les gens pensent bénéficieraient de cette approche. Je note dès maintenant qu’il existe certains cas d’usage que nous avons déjà envisagés et qui sont moins susceptibles de bénéficier de cette approche à ce stade :
-
Boutique. Bien qu’il puisse y avoir une page intégrant des éléments d’une boutique, les boutiques en ligne nécessitent un large éventail de fonctionnalités qui exigeront toujours une solution dédiée comme WooCommerce ou Shopify.
-
Base de connaissances. Ce besoin est déjà bien couvert par des solutions comme le plugin Knowledge Explorer. Une page d’atterrissage peut afficher un sous-ensemble d’une base de connaissances, mais reproduire intégralement les fonctionnalités d’un outil comme le plugin Knowledge Explorer (ou simplement les listes de sujets Discourse) serait contre-productif.
Nous sommes également intéressés à collaborer avec toute personne souhaitant développer de telles pages, que ce soit dans le cadre d’un projet de développement en soi (par exemple, pour améliorer ses compétences), pour sa communauté, ou même pour les vendre. Nous prévoyons de publier nos propres packages open source gratuits pour chaque cas d’usage à moyen terme (4 à 6 mois).
Le plugin Landing Pages, ainsi que les pages de Pavilion, seront toujours 100 % open source et gratuits. Cependant, il s’agit d’une structure généralisable que toute personne ayant des connaissances en HTML et CSS pourrait utiliser pour développer un “pack de pages” si elle le souhaitait. J’ajouterai prochainement un “guide développeur” à la documentation Knowledge pour ce plugin.
Le plugin Landing Pages prend déjà en charge l’hébergement de pages dans des dépôts privés, de la même manière que le système de thèmes de Discourse (en effet, en coulisses, il est basé sur et étend le système de thèmes de Discourse). Cela signifie qu’il est déjà possible de vendre l’accès à un pack de pages d’atterrissage si vous le souhaitez. Cela pourrait rendre intéressant pour d’autres développeurs de créer de tels packs.
Cette approche ne répondra pas à tous les besoins de gestion de contenu associés à un forum, mais elle pourrait servir un sous-ensemble de manière très efficace, en particulier ceux que nous voyons régulièrement chez les communautés plus petites et indépendantes, car elle éliminerait le besoin d’instances séparées et, surtout, le besoin de partager des données entre ces instances via des protocoles d’authentification (c’est-à-dire le partage de données d’utilisateur lors de la connexion), des webhooks ou d’autres méthodes de partage de données.
Cela pourrait réduire les coûts et l’administration, en particulier pour les petites communautés cherchant à gérer du contenu relativement contenu ou ciblé, ou des pages statiques, en parallèle de leur forum. Ce ne sera jamais un remplacement direct de WordPress ou d’autres systèmes de gestion de contenu, mais nous espérons pouvoir rendre certains cas d’usage significativement plus faciles.
