Comment puis-je modifier directement la base de données Discourse depuis une interface graphique ?

Je cherche un utilitaire convivial capable d’exécuter des requêtes SQL pour nettoyer globalement ma base de données actuelle, qui contient des publications et des utilisateurs importés de deux anciens forums différents. Par exemple, supprimer des sujets, ajouter certains tags à tous les messages contenant une chaîne spécifique dans leur titre, supprimer des utilisateurs ou modifier les accès lorsque les profils utilisateurs ne répondent pas à certains critères, etc.

Existe-t-il quelque chose comme phpMyAdmin permettant de modifier une sauvegarde SQL d’un administrateur Discourse ? Ou même de travailler avec une instance Discourse en direct ?

Je vois qu’il existe un plugin permettant d’exécuter des requêtes dans Discourse, mais il semble qu’il ne permette pas de modifier les données.

Télécharger une sauvegarde (sans les fichiers joints) et la restaurer sur une instance PostgreSQL locale, que vous pourrez interroger avec pgAdmin3, est votre meilleure option.

Oui, le plug-in Data Explorer ne permet pas de modifier les données. Mais je vous suggère de commencer par là de toute façon. Vous pouvez exécuter des requêtes pour identifier si vous rencontrez des problèmes, puis lancer d’autres requêtes pour sélectionner les enregistrements qui doivent être modifiés. De cette façon, vous serez protégé contre le risque d’endommager accidentellement votre base de données.

Je suppose que vous êtes déjà en production. Par conséquent, je serais très prudent avant de modifier la base de données sans une quelconque approbation de l’équipe Discourse.

Une fois que vous serez familiarisé avec la base de données Discourse et que vous connaîtrez l’ampleur du problème, vous pourrez envisager vos options pour apporter les modifications. Il se peut que vous puissiez tout faire directement dans Discourse. Ou alors, si les modifications sont si peu nombreuses, la ligne de commande suffira.

Merci Falco !

Je suis un vrai débutant quand il s’agit d’utiliser quoi que ce soit qui ne repose pas sur le clic et le pointage.

Cependant, j’ai réussi à configurer une instance locale de Discourse (sous Windows 10) en suivant les guides officiels (sans vraiment comprendre grand-chose). Je suppose donc qu’il doit exister quelque part des instructions pour installer pgAdmin3 au même endroit ?

Question idiote, mais est-ce que cette instance de Discourse hors ligne est bien celle vers laquelle je dois restaurer le fichier SQL exporté (ou existe-t-il une autre méthode pour « restaurer » un fichier de sauvegarde de base de données Discourse dans PostgreSQL) ?

Et comment puis-je l’interroger une fois restaurée ? Autrement dit, où et comment pointer pgAdmin3 vers la base de données d’une instance Discourse en cours d’exécution ? Où réside physiquement la base de données d’une instance Discourse en cours d’exécution ? Le fait que l’instance Discourse soit en cours d’exécution verrouille-t-elle la base de données d’une certaine manière ?

Je n’arrive pas à voir de fichiers correspondant clairement à une base de données parmi les fichiers de mon serveur local dans le répertoire ~ /var/discourse.

Merci, Remah.

Je fais l’auto-hébergement de Discourse, je n’ai donc pas accès à l’équipe de Discourse.
Je configure et gère un forum pour une petite communauté, entièrement sur une base bénévole (c’est-à-dire sans budget), et j’importe des données provenant à la fois de MyBB et des forums Yahoo Groups. Ces derniers ont, par exemple, introduit un ensemble d’anciennes notifications e-mail administratives générées automatiquement en tant que sujets dans Discourse, ce qui est assez peu pertinent dans ce contexte.

Il est probable que je doive tester et apporter des modifications globales de manière sporadique et progressive, au fur et à mesure que je découvre de nouveaux problèmes. D’où mon désir de minimiser la courbe d’apprentissage et tout ce qui repose sur l’interface en ligne de commande (CLI) !

J’ai vu votre nom de domaine et je vous ai découvert pour la première fois, donc je comprends dans une certaine mesure votre situation. Je suis à Wellington, au fait, et je mets en place et utilise activement plusieurs forums privés pour des associations caritatives.

Compte tenu de votre temps et de votre expérience limités, je vous suggère de commencer par les outils les plus simples et les plus faciles à utiliser, et de passer au niveau supérieur uniquement si vous y êtes contraint. Maîtriser quoi que ce soit au-delà du premier niveau, qui consiste simplement à utiliser Discourse tel quel, a un coût élevé. Lorsqu’il est utilisé comme prévu, Discourse peut être incroyablement puissant.

  1. L’interface graphique de Discourse avec les fonctionnalités que vous devrez maîtriser de toute façon.

    • Familiarisez-vous avec ce que vous devez utiliser dans Discourse. Vous constaterez peut-être que vous pouvez faire 99 % de ce dont vous avez besoin sans aller plus loin. Il est donc possible que vous n’ayez pas besoin d’aller plus loin.

    • Priorisez les problèmes visibles réels.
      Par exemple, vos anciennes notifications par e-mail ne constituent peut-être pas un problème majeur. Si elles sont sans pertinence, elles disparaîtront, comme prévu, de toute visibilité dans Discourse au fur et à mesure que des sujets plus pertinents seront créés. Il est plus important de faire fonctionner correctement votre forum que de résoudre toutes les erreurs de données.
      Alors, combien de ces notifications e-mail automatisées ont-elles été converties en sujets ?

  2. Le plug-in Date Explorer vous sera utile, c’est donc la prochaine étape pour mieux comprendre la base de données et identifier ce qui doit être fait. Plus tard, il vous aidera pour les rapports, mais il n’est pas absolument nécessaire.

    • L’impossibilité d’apporter des modifications constitue un filet de sécurité, car il y a quelques années, de nombreux utilisateurs abîmaient leurs données avec des mises à jour précipitées.

    • Les requêtes que vous générez pour identifier les enregistrements problématiques ne sont qu’à un pas des commandes SQL permettant de modifier la base de données.

  3. La dernière option sera probablement d’utiliser la ligne de commande et des scripts pour modifier votre base de données.

    • Je préfère prendre le risque d’afficher de mauvaises données plutôt que de risquer d’endommager la base de données en la modifiant manuellement. Cela peut créer une bombe à retardement, car certaines corruptions de données pourraient ne pas être détectées en temps utile.

    • L’utilisation de Data Explorer vous donnera des résultats de requête qui sont de vrais exemples de données et des chiffres quantifiables d’enregistrements. Vous avez plus de chances d’obtenir une réponse correcte de l’équipe et d’autres experts s’ils peuvent comprendre vos données et ce que vous essayez d’accomplir. Ils pourront alors vous conseiller sur la manière la plus simple et la plus sûre de mettre à jour la base de données.

    • Une grande partie de ce dont vous avez besoin se trouve probablement déjà dans des sujets, car d’autres sites rencontrent les mêmes types de problèmes. Vous ne ferez donc que copier le savoir acquis avec difficulté par quelqu’un d’autre.

Exactement. Ne modifiez jamais directement la base de données. Vous le regretterez un jour.

Merci, Remah,

Tout cela semble être des conseils judicieux.
Je pourrais peut-être faire appel à la foule pour trouver une solution partielle, si je parviens à convaincre certains utilisateurs de scanner manuellement et de marquer les sujets à supprimer.

Pour l’instant, le site sur le domaine est essentiellement un espace réservé vierge, pendant qu’un freelance affine le processus d’importation depuis les anciens forums (en ajustant le script d’importation pour MyBB en particulier, afin que, espérons-le, les champs de profil utilisateur personnalisés que j’avais configurés là-bas soient importés avec les utilisateurs et leurs publications. J’espère également que le MyCode présent dans certains posts MyBB sera correctement interprété (pour le moment, les codes de mise en forme sont visibles).

J’ai perdu une semaine à essayer en vain d’effectuer cette importation moi-même, mais je n’ai tout simplement pas réussi à mettre en place un environnement de développement avec toutes les prérequis nécessaires, que ce soit sur une instance Ubuntu sous Windows 10 ou sur une instance basée sur DigitalOcean, conformément au guide officiel d’utilisation du script d’importation MyBB.

Après avoir lutté péniblement, en résolvant un message d’erreur après l’autre, je me suis finalement heurté à un mur infranchissable, dans les deux cas, lorsqu’il s’agissait de rendre la base de données SQL accessible lors de l’exécution de la commande finale Ruby on Rails qui déclencherait l’importation.

Linux et Ruby semblent tous deux avoir été écrits par des sadistes pour des masochistes, tous deux étant étonnamment fragiles et ésotériques. Dans un tel environnement, les risques de problèmes catastrophiques lors de la manipulation de bases de données semblent effectivement élevés !

Je vous plains.

Restez administrateur du forum. :+1:

L’ergonomie a toujours fait défaut dans cet environnement. Je pense que la ligne de commande est encore plus reine qu’il y a 20 ans.

Mais c’est pourquoi j’aime Discourse. L’équipe fait un effort pour rendre le cœur de Discourse nettement plus convivial. Malheureusement, la migration est une option haut de gamme.

Il est presque certain qu’il vaut mieux le faire depuis la console Rails.

Je suppose que cela pourrait dépendre de votre critère de « préférable » ?
Dans mon cas, en tant que débutant, la courbe d’apprentissage la plus faible possible et la complexité minimale d’accès pour quelqu’un qui n’a généralement pas d’environnement de développement configuré et qui ne connaît rien à Ruby (ni d’ailleurs à Linux) seraient des priorités élevées. Cela pourrait être différent si j’avais une autre raison (et le temps) de me familiariser avec ces choses… Dans un monde idéal, il existerait une sorte d’application Windows locale avec une interface graphique permettant d’interroger directement mon installation Discourse hébergée sur Digital Ocean…

Si vous décidez de ne pas apporter les modifications directement à la base de données, vous pourriez trouver certaines des commandes décrites dans ce sujet utiles : Administrative Bulk Operations. Par exemple, il donne des détails sur la façon de taguer des sujets depuis la console Rails. La chose la plus importante est de faire une sauvegarde de la base de données de votre site avant d’exécuter toute commande.

Mon critère pour « meilleur » est « beaucoup moins susceptible de laisser votre base de données dans un état cassé, voire totalement cassé ». Puisque vous êtes un « débutant », vous ne savez pas quelles tables doivent être mises à jour lorsque vous faites… quelque chose.

Quelle que soit votre méthode, assurez-vous de faire des sauvegardes fréquentes.

Un point valable – je vais faire de mon mieux pour trouver d’autres solutions en premier lieu.
Mon ignorance représente un risque majeur dans les deux scénarios, mais peut-on affirmer que l’exécution de modifications de base de données via Ruby est plus sûre que de tenter les mêmes modifications avec pgAdmin4 ?

Le risque de causer des dommages non immédiatement détectés a été évoqué, par exemple – y a-t-il des aspects propres à l’une ou l’autre approche qui pourraient influencer ce risque ?

Dans un coin de ma tête, si je devais un jour décider de prendre ce risque (après avoir pris des sauvegardes appropriées), j’envisageais d’avoir une copie de pgAdmin4 exécutée sur mon droplet Digital Ocean, à laquelle je pourrais accéder directement via une URL dans mon navigateur, plutôt que par l’intermédiaire de fenêtres de console en ligne de commande, éliminant ainsi plusieurs couches de complexité (en supposant bien sûr que cela soit même possible).

En gros, oui. Ruby effectue toute une série de manipulations magiques pour s’assurer que la bonne chose se produit. Par exemple, si vous détruisez (supprimez) quelque chose à partir d’un modèle, il sait quand et quels autres éléments doivent être supprimés. Il existe de nombreuses opérations « sûres » que vous pouvez réaliser avec du SQL brut, mais je fais presque toujours cela dans Rails si c’est possible.

Ah, c’est bon à savoir — merci !

Cela semble potentiellement très utile – merci !

Comment j’ai résolu « Comment puis-je modifier directement la base de données Discourse depuis une interface graphique ? » puisque la réponse ne correspondait pas à ce que je recherchais.

:warning: Ne faites pas cela sur une machine de production.

Cela utilise l’outil d’administration recommandé pour PostgreSQL pgAdmin 4

Cela a été fait sur ma machine locale pour en savoir plus sur Discourse, par exemple : installation, configuration, optimisation, développement de plugins, utilisation de l’API, des webhooks, etc.

Note : Discourse a été installé sur Ubuntu 18.04 via WSL 2 sous Windows 10, conformément au Guide pour les débutants pour installer Discourse sur Windows 10 pour le développement.

Note : WSL 2 ne prend pas en charge systemd par défaut. Problème 457

En utilisant Installer pgAdmin 4 sur Ubuntu 20.04/18.04/16.04 comme modèle.

Utilisation de BASH

$ echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" |sudo tee  /etc/apt/sources.list.d/pgdg.list
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
$ sudo apt update
$ sudo apt install pgadmin4 pgadmin4-apache2

Adresse e-mail de l'utilisateur pgAdmin4 : postgres@localhost
Mot de passe pgAdmin4 : <mot de passe 1>

$ sudo /etc/init.d/apache2 restart
$ sudo ufw allow http
$ sudo ufw allow https
$ hostname -I

Enregistrez <adresse>

$ whoami

Enregistrez <nom d'utilisateur>

Cette étape suivante pourrait ne pas être nécessaire, car je ne savais pas comment obtenir le mot de passe d’un utilisateur de base de données PostgreSQL, n’étant pas un expert de PostgreSQL, ni s’il existait une autre méthode pour configurer la connexion à la base de données requise pour pgadmin4.

$ psql postgres

Utilisation de PSQL

postgres=# ALTER ROLE <nom d'utilisateur> WITH PASSWORD '<mot de passe 2>';  

Utilisation d’un navigateur Internet

http://<adresse>/pgadmin4

Utilisateur : postgres@localhost
Mot de passe : <mot de passe 1>

Une fois pgAdmin4 lancé

Utilisation de pgAdmin4

Créer une connexion de serveur

Onglet : Général
   Nom : Développement Discourse
   Groupe de serveurs : Serveurs
Onglet : Connexion
   Hôte : localhost
   Port : 5432
   Base de données de maintenance : postgres
   Nom d'utilisateur : <nom d'utilisateur>
   Mot de passe : <mot de passe 2>

Ce n’est pas parfait, mais cela fonctionne et c’est mieux que rien. Vos retours et suggestions sont les bienvenus.


Bonus

PostgreSQL
Catalogue des logiciels - Outils d’administration/développement

Je constate que pour la plupart des actions, il est plus facile et un peu plus sûr d’accéder à la console Rails plutôt que d’interagir directement avec la base de données.

Ou, si ce que vous voulez faire est de modifier le mot de passe d’un utilisateur (oh, ce n’est pas ce que vous essayiez de faire, mais c’est toujours un bon exemple), exécutez :

cd /var/discourse
./launcher enter app
rake admin:create

Malgré son nom, cette tâche Rake vous permet de :

  • créer un utilisateur (mais c’est acceptable si l’utilisateur existe déjà)
  • modifier le mot de passe (mais ce n’est pas obligatoire)
  • rendre l’utilisateur administrateur (mais ce n’est pas obligatoire).

Consultez Opérations de masse administratives pour d’autres exemples.

En voici quelques-uns :

users = User.all
me = User.find_by_username('pfaffman')
me = User.find_by_email('jay@literatecomputing.com')
UserEmail.create!(user: me, email: 'myotheraddress@somewhereelse.com')
posts_with_uploads = Post.where("raw like '%upload%'")
Group.create(
  name: "mygreatgroup",
  automatic_membership_email_domains: 'literatecomputing.com',
  primary_group: true,
  title: "Literate Computing Staff",
  grant_trust_level: 4,
  flair_url: 'https://example.com/path.icon.png'
)

Merci pour vos retours. Encore une chose à apprendre pour moi.

Bien que j’aie des décennies d’expérience en développement, je n’ai jamais utilisé Ruby ou Rails. J’ai en fait commencé à programmer avec des cartes perforées à l’université et personnellement avec un Atari 800.