In realtà è 3.3, quindi sto facendo lavori preparatori in attesa che arrivino le PR per rendere lo script compatibile con quella versione di phpBB, oppure potrei provarci con lo script attuale usando la modifica che hai suggerito in precedenza per il controllo della versione…
Quindi immagino che dovrò lavorare con xml_to_markdown.rb?
Il mio tentativo di eseguire un’importazione di prova con un forum phpBB 3.3.x è fallito clamorosamente, ma ne parlerò più avanti.
Ho imparato molto nel processo di prova e ho pensato di condividere ciò che ho imparato perché potrebbe essere utile per altre importazioni e quando lo script di importazione verrà aggiornato per phpBB 3.3.
Se è necessario modificare /script/import_scripts/phpbb3/database/database.rb per superare il controllo della versione, o /script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb per aggiungere BBcode personalizzati, il momento giusto per farlo è dopo aver avviato l’importazione con questo comando:
/var/discourse/launcher enter import
A quel punto, è possibile utilizzare nano per modificare i file.
Poiché il mio tentativo di eseguire l’importazione sul mio forum phpBB 3.3 è fallito, non posso essere sicuro che le mie modifiche personalizzate ai BBcode sarebbero state efficaci, ma sembra che tutto ciò che devi fare per phpBB 3.2+ sia modificare il file:
/script/import_scripts/phpbb3/support/bbcode/xml_to_markdown.rb
come notato sopra, e aggiungere una definizione nel formato di:
def visit_<il tuo BBcode personalizzato sensibile alle maiuscole qui>(xml_node, md_node)
# il codice per gestire le cose va qui
end
Ancora una volta, non ho ancora avuto modo di testarlo, ma un BBcode personalizzato molto comune in phpBB che non appare nella versione di xml_to_markdown.rb che avevo è questo:
[YouTube]{Identifier}[/YouTube]
dove {Identifier} è il valore “v” dalla stringa di query dell’URL di YouTube.
Quindi, il mio tentativo da principiante di Ruby di aggiungere quel codice a xml_to_markdown.rb è:
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
Infine, quando ho eseguito lo script di importazione, sono arrivato solo alla fase di caricamento del database e ho ricevuto questo errore:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Non sono sicuro se si tratti di un problema del motore DB - l’originale utilizza InnoDB - o cosa, ma sospetto che verrà affrontato nella versione 3.3 dello script per phpBB.
Ok, non sono riuscito a lasciar perdere.
Sebbene supponga che sia possibile che l’errore che ho ricevuto possa essere gestito dallo script di importazione, mi sembra davvero un problema con la struttura del database di phpBB3 e il fatto che la mia collation del database sia UTF8. Ho ricevuto questo errore eseguendo lo script di importazione:
ERROR 1071 (42000) at line 1233035: Specified key was too long; max key length is 1000 bytes
Quando ho guardato la riga 1233035 del mio file phpbb_mysql.sql - sto usando una copia locale del dump dei dati - ho visto questo:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
Guardando la colonna config_name nella tabella phpbb_config, ho scoperto che è impostata su VARCHAR(255).
Grazie a questo post su Stackoverflow, ho scoperto che posso usare un “prefisso di indice” per ridurre la lunghezza della chiave. L’ho testato e funziona.
Per il mio database phpBB 3.3.8, c’erano in realtà quattro tabelle interessate:
Se qualcun altro vuole provarci, ecco i passaggi per la tabella phpbb_config, e includerò le query per le altre tabelle alla fine.
Calcola il valore più corto per il prefisso di indice usando questa query:
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`;
Nel mio caso, ha mostrato che il 100% delle righe utilizzava meno di 50 caratteri, quindi ho modificato il mio file di dump dei dati:
nano /var/discourse/shared/standalone/import/data/phpbb_mysql.sql
e ho usato la ricerca Ctrl+W per la seguente stringa:
ALTER TABLE `phpbb_config`
quindi ho cambiato questo:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`),
ADD KEY `is_dynamic` (`is_dynamic`);
in questo:
ALTER TABLE `phpbb_config`
ADD PRIMARY KEY (`config_name`(50)),
ADD KEY `is_dynamic` (`is_dynamic`);
Il (50) qui è la lunghezza del prefisso di indice.
Nel mio caso, ho dovuto ripetere il processo con le altre tre tabelle usando queste query per ottenere la lunghezza ottimale della chiave di prefisso:
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`;
Ecco le stringhe di ricerca per le altre tabelle per farti risparmiare tempo:
ALTER TABLE `phpbb_config_text`
ALTER TABLE `phpbb_migrations`
ALTER TABLE `phpbb_oauth_accounts`
Non dirò di essere fuori pericolo, ma quanto sopra ha risolto il mio errore iniziale del database e l’importazione è in corso:
#import_phpbb3.sh
The phpBB3 import is starting...
Loading existing groups...
Loading existing users...
Loading existing categories...
Loading existing posts...
Loading existing topics...
importing from phpBB 3.3.8
creating users
722 / 5014 ( 14.4%) [58 items/min]
Aggiornamento:
L’importazione dello script è terminata in 9 ore e 28 minuti. Meno male che c’era Screen. Questo script è fantastico!
Il post-processing è ora in corso.
C’è un log dell’output dello script di importazione da qualche parte, o avrei dovuto reindirizzarlo a un file?
Quale procedura per l’importatore phpbb3 dovrebbe essere utilizzata quando si esegue discourse_dev in un container Docker sotto WSL?
Ho provato entrambe le procedure: 1. Importazione tramite container Docker e 2. Importazione tramite ambiente di sviluppo. Nessuna delle due ha funzionato, anche se sono riuscito a far eseguire lo script fino al completamento con la procedura 1, ma nessun dato è effettivamente entrato nel database del forum nonostante le numerose query sembrassero essere riuscite man mano che procedevano. Potrebbe esserci un database diverso coinvolto che viene popolato a causa dell’importazione eseguita nel proprio container separato dal container discourse_dev?
Nel caso della procedura 2, non è semplicemente possibile eseguire la build che fallisce con “Si è verificato un errore durante l’installazione di tiny_tds (2.1.5) e Bundler non può continuare”.
Dovrei provare a fare un’“installazione standard” (non Docker, non dev) in WSL e poi fare l’importazione basata su Docker?
Questo è ciò che raccomando. Raramente faccio una migrazione in fase di sviluppo ormai.
Inoltre, non hai bisogno di tiny_tds, a meno che tu non stia usando mssql invece di mysql/mariadb.
Grazie mille, Jay. I tuoi tutorial sono stati perfetti, li apprezzo molto.
Ho installato correttamente Discourse su un nuovo VPS utilizzando il processo di installazione Docker standard. Ho quindi eseguito il processo di importazione seguendo queste istruzioni e lo script è terminato senza problemi. Sono uscito dal container e poi ho emesso il comando stop import ottenendo il messaggio:
''Hai meno di 5 GB di spazio libero sul disco in cui si trova /var/lib/docker. Avrai bisogno di più spazio per continuare
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 24G 20G 2.7G 89% /
Desideri tentare di recuperare spazio pulendo le immagini e i container Docker nel sistema? (y/N)‘’
Il recupero dello spazio non ha prodotto spazio aggiuntivo. Come procedere? Posso eliminare in sicurezza tutti i file immagine che ho caricato in /data? Non sono sicuro se siano ancora necessari.
Grazie.
Se l’importazione sembra essere terminata e stai parlando delle immagini che avrebbero dovuto essere importate, dovrebbe andare tutto bene, ma probabilmente non avrai abbastanza spazio per fare un backup. Ti consiglierei di aumentare le dimensioni del droplet per avere più spazio. Il costo giornaliero non dovrebbe essere un problema.
Grazie per questo consiglio, Jay.
Nel caso in cui questi dettagli possano essere utili ad altri, ho rimosso solo i file immagine, liberando circa 3,4 GB per un totale di 6,1 GB disponibili e Sidekiq ha quindi elaborato con successo il post-processing. Lo spazio su disco è stato da allora aumentato di altri 20 GB.
Ai fini della cronaca, si è trattato di un’importazione di una bacheca phpBB versione 3.3.0 con poco più di 73.000 post in poco più di 8.000 argomenti con poco più di 1300 utenti.
L’unico problema che ho riscontrato, finora, è che alcuni nomi utente sono strani, ma ciò è stato discusso sopra e non è fatale.
Ci sarà un intervallo tra questa importazione e la chiusura del forum phpBB di origine. Posso semplicemente lasciare il container Docker di importazione al suo posto e poi utilizzarlo su un backup incrementale per migrare i post creati dopo questa importazione?
Quando ho eseguito la migrazione da phpBB 3.3.x, per eseguire la mia importazione finale, ho messo il sito phpBB in “modalità di manutenzione”, ho utilizzato rsync per aggiornare gli allegati, gli avatar e le faccine, quindi ho importato un nuovo dump di dati e ho dovuto ricostruire l’importazione per eseguire l’ultima esecuzione dello script di importazione, ma ero uscito dall’importazione prima di ciò.
@DonH Hai importato le password di phpBB e le hai fatte funzionare con il plugin Migrate Passwords?
Non ho importato le password di phpBB per un paio di ragioni. Non volevo potenziali conflitti con i plugin e volevo costringere le persone ad aggiornare le loro password, e questa migrazione sembrava un buon modo (e una buona scusa) per farlo. La sicurezza sull’host web di phpBB è gestita dalla società di hosting, con il nuovo VPS non c’è un tale lusso.
Per essere chiari, hai reimportato l’intero database un’ultima volta e non hai fatto un aggiornamento incrementale?
La mia comprensione, ed esperienza, è che se si esegue un dump dei dati del proprio forum phpBB - da phpMyAdmin, ad esempio - e si carica il file in /var/discourse/shared/standalone/import/data, si ricostruisce l’importazione, quindi si riesegue il comando di importazione, lo script di migrazione non toccherà gli account utente, i post, ecc. già importati, ma solo le voci del database che non sono state importate in precedenza.
In sostanza, sta eseguendo un aggiornamento incrementale, ma non tocca le voci esistenti, quindi potresti perdere alcuni dati; ad esempio, se un utente ha modificato un post già importato o ha cambiato il proprio indirizzo email.
Se si lascia l’impostazione del plugin migratepassword_allow_insecure_passwords deselezionata, il plugin migratepassword non consentirà le password migrate considerate insicure da Discourse, rispettando tutte le impostazioni di complessità come la lunghezza minima e i caratteri univoci.
Non sono sicuro a che tipo di conflitti di plugin ti riferisci?
@RGJ Il plugin migratepassword funzionerà con phpBB 3.3?
Sto effettuando un’importazione con un forum phpBB 3.3.8 in questo momento e sto importando le password per fare un tentativo.
Come potresti essere in grado di migrare da myBB?
Puoi cercare myBB e il tag #migration::tag, forse troverai un howto
Ok, grazie per le informazioni!
Grazie per la chiarificazione, Richard. Non mi riferivo a nessun conflitto specifico, solo alla possibilità che accada qualcosa di inaspettato in un territorio sconosciuto. Ho eseguito l’importazione deliberatamente prima di aggiungere qualsiasi plugin. Soprattutto, però, voglio costringere i nostri membri ad aggiornare le loro password.
Questa migrazione è andata davvero senza intoppi, quindi complimenti a Gerhard e a tutti gli altri coinvolti per uno script ben calibrato. Non vedo l’ora di personalizzare il nostro nuovo forum.
Sì, lo farà, abbiamo recentemente aggiunto il supporto Argon2 nel plugin.
Richard supporta il plugin sul suo hosting. Non ho mai sentito che abbia causato problemi. Molti importatori importano le password e funziona e basta. L’ho persino fatto funzionare per uno script di importazione che ho scritto per un altro forum casuale.