Plugin zur Unterstützung der Zuordnung von Pre-Migration-Threads nach der Migration

Hallo, ich und meine Gruppe von verrückten Idioten sind kurz davor, unser Vbulletin3-Forum endlich nach Discourse zu migrieren, nachdem wir ein Ad-hoc-Skript geschrieben haben, das endlich alle 21 Millionen Antworten aus der ursprünglichen Datenbank nach Discourse migriert.

Jetzt haben wir das Problem mit Links zu den Themen/Antworten, die in den Antworten selbst geschrieben sind.

Bei der Migration, die wir geschrieben haben, erstellen wir eine Zuordnung der „alten“ Themen- und Beitrags-IDs zu dem, was sie in Discourse abbilden.

Zum Beispiel:

   id   | topic_id |   name    | value  |         created_at         |         updated_at
--------+----------+-----------+--------+----------------------------+----------------------------
 581727 |   581736 | import_id | 599137 | 2023-02-08 16:30:01.600759 | 2023-02-08 16:30:01.600759

Was ich mir jetzt überlegt habe, ist ein Plugin, das einfach Links zum alten Forenformat abfängt und sie mit Verweisen auf den neuen Thread/die neue Antwort umwandelt.

Also zum Beispiel etwas wie:

https://oldforum.something.com/showthread.php?t=123456

würde eine Abfrage auslösen, die das topics_custom_field nach dem Wert 123456 durchsucht, die Discourse topic_id findet, dann die Tabelle topic_links mit dieser ID abfragt und die url findet. Schließlich wird sie auf der Clientseite ersetzt (unter der Annahme von JS zur Manipulation des Inhalts).

Etwas Ähnliches für Beiträge.

Ich kann jedoch kein gutes Beispiel dafür finden, wie man so etwas für Discourse überhaupt erstellt.
Kann mir jemand Hinweise, Beispiele oder Plugins geben, die etwas Ähnliches tun (Antworten auf einen Teilstring prüfen und ihn ersetzen, die API? DB? nach einem Wert abfragen, um einen anderen abzurufen?).

Vielen Dank

Das existiert bereits im Kern, es heißt Permalinks, und der vorhandene VB4-Importer hat Code dafür

Sie sollten etwas wie /showthread\\.php\\?(\\d*)/thread/\\1 in die Einstellung permalink_normalizations eingeben.

Nur zur Bestätigung, ich sollte diese Logik nach Abschluss der Migration ausführen, richtig?
Damit werden alle Antworten erneut durchlaufen und die Permalinks geändert.

Was meinst du mit Änderungen? Hast du schon Permalinks?

Wenn wir den Inhalt einer Antwort migrieren, z. B. mit: https://oldforum.something.com/showthread.php?t=123456 weiß nicht, welche id dieses Thema auf Discourse haben wird… oder?

es wird, wenn Sie den obigen Code zum Erstellen von Permalinks verwenden.

showthread.php?t= bezieht sich übrigens auf ein Thema/einen Thread und nicht auf eine Antwort

Ich habe diesen Link nur als Beispiel verwendet

Leider können wir diesen Code nicht verwenden, da der Import von 20 Millionen Beiträgen ewig dauert und der Massenimport einfach nicht funktioniert. Es fehlen Teile.

Deshalb mussten wir unser eigenes Migrationsskript schreiben. Es erledigt alles (PM, Benutzer, Benutzergruppen, Kategorien, Themen, Antworten) in etwa 6 Stunden mit 4 Kernen und 8 GB RAM, aber wir haben festgestellt, dass uns die Permalinks fehlen

Vielleicht können Sie die Nginx-Map-Lösung für Permalinks in Betracht ziehen? Redirect vBulletin URLs to Discourse URLs

Wir haben intern darüber gesprochen und werden einfach einen zweiten Durchgang machen, wenn alle Antworten migriert wurden.

Danke, dass du Ideen mit mir ausgetauscht hast, Richard

Hat Ihr Skript import_ids erstellt? Wenn ja, auch wenn Sie die Permalinks nicht erstellt haben, können Sie diese recht schnell verarbeiten, um sie zu erstellen.

Ja, Jay, das tun wir.

Wir haben versucht, die gesamten 20 Millionen+ Antworten nicht noch einmal zu durchlaufen, aber uns wurde klar, dass alternative Lösungen (Plugin, Nginx-Weiterleitung usw.) ziemlich kompliziert wären oder auf externen Faktoren beruhen würden, die es zu einer halbherzigen Lösung machen würden. Daher werden wir die Antworten einfach noch einmal durchlaufen und die Permalinks verarbeiten. Dies wird die Migration etwas verlängern, aber hoffentlich nicht zu sehr.

Alles andere wird „on the fly“ „gekocht“, da wir wissen, was „roh“ in HTML konvertiert werden muss.

Bei den Permalinks können wir das nicht tun, da eine hinzugefügte Permalink-Referenz auf ein Topic verweisen könnte, das noch nicht verarbeitet wurde (höhere Topic-ID) und zum Zeitpunkt der Verarbeitung nicht in der topics_custom_field-Tabelle gefunden wird.

Ich weiß nicht, wie Sie topic_custom_fields erstellen konnten, ohne zuerst das Thema zu erstellen. Ich würde denken, Sie könnten so etwas tun

TopicCustomField.each do |tcf|

und die Permalinks erstellen, aber ich weiß vieles über Ihren Code nicht.

Lassen Sie mich das klarstellen:

Themen und alle ihre Antworten werden anhand der Themen-IDs von kleiner zu größer aus der vbulletin-Datenbank importiert. Das bedeutet auch, dass wir in chronologischer Reihenfolge importieren.

Das würde jedoch zu dem Schluss führen, dass, wenn Sie jemals eine Referenz auf ein anderes Thema finden, es sich immer um ein anderes handelt, das bereits existiert hat.

Aber es gibt Fälle, in denen dies nicht zutrifft, nur ein paar Beispiele:

• Aufgeteiltes Thema mit einem Kommentar, der zur Aufteilung führte. Die Aufteilung erfolgt mit einer ID, die höher ist, aber in einem Thema mit einer geringeren ID existiert.
• Bearbeitung für zukünftige Leser, bei der Beiträge älterer Themen Verweise auf neuere enthalten.

Also, ja, während die topics_custom_field während des Imports generiert und gefüllt wird, wie im allerersten Thema erklärt, ist es nicht zuverlässig, dies “on the fly” zu tun, da Sie nicht sicher sein können, immer die richtige Entsprechung zwischen den IDs zu finden.

Ein weiterer Durchgang nach Abschluss des vollständigen Imports ist erforderlich.

Bezüglich TopicCustomField.each do |tcf|, bin ich mir nicht sicher, was der tcf-Teil tun würde. Ruby ist keine Sprache, die ich gelernt habe. Unser Skript ist in C# geschrieben, da die meisten Leute, die angeboten haben, damit zu arbeiten, es bereits beruflich nutzen.