Comme prévu, cela n’est pas apparu dans l’interface graphique. Mais quelles sont les étapes minimales ? Dois-je ajouter des données à d’autres tables, ou y a-t-il un redémarrage à effectuer ?
Je m’attends à ce que quelqu’un dise que ce n’est pas la bonne façon de faire les choses, et je le comprends, mais pour moi, cela pourrait être nécessaire comme je l’expliquerai ci-dessous (certaines de mes hypothèses peuvent être incorrectes, mais voici ma compréhension) :
Tous les scripts d’importation qui importent depuis un autre forum basé sur une base de données supposent pouvoir se connecter à l’autre forum depuis l’instance Discourse. Mais pouvoir accéder à l’autre forum (jforum) depuis l’instance Discourse en production sera difficile, voire impossible. De même, tenter d’installer un environnement de développement Discourse où résiderait l’ancien forum (un serveur très ancien) n’est pas possible.
Je ne comprends pas Ruby on Rails, je ne peux donc pas modifier les scripts existants, mais je comprends SQL.
Je pourrais utiliser l’API (je n’ai que 5000 utilisateurs), mais je souhaite pouvoir utiliser un plugin ou une méthode qui conserve le hachage de mot de passe MD5 plutôt que de demander à tous les utilisateurs de réinitialiser leurs mots de passe. Je ne pense donc pas pouvoir le faire via l’API.
Il existe un script d’importation pour jforum, je peux donc l’utiliser pour examiner le SQL nécessaire afin d’extraire les données de jforum sans problème, puis les placer dans des fichiers CSV à charger dans la base de données.
Les importateurs par lot pourraient offrir un moyen d’ajouter du SQL dans Discourse, mais je peine à voir le SQL requis.
Il semble que l’ajout des utilisateurs soit l’élément clé ; ajouter ensuite les catégories, les sujets et les messages ne devrait pas être trop difficile.
Si c’était le cas, tu ne poserais pas la question.
Les chances que tu te retrouves avec une base de données corrompue sont assez élevées. Et ensuite, personne ne pourra t’aider.
Fais une sauvegarde de ta base de données et restaure-la sur ton serveur Discourse local (ou n’importe où où il peut se connecter — j’ai déjà effectué des imports plus importants avec une base de données distante via ma connexion internet personnelle), puis exécute le script existant.
Ce sera beaucoup plus facile d’utiliser Ruby que tu ne comprends pas que de le maîtriser suffisamment pour comprendre comment écrire le SQL. J’ai appris Ruby bien après avoir écrit mon premier importateur.
C’est un peu condescendant !
Si le script d’importation par lots exécute du SQL (ce que je pense qu’il fait), alors documenter le SQL nécessaire pour créer un utilisateur n’est vraiment pas plus dangereux que d’essayer d’utiliser un script d’importation par lots. Et comme j’ai actuellement une installation Discourse standard, cela ne me dérangeait pas trop si cela était perturbé. Je suppose que j’ai encore beaucoup plus d’années d’expérience en développement que vous.
Ce dont je n’ai pas une grande expérience, ce sont toutes les tâches d’administration. Ma première tentative pour installer un serveur Discourse local a ouvert une boîte de Pandore, et si je ne peux pas me connecter à mon serveur MySQL JForum depuis mon serveur Discourse, je vais devoir installer MySQL également et transférer la base de données. Le script JForum existant n’est pas intégré dans l’arbre de source principal, et je suis sur une très ancienne version de JForum, donc je ne m’attends pas à ce que cela fonctionne.
Je ne voulais pas offenser. Je suppose que tu as manqué le :wink ?
Je parie que tu as raison !
Parfois, un conseil gratuit de quelqu’un qui travaille à temps plein sur Discourse depuis plus de trois ans, a réalisé des dizaines d’importations et a écrit plusieurs importateurs à partir de zéro vaut ce que vous payez.
Mais vous pouvez créer les utilisateurs via l’API, puis insérer les hachages md5 dans un champ personnalisé en utilisant SQL. Vous aurez ainsi le meilleur des deux mondes.
Oui, j’y avais pensé, mais comme je ne comprends pas tout à fait comment fonctionne le hachage MD5, je n’étais pas sûr que ce soit possible. D’accord, je vais essayer.
Je l’ai installé, mais comment redémarre-t-on Discourse ?
Comment insérer le champ personnalisé ? Pouvez-vous fournir la requête SQL, ou cela peut-il être fait via l’API avec la partie "user_fields[1]": "string" ? Je suis actuellement capable de créer des utilisateurs de manière programmatique via l’API, mais j’ignore pour le moment ce champ.
Si vous avez installé le plugin, la valeur du mot de passe passée dans l’appel API de création d’utilisateur est-elle sans importance ?
Non, il prévaudra sur le hachage MD5 dans le champ personnalisé.
Les réponses aux deux autres questions peuvent facilement être trouvées sur ce forum. Si vous souhaitez gagner du temps, nous pouvons effectuer l’importation et/ou l’hébergement pour vous en tant que service payant.
J’ai cherché les deux réponses mais je n’ai rien trouvé. Dans le premier cas, c’est confusant : certaines installations se font en modifiant le fichier YAML puis en relançant Docker, tandis que d’autres, comme celle-ci, semblent s’effectuer directement dans le conteneur Docker. Il n’est pas clair ce que signifie « redémarrer » dans ce contexte.
Je ne parviens pas à trouver de code SQL pur sur ce forum.
Je suis surpris de voir une telle pression pour vendre des services payants pour utiliser ce logiciel open source. Je n’ai jamais vu cela quand je posais des questions sur Stack Overflow.
J’adore réfléchir, innover et contribuer. Mais je dois aussi gagner ma vie, ce qui signifie que je dois tracer une limite quelque part. J’essaie de la placer là où j’ai l’impression de faire du travail plutôt que de réfléchir, d’innover et de contribuer.
Rechercher la requête SQL pour un champ personnalisé utilisateur, c’est du travail pour moi. Et comme vous êtes un développeur expérimenté, je suppose que vous pourrez le trouver vous aussi
Bien sûr, je peux essayer de le comprendre, mais il n’y a pas de mal à demander, puisque ce n’est pas
facilement trouvable sur ce forum.
En ce qui concerne l’autre question, elle reste floue pour moi.
Je ne m’attends pas à ce que vous fassiez mon travail à ma place ; en revanche, je trouve généralement frustrant que la documentation suppose beaucoup de la part des utilisateurs.
OK, question 2, un exemple d’ajout d’un champ personnalisé import_pass pour l’identifiant utilisateur 5 (l’identifiant utilisateur peut être consulté dans la table user_emails ou l’identifiant de la table users)
D’accord, je l’ai trouvé ./launcher restart app
mais cela ne semble pas redémarrer. Je peux accéder à l’application et me connecter à la base de données, mais je ne peux pas me connecter au site web. Je vais peut-être simplement reconstruire et recommencer.
J’ai donc exécuté ./launcher rebuild app et tout est de nouveau opérationnel.
Je pensais que cela recréerait la base de données, mais ce n’est pas le cas. Je suppose que c’est parce que la base de données réelle persiste en dehors de Docker et que rebuild ne reconstruit que l’application Docker. Je constate également que le plugin dataexplorer que j’ai ajouté (en modifiant le fichier YAML) est toujours présent. Mais le plugin passwordmigration est-il toujours là ou est-il effacé par rebuild ? Il n’y a certainement rien dans la section des plugins de la page d’administration.
Bon, j’ai essayé d’installer passwordmigration, puis j’ai redémarré à nouveau, et une fois de plus, mon site est hors ligne. Il semble que passwordmigration rompe quelque chose ?
J’ai donc reconstruit à nouveau, et tout fonctionne (mais le plugin passwordmigration manque maintenant). Si j’exécute ./launcher restart app sans installer passwordmigration au préalable, le redémarrage se déroule correctement. Il semble donc y avoir un problème spécifique avec passwordmigration dans ma configuration.
La dernière fois que j’ai essayé, le plugin passwordmigration était incompatible avec l’exécution d’une importation, vous devrez donc l’installer après avoir effectué l’importation.
Il se peut qu’il cause la rupture de votre reconstruction, mais cela serait assez surprenant, car Richard l’utilise dans son hébergement. Je vous recommande de l’installer dans app.yml, tout comme vous l’avez fait pour l’explorateur de données, une fois l’importation terminée.
Étrange, j’ai supprimé la base de données et exécuté ./discourse-setup, ce qui a donné une installation toute neuve, tout allait bien.
J’ai installé migrationpassword avec rake et redémarré, mais le site échoue à nouveau avec une erreur 502 !
Le plugin DataExplorer était toujours présent, donc je l’ai supprimé, reconstruit, ça a marché, puis j’ai réinstallé migrationpassword et l’erreur 502 réapparaît.
C’est vraiment déroutant car cela fonctionne clairement pour d’autres, mais pas sur mon installation vanilla.
Je vais essayer de l’installer en modifiant le fichier app.yml la prochaine fois.
(Les achats de Noël ont pris le dessus), mais j’ai enfin essayé d’installer migratepassword en modifiant app.yml et en reconstruisant, et… ça a fonctionné !
Mais l’option bundle exec rake plugin:install repo=http://github.com/[Communiteq](https://www.communiteq.com) (anciennement DiscourseHosting)/discourse-migratepassword ne fonctionne pas sur mon installation vanilla. Il faudrait peut-être vérifier ou supprimer cela dans le README.md de GitHub - communiteq/discourse-migratepassword: Support migrated password hashes · GitHub
