Es sind eigentlich 3.3, also bereite ich die Arbeit vor, bis die PRs eintreffen, um das Skript mit dieser Version von phpBB kompatibel zu machen, oder ich versuche es mit dem aktuellen Skript unter Verwendung der von Ihnen zuvor vorgeschlagenen Bearbeitung für die Versionsprüfung.
Ich muss also mit xml_to_markdown.rb arbeiten?
Mein Versuch, einen Testimport mit einem phpBB 3.3.x Forum durchzuführen, war ein großer Fehlschlag, aber dazu später mehr.
Ich habe bei dem Versuch viel gelernt und dachte, ich teile meine Erkenntnisse, da sie für andere Importe und bei der Aktualisierung des Import-Skripts für phpBB 3.3 hilfreich sein könnten.
Wenn Sie /script/import_scripts/phpbb3/database/database.rb bearbeiten müssen, um die Versionsprüfung zu umgehen, oder /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb, um benutzerdefinierte BBcodes hinzuzufügen, ist der richtige Zeitpunkt dafür, nachdem Sie den Import mit diesem Befehl gestartet haben:
/var/discourse/launcher enter import
Zu diesem Zeitpunkt können Sie nano zum Bearbeiten der Dateien verwenden.
Da mein Versuch, den Import auf meinem phpBB 3.3 Forum auszuführen, fehlgeschlagen ist, bin ich mir nicht sicher, ob meine benutzerdefinierten BBcode-Änderungen wirksam gewesen wären, aber es sieht so aus, als ob Sie für phpBB 3.2+ nur die Datei bearbeiten müssen:
/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb
wie oben erwähnt, und eine Definition im Format hinzufügen:
def visit_<Ihr benutzerdefinierter BBcode, Groß-/Kleinschreibung beachten>(xml_node, md_node)
# Code zur Verarbeitung von Dingen kommt hierher
end
Auch hier habe ich das noch nicht testen können, aber ein sehr häufiger benutzerdefinierter BBcode in phpBB, der in der Version von xml_to_markdown.rb, die ich hatte, nicht vorkommt, ist dieser:
[YouTube]{Identifier}[/YouTube]
wobei {Identifier} der “v”-Wert aus der Abfragezeichenfolge der YouTube-URL ist.
Mein Ruby-Anfängerversuch, diesen Code zu xml_to_markdown.rb hinzuzufügen, lautet also:
def visit_YouTube(xml_node, md_node)
content = xml_node.content
url = "https://www.youtube.com/watch?v=" + content
md_node.text = "#{url}"
md_node.prefix_linebreaks = md_node.postfix_linebreaks = 2
md_node.prefix_linebreak_type = LINEBREAK_HTML
end
Schließlich, als ich das Import-Skript ausführte, kam ich nur bis zum Schritt des Ladens der Datenbank und erhielt diese Fehlermeldung:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Ich bin mir nicht sicher, ob das ein DB-Engine-Problem ist – die Originalversion verwendet InnoDB – oder was, aber ich vermute, dass dies in der phpBB 3.3-Version des Skripts behoben wird.
Okay, ich konnte das nicht so stehen lassen.
Während ich annehme, dass es möglich ist, dass der Fehler, den ich erhalten habe, vom Import-Skript behandelt werden könnte, scheint es mir wirklich ein Problem mit der Datenbankstruktur von phpBB3 zu sein, und zwar mit der Tatsache, dass meine Datenbank-Kollation UTF8 ist. Ich habe diesen Fehler beim Ausführen des Import-Skripts erhalten:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Als ich Zeile 1233035 meiner phpbb_mysql.sql-Datei betrachtete – ich verwende eine lokale Kopie des Daten-Dumps –, sah ich dies:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
Als ich die Spalte config_name in der Tabelle phpbb_config betrachtete, stellte ich fest, dass sie auf VARCHAR(255) gesetzt ist.
Dank dieses Beitrags auf Stackoverflow entdeckte ich, dass ich einen “Präfix-Index” verwenden kann, um die Länge des Schlüssels zu verkürzen. Ich habe es getestet und es funktioniert.
Für meine phpBB 3.3.8-Datenbank waren tatsächlich vier Tabellen betroffen:
phpbb_configphpbb_config_textphpbb_migrationsphpbb_oauth_accountsWenn jemand anderes es versuchen möchte, hier sind die Schritte für die Tabelle phpbb_config, und ich werde die Abfragen für die anderen Tabellen am Ende einfügen.
Berechnen Sie den kürzesten Wert für den Präfix-Index mit dieser Abfrage:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config`;
In meinem Fall zeigte sich, dass 100 % der Zeilen weniger als 50 Zeichen verwendeten. Also bearbeitete ich meine Dump-Datei:
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
und verwendete die Suche Strg+W für die folgende Zeichenkette:
ALTER TABLE `phpbb_config`
dann änderte ich dies:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
zu diesem:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
Das (50) darin ist die Länge des Präfix-Index.
In meinem Fall musste ich den Vorgang mit den anderen drei Tabellen wiederholen, indem ich diese Abfragen verwendete, um die optimale Präfix-Schlüssellänge zu erhalten:
SELECT
ROUND(SUM(LENGTH(`config_name`)<10)*100/COUNT(`config_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`config_name`)<20)*100/COUNT(`config_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`config_name`)<50)*100/COUNT(`config_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`config_name`)<100)*100/COUNT(`config_name`),2) AS pct_length_100
FROM `phpbb_config_text`;
SELECT
ROUND(SUM(LENGTH(`migration_name`)<10)*100/COUNT(`migration_name`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`migration_name`)<20)*100/COUNT(`migration_name`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`migration_name`)<50)*100/COUNT(`migration_name`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`migration_name`)<100)*100/COUNT(`migration_name`),2) AS pct_length_100
FROM `phpbb_migrations`;
SELECT
ROUND(SUM(LENGTH(`provider`)<10)*100/COUNT(`provider`),2) AS pct_length_10,
ROUND(SUM(LENGTH(`provider`)<20)*100/COUNT(`provider`),2) AS pct_length_20,
ROUND(SUM(LENGTH(`provider`)<50)*100/COUNT(`provider`),2) AS pct_length_50,
ROUND(SUM(LENGTH(`provider`)<100)*100/COUNT(`provider`),2) AS pct_length_100
FROM `phpbb_oauth_accounts`;
Hier sind die Suchstrings für die anderen Tabellen, um Ihnen Zeit zu sparen:
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
Ich sage nicht, dass ich aus dem Gröbsten raus bin, aber das oben hat meinen anfänglichen Datenbankfehler behoben, und der Import läuft:
#import_phpbb3.sh
Der phpBB3-Import beginnt...
Lade vorhandene Gruppen...
Lade vorhandene Benutzer...
Lade vorhandene Kategorien...
Lade vorhandene Beiträge...
Lade vorhandene Themen...
Importiere von phpBB 3.3.8
Erstelle Benutzer
722 / 5014 ( 14.4%) [58 Elemente/min]
Update:
Das Import-Skript wurde in 9 Stunden und 28 Minuten abgeschlossen. Gott sei Dank für Screen. Dieses Skript ist großartig!
Die Nachbearbeitung läuft jetzt.
Gibt es irgendwo ein Protokoll der Ausgabe des Import-Skripts, oder hätte ich es in eine Datei umleiten sollen?
Welches Verfahren für den phpbb3-Importer sollte verwendet werden, wenn discourse_dev in einem Docker-Container unter WSL ausgeführt wird?
Ich habe versucht, sowohl Verfahren 1. Importieren mit einem Docker-Container als auch Verfahren 2. Importieren mit Entwicklungsumgebung zu verwenden. Keines davon hat funktioniert, obwohl ich das Skript unter Verfahren 1 erfolgreich ausführen konnte, aber keine Daten tatsächlich in die Forendatenbank gelangten, obwohl die vielen Abfragen anscheinend erfolgreich waren, als sie durchliefen. Könnte es eine andere Datenbank geben, die aufgrund des Imports, der in einem eigenen Container getrennt vom discourse_dev-Container ausgeführt wird, gefüllt wird?
Im Fall von Verfahren 2 ist es einfach nicht möglich, den Build auszuführen, der mit „Ein Fehler ist beim Installieren von tiny_tds (2.1.5) aufgetreten, und Bundler kann nicht fortfahren“ fehlschlägt.
Sollte ich versuchen, eine „Standardinstallation“ (nicht Docker, nicht Dev) unter WSL durchzuführen und dann den Docker-basierten Import durchzuführen?
Das ist, was ich empfehle. Ich führe Migrationen im Entwicklungsbereich nur noch sehr selten durch.
Außerdem brauchen Sie kein tiny_tds, es sei denn, Sie verwenden mssql anstelle von mysql/mariadb.
Vielen Dank, Jay. Deine Tutorials waren genau richtig, ich schätze sie sehr.
Ich habe Discourse erfolgreich auf einem neuen VPS mit dem Standard-Docker-Installationsprozess installiert. Ich habe dann den Importprozess gemäß dieser Anleitung ausgeführt und das Skript wurde ohne Probleme abgeschlossen. Ich habe den Container verlassen und dann den Import gestoppt, woraufhin die folgende Meldung erschien:
''Sie haben weniger als 5 GB freien Speicherplatz auf der Festplatte, auf der sich /var/lib/docker befindet. Sie benötigen mehr Speicherplatz, um fortzufahren.
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/vda1 24G 20G 2,7G 89% /
Möchten Sie versuchen, Speicherplatz durch Bereinigung von Docker-Images und Containern im System wiederherzustellen? (j/N)‘’
Die Wiederherstellung des Speicherplatzes brachte keinen zusätzlichen Platz. Wie soll ich also vorgehen? Kann ich alle Bilddateien, die ich nach /data hochgeladen habe, sicher löschen? Ich bin mir nicht sicher, ob sie noch benötigt werden.
Danke.
Wenn der Import abgeschlossen zu sein scheint und Sie die Bilder meinen, die hätten importiert werden sollen, sollte alles in Ordnung sein, aber Sie werden wahrscheinlich nicht genug Speicherplatz für ein Backup haben. Ich würde das Droplet aufrüsten, um mehr Speicherplatz zu haben. Die Kosten pro Tag sollten keine große Sache sein.
Vielen Dank für diesen Rat, Jay.
Falls diese Details für andere hilfreich sind, habe ich nur die Bilddateien entfernt, wodurch ~ 3,4 GB für insgesamt 6,1 GB freigegeben wurden und Sidekiq dann erfolgreich die Nachbearbeitung erledigt hat. Der Festplattenspeicher wurde seitdem um weitere 20 GB erweitert.
Zur Information: Dies war ein Import eines phpBB-Messageboards der Version 3.3.0 mit etwas mehr als 73.000 Beiträgen in etwas mehr als 8.000 Themen mit etwas mehr als 1300 Benutzern.
Das einzige Problem, das ich bisher gefunden habe, ist, dass einige Benutzernamen seltsam sind, aber das wurde oben besprochen und ist nicht fatal.
Zwischen diesem Import und der Schließung des Quell-phpBB-Forums wird eine gewisse Zeit vergehen. Kann ich den Import-Docker-Container einfach belassen und ihn dann mit einem inkrementellen Backup verwenden, um Beiträge zu migrieren, die nach diesem Import erstellt wurden?
Als ich meine phpBB 3.3.x-Migration durchführte, habe ich für meinen endgültigen Import die phpBB-Seite in den „Wartungsmodus“ versetzt, rsync verwendet, um die Anhänge, Avatare und Smileys zu aktualisieren, dann einen neuen Daten-Dump importiert und den Import neu aufbauen müssen, um den Import-Skript-Endlauf durchzuführen, aber ich hatte den Import vorher abgebrochen.
@DonH Haben Sie die phpBB-Passwörter importiert und mit dem Migrate Passwords-Plugin zum Laufen gebracht?
Ich habe aus mehreren Gründen keine phpBB-Passwörter importiert. Ich wollte keine potenziellen Konflikte mit Plugins und ich wollte die Leute zwingen, ihre Passwörter zu aktualisieren, und diese Migration schien ein guter Weg (und eine gute Ausrede) dafür zu sein. Die Sicherheit auf dem phpBB-Webhost wird vom Hosting-Unternehmen übernommen, mit dem neuen VPS gibt es keinen solchen Luxus.
Um es klarzustellen, haben Sie Ihre gesamte Datenbank ein letztes Mal neu importiert und kein inkrementelles Update durchgeführt?
Meine Erfahrung und mein Verständnis ist, dass, wenn Sie einen Daten-Dump Ihres phpBB-Forums (z. B. von phpMyAdmin) erstellen, die Datei nach /var/discourse/shared/standalone/import/data hochladen, den Import neu erstellen und dann den Importbefehl erneut ausführen, das Migrationsskript keine bereits importierten Benutzerkonten, Beiträge usw. anrührt, sondern nur Datenbankeinträge, die zuvor nicht importiert wurden.
Im Wesentlichen wird ein inkrementelles Update durchgeführt, aber bestehende Einträge werden nicht angetastet, sodass Sie möglicherweise einige Daten verlieren. Zum Beispiel, wenn ein Benutzer einen bereits importierten Beitrag bearbeitet oder seine E-Mail-Adresse geändert hat.
Wenn Sie die Plugin-Einstellung migratepassword_allow_insecure_passwords nicht aktiviert lassen, wird das migratepassword-Plugin keine migrierten Passwörter zulassen, die von Discourse als unsicher eingestuft werden, und alle Komplexitätseinstellungen wie Mindestlänge und eindeutige Zeichen berücksichtigen.
Ich bin mir nicht sicher, auf welche Art von Plugin-Konflikten Sie sich beziehen?
@RGJ Funktioniert das migratepassword-Plugin mit phpBB 3.3?
Ich bin gerade dabei, einen Import mit einem phpBB 3.3.8 Forum durchzuführen, und ich importiere die Passwörter, um es zu versuchen.
Wie können Sie von myBB migrieren?
Sie können nach myBB und dem Tag #migration::tag suchen, vielleicht finden Sie eine howto
Ok, danke für die Info!
Danke für diese Klarstellung, Richard. Ich bezog mich nicht auf einen bestimmten Konflikt, sondern nur auf die Möglichkeit, dass in unbekanntem Gebiet etwas Unerwartetes passieren könnte. Ich habe den Import absichtlich durchgeführt, bevor ich Plugins hinzugefügt habe. Hauptsächlich möchte ich jedoch unsere Mitglieder dazu zwingen, ihre Passwörter zu aktualisieren.
Diese Migration verlief wirklich reibungslos, also ein großes Lob an Gerhard und alle anderen, die an einem gut abgestimmten Skript beteiligt waren. Ich freue mich darauf, unser neues Messageboard anzupassen.
Ja, das wird es, wir haben kürzlich Argon2-Unterstützung im Plugin hinzugefügt.
Richard unterstützt das Plugin auf seinem Hosting. Ich habe noch nie gehört, dass es Probleme verursacht hat. Viele Importeure importieren die Passwörter und es funktioniert einfach. Ich hatte es sogar für ein Import-Skript, das ich für ein anderes zufälliges Forum geschrieben habe, zum Laufen gebracht.