Après l’arrêt de Discuz, il faut trouver une alternative. J’ai testé plusieurs options. Voici un bref aperçu de mes impressions et des méthodes de migration.

Voici les options classées par ordre de popularité sur GitHub :

Discourse

C’est le forum le mieux classé, mais il est basé sur Ruby on Rails (RoR). Les performances de RoR sont loin d’être excellentes et la consommation mémoire est élevée, donc je l’ai directement écarté.

Par exemple, notre ancien système de connexion était basé sur RoR. Lorsque des robots d’indexation crawlaient notre forum Discuz, chaque message contenait un lien de connexion avec un paramètre from différent. Certains robots peu intelligents les parcouraient tous. Ces pages ne faisaient que générer un formulaire de connexion, mais cela a suffi à faire planter le système RoR. Pendant ce temps, le forum Discuz, lui aussi crawlé, ne montrait aucune perturbation. Si vous êtes habitué à la vitesse et à l’économie de Discuz, préparez-vous et voyez si vous pouvez supporter cela.

Flarum

L’interface est très belle. Basé sur PHP + MySQL, les performances ne devraient pas poser problème en théorie. Cependant, les requêtes SQL du forum ne sont pas optimisées. L’accès à un forum vide pour afficher les premiers messages génère environ 100 requêtes SQL, avec un temps de chargement minimal de 100 ms. Avec une base de données cloud bas de gamme, 200 ms sont normales. Ajoutez à cela le chargement des autres éléments, et l’attente approche la seconde.

NodeBB

Ce forum est basé sur NoSQL + Node.js. Les performances sont excellentes et l’utilisation du CPU est très faible. De plus, il utilise des connexions WebSocket persistantes, ce qui rend les réponses très rapides. La consommation mémoire initiale est d’environ 1 Go, mais elle augmente lentement. Les plugins et l’API sont complets, c’est pourquoi j’ai choisi cette solution.

Apache / Answer

C’est aussi une très bonne option, similaire à Zhihu ou Stack Overflow. Mais je n’ai pas trouvé de moyen de désactiver les fonctionnalités comme “poser une question” ou “accepter une réponse”. Si cela était possible, cela deviendrait un forum centré sur des articles (messages principaux longs), adapté aux forums axés sur des guides plutôt que sur de nombreuses interactions.

Flaskbb / Flaskbb

Un forum en Python, aux performances très correctes, mais qui n’est plus mis à jour depuis longtemps.

rafalp / Misago

On dirait un forum pour la culture otaku au premier coup d’œil. Également en Python, l’auteur a commencé le développement il n’y a que quelques années mais est très assidu. J’ai vu qu’il utilisait la bibliothèque Python SocialAuth, qui permet d’intégrer facilement des connexions via QQ, Weixin, Google, etc., ainsi que l’intégration avec son propre site.

Il y a aussi deux forums développés par des Chinois qui ont l’air intéressants : un, Casbin, qui imite fortement v2ex, et bbs-go ainsi que symphony qui ressemblent à des blogs comme CSDN. Je ne les ai pas testés.

Migration de Discuz vers NodeBB

Si vous avez votre propre site, pour gérer l’authentification avec NodeBB, vous pouvez utiliser l’un de ces deux plugins officiels : nodebb-plugin-session-sharing ou nodebb-plugin-sso-oauth2-multiple.

Pour l’importation depuis Discuz, il faut écrire son propre code. Demandez à une IA de vous écrire un squelette en Python, puis modifiez-le.

Si vous ne devez importer que les messages, parcourez la table posts de Discuz. Chaque ligne est un message. first=1 indique un message de sujet (topic).

Pour les sujets, utilisez l’endpoint NodeBB api/v3/topics/. Pour les réponses, utilisez api/v3/topics/{tid}. Pour les utilisateurs, vous pouvez utiliser l’endpoint de création d’utilisateur. Comme j’utilise session-sharing, j’utilise l’endpoint api/session-sharing/user et la requête pour rechercher un utilisateur est api/session-sharing/lookup?id={passport_id}.

Le taux de traitement de l’API est d’environ 5 requêtes par seconde. Préparez-vous à une migration lente.

Exemple d’appel :

async def create_topic(title, body, timestamp, category, tags, uid):
    # Créer un sujet POST
    data = {
        "cid": category,  # Numéro de la catégorie
        "title": title,
        "content": body,
        "timestamp": int(timestamp),  # Temps en millisecondes
        "tags": tags,
        "_uid": uid   # Auteur du message
    }
    # Clé secrète administrateur de l'API
    headers = {"Authorization": f"Bearer 1239383-3323-2323-2323-asd123123123"}
    # Appel
    async with aiohttp.ClientSession() as session:
        async with session.post(
                'https://xxx.com/api/v3/topics/',
                headers=headers,
                json=data
        ) as response:
            if response.status != 200:
                # Si l'erreur est "Veuillez ajouter du contenu au message, il doit contenir au moins 1 caractère", c'est que le content n'est pas échappé.
                response_text = await response.text()
                raise Exception(f"Error creating topic {title}: {response_text}")
            result = await response.json()
            topic_object = result['response']
            return topic_object['tid']

Notez que publier via l’API suit la même logique que la publication par un utilisateur, et est donc soumis à toutes les limites de caractères du forum. De même, le paramètre timestamp est ignoré pour cette raison, et le message sera publié avec l’heure actuelle. La solution est de modifier l’horodatage à la ligne 16 du fichier src/api/helpers.js. Commentez simplement la ligne data.timestamp = Date.now();. N’oubliez pas de la remettre après la migration, sinon les utilisateurs pourront aussi modifier les dates.

Après cette modification, l’endpoint API pour les réponses api/v3/topics/{tid} acceptera également un paramètre timestamp pour spécifier l’heure.