Sì, vengono convertiti. Ti invierò un’email domani!
3 Mi Piace
Devi raggiungere il livello di fiducia 1 per sbloccare i messaggi privati, ma non hai ancora dedicato abbastanza tempo alla lettura dei topic qui per ottenerlo.
4 Mi Piace
Ciao, sto usando un container Docker (DigitalOcean) e sto cercando di importare il mio BB (so che questa guida è per Vbulletin, ma la questione del Gemfile è simile). Sono bloccato al comando bundle install:
Ciao,
Abbiamo provato a importare vBulletin 3.8 in Discourse. Questo script funziona bene con un database da 300 MB, circa 40.000 utenti e 60.000 post. Ma alla fine del processo di importazione abbiamo riscontrato un problema con la codifica dei caratteri.
- Il nostro vBulletin 3.8 è codificato con latin1
----> quando eseguiamo lo script di importazione, MySQL 5.6 nel container Docker di Discourse è configurato con la codifica UTF-8, - Lo script di importazione forza la conversione dei dati in UTF-8 durante il processo,
quindi alla fine del processo di importazione il forum di Discourse visualizza i dati con errori di codifica UTF-8. Sembra come nell’immagine qui sotto.
-
Prima dell’importazione, vB 3.8
-
Dopo l’importazione in Discourse
Abbiamo provato:
- Convertire la codifica da latin1 a UTF-8 su vB 3.8 prima di eseguire lo script di importazione
- Testato questo database vB 3.8 su un nuovo server MySQL: il testo viene visualizzato correttamente senza errori di codifica.
Quindi, potreste darci qualche consiglio in questo caso?
Grazie per qualsiasi supporto (e scusate anche per il mio inglese, se è difficile da capire)
1 Mi Piace
Ecco un esempio di come ho risolto un problema simile:
### Codifica WIN1252
win_encoded = ''
begin
win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
invalid: :replace, undef: :replace, replace: ""
).force_encoding('utf-8').scrub
rescue => e
puts "\n#{'-'*50}\nWin1252 fallito per \n\n#{raw}\n\n"
win_encoded = ''
end
raw = win_encoded
5 Mi Piace
Mi hai salvato la vita.
Per la soluzione semplice, ho provato lo script di conversione nel post Migrate a phpBB3 forum to Discourse - #540 by gerhard, aiutandomi a risolvere rapidamente il problema della codifica dei caratteri del mio database, e ora funziona alla perfezione.
Grazie mille per il consiglio.
3 Mi Piace
Qualcuno ha migrato usando l’importatore vBulletin 5? Potrei utilizzarlo in futuro; vorrei sapere se è già stato impiegato senza problemi.
2 Mi Piace
Ho appena completato l’importazione di vBulletin5 e ho aggiunto alcune funzionalità (permalink, alcune opzioni di formattazione e forse altre cose che non ricordo). Intendo inviare una pull request, ma non è ancora avvenuta.
3 Mi Piace
Ho un dump del database vb5 che contiene allegati. Posso importarli in Discourse o devo avere tutti gli allegati come file?
Anche io sono confuso su questo. Dove devo copiare esattamente i file degli allegati nella cartella di Discourse? 
2 Mi Piace
Ciao di nuovo,
Da quanto ho capito, gli allegati dal database funzioneranno, poiché sembrano essere gestiti nello stesso modo degli avatar, che si trovano anch’essi nel database.
La mia importazione sta procedendo bene, ma ho riscontrato un errore al 91% dei post importati 
importing posts...
1425149 / 1564573 ( 91.1%) [1040 items/min] Traceback (most recent call last):
14: from script/import_scripts/vbulletin5.rb:726:in `<main>'
13: from /home/canapin/discourse/script/import_scripts/base.rb:47:in `perform'
12: from script/import_scripts/vbulletin5.rb:49:in `execute'
11: from script/import_scripts/vbulletin5.rb:300:in `import_posts'
10: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `batches'
9: from /home/canapin/discourse/script/import_scripts/base.rb:862:in `loop'
8: from /home/canapin/discourse/script/import_scripts/base.rb:863:in `block in batches'
7: from script/import_scripts/vbulletin5.rb:320:in `block in import_posts'
6: from /home/canapin/discourse/script/import_scripts/base.rb:508:in `create_posts'
5: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
4: from /usr/local/rvm/gems/ruby-2.6.5/gems/rack-mini-profiler-2.0.4/lib/patches/db/mysql2.rb:8:in `each'
3: from /home/canapin/discourse/script/import_scripts/base.rb:509:in `block in create_posts'
2: from script/import_scripts/vbulletin5.rb:321:in `block (2 levels) in import_posts'
1: from script/import_scripts/vbulletin5.rb:450:in `preprocess_post_raw'
script/import_scripts/vbulletin5.rb:450:in `gsub': invalid byte sequence in UTF-8 (ArgumentError)
Come posso identificare correttamente il post per vedere come appare il contenuto nel database di vbulletin?
1 Mi Piace
Qualcuno ha suggerito di utilizzare rescue per risolvere questi problemi, quindi potresti tornare indietro e trovarlo (non ricordo se fosse in questo argomento o in un altro). Potresti inserire un puts nel blocco rescue per stampare l’id e/o il testo che ha causato il problema.
Hai un problema di codifica.
Ho usato questo approccio in un’importazione simile (penso che dovresti inserirlo in preprocess_post_raw):
begin
win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
invalid: :replace, undef: :replace, replace: ""
).force_encoding('utf-8').scrub
rescue => e
puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
win_encoded = ''
end
3 Mi Piace
Ciao,
Ho modificato l’importatore e aggiunto il tuo script come segue:
def preprocess_post_raw(raw)
return "" if raw.blank?
begin
win_encoded = raw.force_encoding('utf-8').encode("Windows-1252",
invalid: :replace, undef: :replace, replace: ""
).force_encoding('utf-8').scrub
rescue => e
puts "\n#{'-'*50}\nWin1252 failed for \n\n#{raw}\n\n"
win_encoded = ''
end
# decodifica le entità HTML
raw = @htmlentities.decode(raw)
# correggi gli spazi bianchi
raw = raw.gsub(/(\\r)?\\n/, "\n")
.gsub("\\t", "\t")
La sequenza di byte non valida in UTF-8 si verifica in questa parte: raw = raw.gsub(/(\\r)?\\n/, "\n") .gsub("\\t", "\t").
Poi ho riavviato l’importatore. Sebbene salti i dati già importati, ci sono volute circa 6 ore per arrivare al post che genera un errore, e non ha aggiunto le informazioni previste per visualizzare il contenuto del post. 
Hai qualche idea sul perché?
edit:
Questo è probabilmente il contenuto grezzo del post che causa l’errore:
I wonder if Billy is enjoying the parade.
Qwertyuiopasdfghjklzxcvbnm��
Proverò a modificare lo script dell’importatore per far sì che salti (davvero) i precedenti 1,4 milioni di post. Incrociate le dita per me. 
2 Mi Piace
Ho modificato molti altri importatori per includere un’impostazione import_after che consente di importare solo i dati recenti. Puoi consultare alcuni degli altri per vedere come ho fatto.
2 Mi Piace
Ciao,
sono riuscito a importare quasi tutti i miei post! Ho corretto a mano alcune decine di errori e ho riavviato l’importazione ogni volta che si presentava un nuovo errore UTF-8… 
Ora, devo importare gli allegati (che sono archiviati nel database di VBulletin), ma non funziona:
Quando avvio il processo, il consumo di RAM aumenta notevolmente in circa 10 o 20 secondi e si verifica questo errore:
importing attachments...
Failed to create upload: Cannot allocate memory - grep
Fail
La mia RAM:
Sto usando una versione di sviluppo di Discourse su un subsystem Ubuntu 18 su Windows 10 e ho 16 GB di RAM.
Gli allegati occupano 7 GB dei 13 GB del database vBulletin.
Tieni presente che sto usando l’importer vbulletin5.
Il problema deriva da questa query:
SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
FROM #{DB_PREFIX}attach a
LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
Se eseguo questa query su MySQL, la RAM residua si esaurisce in pochi secondi.
(Sto modificando il mio post per rimuovere informazioni e domande inutili, dato che sto facendo progressi e fornendo una soluzione alternativa)
Soluzione alternativa:
Ho aggiunto un limite e un offset alla query SQL dell’importer. Ho importato gli allegati selezionandone 20.000 alla volta:
uploads = mysql_query <<-SQL
SELECT n.parentid nodeid, a.filename, fd.userid, LENGTH(fd.filedata) AS dbsize, filedata, fd.filedataid
FROM #{DB_PREFIX}attach a
LEFT JOIN #{DB_PREFIX}filedata fd ON fd.filedataid = a.filedataid
LEFT JOIN #{DB_PREFIX}node n on n.nodeid = a.nodeid
LIMIT 20000 OFFSET 0
SQL
Ho anche aggiunto un exit alla fine del ciclo uploads.each do |upload| per impedire allo script di importazione di continuare a eseguire altre operazioni dopo aver importato i miei 20.000 allegati.
Quando i miei 10.000 allegati sono stati importati, ho modificato lo script (grazie a nano +353 ./scripts/import_scripts/vbulletin5.rb per aprire il file alla riga corretta) per aumentare l’OFFSET della query SQL di 10.000 e ho riavviato l’importatore… E ho ripetuto questa operazione per tutti i miei 65.000 allegati.
Durante l’importazione degli allegati, ho riscontrato diversi errori e avvisi, tra cui:
W, [2020-08-20T12:05:37.402860 #31042] WARN -- : Bad date/time value "0000:00:00 00:00:00": mon out of rangePost for 490451 not found(probabilmente allegati vecchi orfani?)- Alcuni errori relativi ai dati EXIF, a quanto pare
FailQuesto mi ha lasciato perplesso e ha fermato lo script di importazione. Ho controllato il primo “Fail” che ho ricevuto e l’allegato del forum era in qualche modo danneggiato (nessun nome file), quindi ho commentato l’istruzioneexitper permettere all’importatore di continuare il suo lavoro quando “fallisce”, sperando che ciò non avrebbe rotto nulla.
puts "Fail"
#exit
Ho anche riscontrato un errore più fastidioso che ha interrotto l’importazione:
1: from /usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:53:in `save!'
/usr/local/rvm/gems/ruby-2.6.5/gems/activerecord-6.0.3.2/lib/active_record/validations.rb:80:in `raise_validation_error':
Validation failed: Body is limited to 32000 characters; you entered 32323. (ActiveRecord::RecordInvalid)
Fortunatamente, si è trattato di un errore raro e ho semplicemente saltato quell’allegato fino a quando non sono incappato nel successivo errore identico. È successo forse una dozzina di volte su un totale di 65.000 allegati. Ho semplicemente riavviato lo script di importazione con un diverso offset della query SQL.
1 Mi Piace
Ciao,
Ho notato che il campo personalizzato import_pass mancava per circa 400 utenti sui 27.000 utenti rimanenti (ho rimosso 154.000 utenti inattivi).
Hai idea del perché?
Il forum è stato migrato da phpBB a vBulletin a maggio. Potrebbe avere a che fare con questo?
Non proverò a “risolvere” questo problema e importare le password per questi 400 utenti (a meno che non ci sia un modo semplice per farlo…?) e non è un grosso problema, quindi sono solo curioso, più che altro.
1 Mi Piace
Ciao a tutti,
Le immagini importate hanno un rapporto larghezza/altezza errato a meno che non rigeneri i post. Vorrei trovare un modo per ottenere il rapporto corretto (ad esempio durante l’importazione) senza dover rigenerare.
Descrizione più dettagliata del problema:
Per quanto ho capito, i post importati non vengono “rigenerati” (baked) quando Discourse crea il post corrispondente (anche se il campo cooked viene generato in qualche modo), ed è per questo che importare i post è molto più veloce rispetto alla rigenerazione di post esistenti su Discourse.
Il mio problema è che le immagini importate hanno un rapporto larghezza/altezza errato.
Esempio del testo grezzo di Discourse relativo a un’immagine importata:
Contenuto del campo “cooked”:
<img src="https://d11a6trkgmumsb.cloudfront.net/original/3X/0/3/0379f53ed8221730ccb31807238e9c46e9fe1d37.jpeg" alt="SH-MUniFrame.JPG" data-base62-sha1="6Li1nnjbA8zDz6YJ3FqeYHV5zXK" width="517" height="500" class="d-lazyload">
Come appare l’immagine nel post:
Ecco l’immagine originale: https://d11a6trkgmumsb.cloudfront.net/original/3X/f/7/f73a0ae8594219dd5a1620e59b3c17f9b02b1583.jpeg
La dimensione originale dell’immagine nel database vBulletin è:
select width, height from filedata where filedataid = 76237
+-------+--------+
| width | height |
+-------+--------+
| 600 | 800 |
+-------+--------+
La mia interpretazione è che l’attributo height sia limitato dalle impostazioni di Discourse, che impostano un’altezza massima di 500px, da qui lo stesso valore nell’attributo height del tag <img>. L’attributo width del tag <img> è stato modificato da 600 a 517, ma non riesco a capire come e perché.
Il problema si presenta anche per le immagini più vecchie che hanno 0 sia nel campo larghezza che in quello altezza degli allegati vBulletin. Anche queste presentano lo stesso errore nel rapporto altezza/larghezza. Non so se questi valori vengano effettivamente utilizzati durante l’importazione.
Il problema viene risolto rigenerando (ricostruendo l’HTML) il post. L’immagine verrà quindi ridimensionata correttamente e verrà aggiunto il visualizzatore di immagini. Tuttavia, ho 1,6 milioni di post e preferirei evitare di rigenerarli tutti.
Una soluzione rapida sarebbe utilizzare questo CSS sul mio Discourse:
.cooked img:not(.emoji) {
height: auto;
width: auto;
}
Ma ciò implicherebbe che nessuno potrebbe scegliere una dimensione arbitraria quando carica un’immagine, e potrebbero esserci effetti collaterali di cui non sono a conoscenza.
Avete qualche idea su come ottenere un rapporto corretto tra larghezza e altezza per le immagini importate negli allegati?
Sospetto che sia perché non hai permesso loro di cuocere dopo l’importazione. Non riesco a immaginare un modo per risolvere il problema senza rifare la cottura dei post. Forse vorresti rifare la cottura solo dei post rotti invece di tutti?
1 Mi Piace
Dovrebbero essere rielaborate automaticamente nel tempo dopo l’importazione? A partire dall’ultimo o dal primo post creato?
Non è comunque un grosso problema e, se non vengono rielaborate automaticamente, probabilmente avvierò una nuova elaborazione di tutti i post e sarò paziente, anche se ammetto che ho letto questo post qualche giorno fa e mi ha spaventato un po’: My journey into a massive posts rebake job. Ho anche delle domande a riguardo, ma le farò nel topic appropriato. 
Mmh sì, sembra che sia il mio codice. Scusa per questo. 
Questo dovrebbe seguire il seguente pattern:
batches(BATCH_SIZE) do |offset|
(Codice SQL)
LIMIT #{BATCH_SIZE}
OFFSET #{offset}
(Altro codice)
end
1 Mi Piace
Alza semplicemente l’impostazione del sito lunghezza massima del post prima dell’importazione.
2 Mi Piace