Welche sind die mindestens erforderlichen Tabellen, in denen Zeilen hinzugefügt werden müssen, um einen Benutzer zu erstellen, der dann in Discourse als aktiv sichtbar ist?
Ich habe gerade eine Zeile in user_emails eingefügt:
Es ist nicht überraschend, dass er nicht in der GUI erschienen ist. Aber was sind die Mindestschritte? Muss ich weitere Tabellen füllen, oder muss ich etwas neu starten?
Ich erwarte nun, dass jemand sagt, dies sei nicht der richtige Weg, und ich verstehe das. Aber für mich könnte es so sein, wie ich unten erkläre (einige meiner Annahmen mögen falsch sein, aber so verstehe ich es):
Alle Importskripte, die Daten aus einem anderen Forum-Datenbank importieren, erwarten, dass sie von der Discourse-Instanz aus eine Verbindung zu diesem anderen Forum herstellen können. Da es jedoch schwierig bis unmöglich ist, von der Live-Discourse-Instanz aus auf das andere Forum (jforum) zuzugreifen, ist auch das Installieren einer Discourse-Entwicklungsumgebung, in der sich das alte Forum befindet (ein sehr alter Server), nicht möglich.
Ich verstehe Ruby on Rails nicht, daher kann ich die vorhandenen Skripte nicht anpassen, aber ich verstehe SQL.
Ich könnte die API nutzen (ich habe nur 5000 Benutzer), aber ich möchte eine Methode haben, bei der der MD5-Passworthash erhalten bleibt, ohne dass alle Benutzer ihre Passwörter zurücksetzen müssen. Daher glaube ich nicht, dass dies über die API möglich ist.
Es gibt ein jforum-Importskript, mit dem ich problemlos die erforderlichen SQL-Befehle ansehen kann, um Daten aus jforum zu extrahieren, um sie dann in CSV-Dateien zu speichern und in die Datenbank zu laden.
Die Bulk-Importer bieten möglicherweise einen Weg, SQL direkt in Discourse einzufügen, aber ich sehe den SQL-Code nicht klar.
Es scheint, dass das Hinzufügen der Benutzer der Schlüssel ist; das Hinzufügen von Kategorien, Themen und Beiträgen sollte dann nicht so schwierig sein.
Die Wahrscheinlichkeit, dass du am Ende eine beschädigte Datenbank hast, ist ziemlich hoch. Und dann wird niemand dir helfen können.
Sichere deine Datenbank und stelle sie auf deinem lokalen Discourse-Server wieder her (oder überall dort, wo eine Verbindung möglich ist – ich habe größere Importe mit einer entfernten Datenbank über meine Heim-Internetverbindung durchgeführt) und führe dann das vorhandene Skript aus.
Es wird viel einfacher sein, Ruby zu verwenden, das du nicht verstehst, als es so gut zu verstehen, dass du herausfindest, wie man das SQL schreibt. Ich habe Ruby erst lange nach dem Schreiben meines ersten Importers gelernt.
Das ist doch etwas herablassend!
Wenn das Bulk-Import-Skript SQL ausführt (wie ich vermute), dann ist die Dokumentation des erforderlichen SQL zum Erstellen eines Benutzers nicht gefährlicher als der Versuch, ein Bulk-Import-Skript zu verwenden. Da ich derzeit eine Vanilla-Discourse-Installation habe, würde es auch nicht allzu sehr ins Gewicht fallen, wenn sie beschädigt würde. Ich vermute, dass ich mehr Jahre an Entwicklungserfahrung habe als du.
Was mir jedoch an großer Erfahrung fehlt, sind alle Admin-Aufgaben. Mein erster Versuch, einen lokalen Discourse-Server zu installieren, hat eine ganze Kiste voller Probleme geöffnet. Wenn ich von meinem Discourse-Server keine Verbindung zu meinem JForum-MySQL-Server herstellen kann, muss ich auch MySQL installieren und die Datenbank übertragen. Das bestehende JForum-Skript ist nicht im Haupt-Quellbaum eingecheckt, und ich verwende eine sehr alte Version von JForum, also erwarte ich nicht, dass es funktioniert.
Ich wollte niemanden beleidigen. Vielleicht hast du das übersehen?
Da hast du wahrscheinlich recht!
Manchmal ist kostenlose Beratung von jemandem, der seit über drei Jahren Vollzeit mit Discourse arbeitet, Dutzende Importe durchgeführt und mehrere Importer von Grund auf neu geschrieben hat, genau so viel wert, wie man dafür zahlt.
Wie wäre es mit der Einrichtung eines SSH-Tunnels?
Inkonsistent, vielleicht. Beschädigt, nein.
Aber Sie können die Benutzer über die API erstellen und dann die MD5-Hashes in einem benutzerdefinierten Feld per SQL einfügen. So haben Sie das Beste aus beiden Welten.
Ja, ich hatte diesen Gedanken, aber da ich nicht ganz verstehe, wie die MD5-Hashing-Funktion arbeitet, war mir nicht klar, ob das möglich ist. Okay, ich werde es versuchen.
Danke, ich habe ein paar Fragen, bei denen ich hoffe, dass Sie mir helfen können.
Installation
Führen Sie in Ihrem Discourse-Verzeichnis bundle exec rake plugin:install repo=http://github.com/[Communiteq](https://www.communiteq.com) (ehemals DiscourseHosting)/discourse-migratepassword aus
Starten Sie Discourse neu
Ich habe es installiert, aber wie starte ich Discourse neu?
Wie füge ich das benutzerdefinierte Feld ein? Können Sie mir das SQL angeben, oder kann dies über die API mit dem Teil "user_fields[1]": "string" erfolgen? Ich kann Benutzer derzeit programmatisch über die API erstellen, ignoriere dieses Feld jedoch momentan.
Wenn das Plugin installiert ist, ist der Wert des Passworts, der als Teil des API-Aufrufs zum Erstellen eines Benutzers übergeben wird, irrelevant.
Nein, es setzt sich im benutzerdefinierten Feld gegenüber dem MD5-Digest durch.
Die Antworten auf die anderen beiden Fragen finden Sie ganz einfach in diesem Forum. Wenn Sie Zeit sparen möchten, können wir den Import und/oder das Hosting als kostenpflichtigen Dienst für Sie übernehmen.
Ich habe nach beiden Antworten gesucht, konnte sie aber nicht finden. Im ersten Fall ist es verwirrend, dass einige Installationen durch Bearbeiten der YAML-Datei und anschließendes Neustarten von Docker erfolgen, während andere, wie hier, innerhalb des Docker-Containers installiert werden. Es ist nicht klar, was „Neustart
Ich liebe es, mitzudenken, zu innovieren und beizutragen. Aber ich muss auch meinen Lebensunterhalt verdienen, und das bedeutet, dass ich irgendwo eine Grenze ziehen muss. Ich versuche, diese dort zu ziehen, wo ich das Gefühl habe, nur noch Arbeit zu verrichten, statt zu innovieren, beizutragen und mitzudenken.
Die SQL-Abfrage für ein benutzerdefiniertes Feld nachzuschlagen, ist für mich Arbeit. Da du ein erfahrener Entwickler bist, schätze ich, dass du das auch herausfinden kannst
Na klar, ich kann es versuchen und herausfinden, aber es schadet nicht zu fragen, da es nicht
einfach auf diesem Forum zu finden ist.
Was die andere Frage betrifft, ist sie für mich nach wie vor unklar.
Ich erwarte nicht, dass du meine Arbeit für mich erledigst. Andererseits finde ich es generell frustrierend, wie Dokumentation viel von den Nutzern voraussetzt.
OK, Frage 2: Ein Beispiel für das Hinzufügen eines benutzerdefinierten Feldes import_pass für die user_id 5 (die user_id kann in der Tabelle user_emails oder als id aus der Tabelle users eingesehen werden):
Okay, ich habe es gefunden. ./launcher restart app
Es scheint jedoch nicht neu gestartet zu werden. Ich kann auf die App zugreifen und eine Verbindung zur Datenbank herstellen, aber nicht zur Website. Vielleicht baue ich es einfach neu auf und starte von vorne.
Also habe ich ./launcher rebuild app ausgeführt, und jetzt ist alles wieder da und funktioniert.
Ich dachte, das würde die Datenbank neu erstellen, aber das ist nicht geschehen. Ich vermute, das liegt daran, dass die eigentliche Datenbank außerhalb von Docker persistent gespeichert ist und rebuild nur die Docker-App neu aufbaut. Außerdem sehe ich, dass das von mir hinzugefügte Dataexplorer-Plugin (durch Änderung der YAML-Datei) noch vorhanden ist. Aber ist das Passwordmigration-Plugin noch da oder wird es durch rebuild gelöscht? In der Plugins-Sektion der Adminseite ist jedenfalls nichts zu sehen.
Okay, ich habe versucht, passwordmigration zu installieren und dann erneut neu gestartet. Und wieder ist meine Seite down. Es scheint, als würde passwordmigration etwas kaputt machen?
Also habe ich erneut neu aufgebaut, und es funktioniert wieder (aber jetzt fehlt das passwordmigration-Plugin). Wenn ich ./launcher restart app ausführe, ohne vorher migrationpassword zu installieren, startet es problemlos. Es scheint also ein spezifisches Problem mit migrationpassword in meiner Konfiguration zu geben.
Beim letzten Versuch, den ich gemacht habe, war das Passwortmigration-Plugin mit dem Importvorgang inkompatibel. Installieren Sie es daher erst, nachdem Sie den Import durchgeführt haben.
Es könnte sein, dass es Ihren Neuaufbau stört, aber das wäre ziemlich überraschend, da Richard es in seinem Hosting-System verwendet. Ich empfehle, es in app.yml zu installieren, genau wie Sie es nach dem Import mit dem Data Explorer gemacht haben.
Komisch: Ich habe die Datenbank gelöscht und ./discourse-setup ausgeführt, sodass ich eine brandneue Installation hatte – alles war in Ordnung. Ich habe migrationpassword mit Rake installiert und neu gestartet, doch die Website schlägt erneut mit einem 502-Fehler fehl! Das DataExplorer-Plugin war noch vorhanden, also habe ich es entfernt, neu aufgebaut – es funktionierte. Dann habe ich migrationpassword erneut installiert, und es schlägt wieder mit einem 502-Fehler fehl.
Das ist verwirrend, denn es funktioniert offensichtlich bei anderen, aber nicht auf meiner Vanilla-Installation.
Als Nächstes werde ich versuchen, es durch Bearbeiten der app.yml-Datei zu installieren.
(Das Weihnachtseinkaufen hat dazwischengekommen), aber ich habe es endlich geschafft, migratepassword zu installieren, indem ich app.yml bearbeitet und neu aufgebaut habe … und es hat funktioniert!
Die Option bundle exec rake plugin:install repo=http://github.com/[Communiteq](https://www.communiteq.com) (ehemals DiscourseHosting)/discourse-migratepassword funktioniert jedoch nicht bei meiner Vanilla-Installation. Vielleicht sollte dies in der README.md unter GitHub - communiteq/discourse-migratepassword: Support migrated password hashes · GitHub überprüft oder entfernt werden.
