J’ai un site WordPress avec environ 1000 anciens articles. Je souhaiterais créer en masse des fils de discussion de commentaires Discourse pour chacun d’eux. Il semble que je puisse modifier et enregistrer chaque article, ce qui créerait un nouveau fil de commentaires si les paramètres du plugin Discourse pour WordPress sont correctement configurés.
Mais… je préférerais éviter d’ouvrir et d’enregistrer 1000 articles.
Je peux facilement récupérer les identifiants et les titres des articles nécessaires depuis la table wp_post. Peut-être que quelqu’un sait comment écrire une requête SQL pour Discourse qui créerait ces nouveaux fils avec les données nécessaires issues de wp_posts ?
Oui, j’utilise le plugin et il est configuré pour l’automatisation, mais pour qu’un post « automatiquement » génère un fil de commentaires dans Discourse, le post WordPress doit être mis à jour, par exemple : ouvert pour édition puis sauvegardé.
En tout cas, non, je pense qu’il serait beaucoup plus simple d’interroger les données dont j’ai besoin directement dans la base de données MySQL de WordPress et de les importer dans la base de données Discourse via SQL. Je ne connais tout simplement pas du tout la structure de la base de données Discourse et j’espère pouvoir trouver quelqu’un qui la maîtrise.
Je pourrais peut-être écrire un script bash pour le WP-CLI afin d’ouvrir et de sauvegarder tous les posts. lol. Peut-être que je vais le faire.
Le problème, c’est que votre site WordPress ne disposerait pas des informations nécessaires pour afficher les bons liens, le nombre de commentaires, etc., si vous le faites côté Discourse. Je n’ai pas non plus de solution pour le faire d’un côté ou de l’autre, mais je pense que vous devriez concentrer vos efforts sur WordPress.
Si les outils en ligne de commande de Wordpress vous permettent d’itérer sur les posts et de les enregistrer d’une manière qui déclenche le plugin Discourse pour créer les sujets comme vous le souhaitez, c’est certainement ce que je ferais. Ce n’est probablement pas très efficace, mais pour une tâche ponctuelle, n’importe quel surcoût prendra moins de temps que d’essayer de trouver une solution « meilleure ».
Comme d’autres l’ont mentionné, la méthode la plus simple pour le faire actuellement consiste à utiliser le plugin WP Discourse. Mettre à jour directement les bases de données de chaque instance soulève deux problèmes potentiels :
Cela nécessite de comprendre toutes les données et métadonnées stockées sur chaque instance.
Les données et métadonnées sont interdépendantes, c’est-à-dire qu’après la publication réussie d’un article depuis WordPress vers Discourse, l’ID de l’article dans Discourse est enregistré dans un champ de métadonnées d’article dans WordPress.
Si vous étiez déjà familier avec les points 1 et 2, alors oui, mettre à jour directement les bases de données pourrait être une bonne option. Cependant, comme ce n’est pas votre cas, ce n’est pas une bonne idée, sauf si vous souhaitez consacrer du temps à apprendre cela uniquement dans ce but. Dans cette optique, vous pourriez engager quelqu’un pour le faire à votre place, mais je vous recommande plutôt d’utiliser simplement les fonctionnalités du plugin WP Discourse.
L’utilisation du plugin WP Discourse présente l’avantage supplémentaire d’avoir déjà configuré la journalisation pour la publication via WP Discourse, ce qui signifie que vous obtiendrez des informations détaillées et spécifiques à chaque article en cas d’échec de l’une des publications.
Il est vrai que cela entraînera environ 1 000 requêtes POST vers votre instance Discourse, car le plugin WP Discourse ne publie qu’un seul sujet à la fois. Cependant, considérant qu’il s’agit d’une migration ponctuelle, vous pouvez gérer cela en divisant le processus en lots et en ajoutant des pauses (c’est-à-dire des sleep) dans le script. Je vous recommande de vérifier manuellement après les premiers lots que tout fonctionne comme prévu.
En ce qui concerne le script lui-même, vous utiliserez la méthode WPDiscourse\DiscoursePublishpublish_post_after_save pour chaque article, c’est-à-dire dans une boucle (avec un lotissement et des pauses appropriés).
Je ne savais pas qu’il y avait des modifications de base de données des deux côtés. C’est intéressant. Je connais très bien la base de données de WordPress. Trop bien, sans doute. Je me tourne souvent vers la base de données en premier lieu, alors que je devrais probablement utiliser d’autres approches.
Oui, je suis un fou obsédé par les bases de données. J’adore la conception et la création de bases de données. Mais… je ne connais absolument pas la base de données de Discourse (pour l’instant). Donc…
Ah oui… une journalisation appropriée est une chose merveilleuse.
Oui, excellent. Je considérerai cela comme la réponse appropriée, car c’est exactement ce dont j’avais besoin.
Cependant…
Ce que j’ai fini par faire, c’est utiliser l’outil WP cli comme suit :
$wp post update 396 398 402 {plusieurs autres ici} --tags_input=discourse
Avant cela, j’ai récupéré une liste d’identifiants de ligne à partir de la table wp_posts où post_status = ‘publish’ et post_type = post.
J’ai donné cette liste à la commande wp post, et cela a pris environ 500 ms par ligne sur un serveur à 4 cœurs. Si je spécifiais plus de 20 lignes environ, Discourse… ???.. mais après cela, aucun lien supplémentaire n’était créé. J’ai donc alimenté le processus par lots de 20, avec un délai de 30 secondes, et j’ai travaillé sur d’autres projets.
Donc, cette réponse est un véritable hack, mais pour moi (n’ayant pas encore la réponse de @angus), c’était la voie la plus directe.