Grazie per le preziose informazioni!

Ho un’altra domanda, riguardo alla query SQL che seleziona gli utenti vBulletin.

Quando ho importato il mio vecchio forum phpbb su Discourse 3 anni fa, c’erano circa 20.000 utenti. Ovviamente, la maggior parte degli utenti erano account inattivi. In questi 3 anni, Discourse ha fatto la sua pulizia degli utenti inattivi, e ora abbiamo un numero più realistico di 3.000 membri.

Quando ho importato i miei 180.000 utenti da vBulletin e ho chiesto a Discourse di eseguire la pulizia in modo aggressivo, mi sono rimasto con 27.000 utenti, il che sembra corretto.

Sul mio vBulletin, dato che:

1. Tutti i messaggi pubblicati dagli utenti sui profili di altri utenti vengono importati su Discourse come argomenti senza categoria e senza titolo, che non aggiungono nulla se non rumore inutile, e
2. La stragrande maggioranza degli utenti che hanno pubblicato solo sui profili di altri utenti sembrano essere spammer,
   vorrei eseguire la pulizia durante l’importazione e non dopo.

Non conosco bene tutto il database vBulletin, che è un po’ confuso con la sua struttura dei nodi, ma vorrei importare solo gli utenti che hanno pubblicato almeno 1 argomento o risposta.
Mi sembra che gli argomenti e le risposte riempiano il campo lastpostid nella tabella utenti vBulletin, ma i messaggi pubblici del profilo no.

Sì, intendo modificare

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

in:

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email, u.lastpost
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
    WHERE u.lastpost > 0
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

Aggiungo semplicemente WHERE u.lastpost > 0.

Un conteggio con questa query mi dà 25.000 utenti, rispetto ai 27.000 utenti attivi della mia precedente importazione, dopo la pulizia di Discourse ma con ancora questi argomenti senza titolo (ex messaggi pubblici del profilo). Questo significherebbe che circa 2.000 utenti avrebbero pubblicato solo sui profili di altri utenti, il che non è un numero assurdo.

Credi che il mio ragionamento sia corretto e che aggiungere WHERE u.lastpost > 0 pulirà bene la mia base utenti senza alcun effetto dannoso?

Dipende da dove si trovava il tuo database. Se è stato migrato da phpBB a vBulletin o se ha subito numerosi aggiornamenti di vBulletin, questa logica potrebbe essere errata.

Il meglio che puoi fare è verificare la tua ipotesi eseguendo ulteriori query, ad esempio elencando tutti i post pubblicati dagli utenti senza un lastpost.

Inoltre, se hai plugin come “mi piace” o “votazioni”, potresti rimuovere utenti che non dovresti rimuovere.

La mia strategia è essere molto conservativo nell’eliminazione o nell’esclusione di elementi. Lo spazio di archiviazione è economico.

Grazie, farò come dici; preferisco essere prudente.
Lascio che Discourse faccia la sua pulizia nel tempo.

Sto aggiungendo espressioni regolari per la pulizia dei post personalizzati allo script di migrazione da giorni, perché il forum è molto vecchio ed è stato migrato da phpBB prima di vBulletin, quindi c’era molto da sistemare, ma penso e spero di essere vicino alla conclusione.

Non conosco molto vBulletin, ma il forum su cui sto lavorando usava vBulletin 5.6 e alcune immagini esterne che avevo pubblicato usavano questa sintassi nel database di vBulletin:
[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/forum.monocycle.info\/uploads\/default\/original\/2X\/3\/396192845ba93e7df2a6109a2608072efa21ee32.jpeg"}[/IMG2]
Non sono sicuro se questo sia qualcosa che è stato “dimenticato” nel tuo script o se l’amministratore del forum abbia usato qualche plugin che generava questi tag img2.

Comunque, li ho sistemati con questo codice:

    raw = raw.gsub(/\[img2=json\].+?(http.+?).}\[\/img2\]/i) {"\n#{$1}\n"}

Ho però una domanda: Discourse rifarà automaticamente il rebake dei post importati nel tempo? Se sì, inizierà dai post più recenti?

Ciao di nuovo,
Il mio forum ha circa 1000 tag, ma probabilmente non li useremo su Discourse. Inoltre, questi tag sono probabilmente un vero disastro. Posso semplicemente commentare questa riga nell’importatore:

    import_tags

Oppure potrebbero esserci dei danni collaterali?

Puoi tranquillamente commentarlo.

È sicuro non attendere che Sidekiq abbia completato i suoi lavori dopo un’importazione?

Ho importato i miei utenti e questo è lo stato attuale di Sidekiq.

image1182×324 27.3 KB

Cosa succede a questi task se creo un backup e lo ripristino su un forum di produzione?

No, anche se una rigenerazione completa ricreerà la maggior parte di questi lavori, ti consiglio assolutamente di attendere.

Continueranno a essere eseguiti… sull’istanza di importazione.
Non verranno inclusi nel backup né trasferiti al forum di produzione.

Grazie!

A causa di alcuni messaggi di errore durante il ripristino dei backup (che non impediscono il completamento del ripristino o il funzionamento del forum), mi chiedevo se potesse essere dovuto al fatto che non ho aspettato che Sidekiq concludesse il suo lavoro.

Ho avviato una nuova importazione da vBulletin: ho importato solo i gruppi e 30.000 utenti nel mio Discourse di sviluppo, ho atteso alcune decine di minuti, quindi ho creato un backup e l’ho ripristinato su un’installazione basata su Docker. Il ripristino è andato a buon fine, ma i log mostrano questi errori:

ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "users" does not exist LINE 1: SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 ^ ) lib/a
10:03 pm
7
ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "user_auth_tokens" does not exist LINE 1: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((...

Sono incoerenti e gli errori relativi alle relazioni variano da un backup all’altro.
Non riesco a capire da dove provengano.

TL;DR: Non credo che quegli errori siano in alcun modo correlati all’importazione.

Li ho già visti prima; penso si tratti di una condizione di gara che si verifica perché il database viene accessibile mentre il backup viene ripristinato.

Ciò potrebbe essere dovuto al traffico regolare in arrivo sul tuo server o a un processo Sidekiq che non è stato messo in pausa. In entrambi i casi, non è dannoso. Se fossi in te, ignorerei completamente tutti gli errori PG che si verificano prima che il ripristino sia completato.

È rassicurante!

Il punto è che non solo i messaggi in sé mi spaventano un po’, ma lo sono anche perché:

1. si verificano per ogni (o quasi? ) backup che ho creato dall’inizio della mia importazione, sia che io ripristini il backup in un forum di sviluppo locale o in un’installazione Docker online.
2. impediscono al registro di ripristino (nell’interfaccia di backup di Discourse) di continuare a essere scritto nell’interfaccia di Discourse mentre viene eseguita il ripristino: rimane bloccato su “decompressione dell’archivio” (o “Creazione delle funzioni mancanti nello schema discourse_functions…” se si tratta di un backup senza file caricati).
   Sembra che qualcosa si sia bloccato, ma se aspetto, dopo un po’ vengo sempre disconnesso automaticamente e, quando accedo di nuovo, sembra che l’importazione sia andata a buon fine nonostante questi messaggi di errore.

Visto che il forum funziona (a parte la modifica delle categorie che causa un errore 502, che ho descritto in un altro thread), ho solo paura che il forum funzioni… Fino a quando, per qualche motivo tra settimane/mesi/anni, smetterà di funzionare a causa di qualcosa che non ho individuato in anticipo, e questo è proprio ciò che non voglio che accada, soprattutto considerando che lavoro su questa importazione ogni giorno da un mese e non solo.

Comunque, grazie per il tuo aiuto, è molto apprezzato. Sto dedicando molta energia a questo lavoro di importazione non retribuito per una grande comunità, e ricevere risposte alle mie domande è sempre un sollievo.

Prima di tutto, grazie per aver pubblicato questo. Ho appena provato a importare vBulletin 3.7.x. Ho seguito tutti i passaggi, ma quando ho eseguito lo script di importazione mi dice che non può connettersi, anche se riesco a connettermi. Avete qualche idea?

root@uat-app:/var/www/discourse# export DB_NAME="vb4"
root@uat-app:/var/www/discourse# export DB_USER="root"
root@uat-app:/var/www/discourse# export DB_PW="1234"
root@uat-app:/var/www/discourse# export TABLE_PREFIX="vbulletin"
root@uat-app:/var/www/discourse# export ATTACHMENT_DIR='/shared/vbulletin'
root@uat-app:/var/www/discourse# export TIMEZONE="America/Vancouver"
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost vuole vb4
Caricamento dei gruppi esistenti...
Caricamento degli utenti esistenti...
Caricamento delle categorie esistenti...
Caricamento dei post esistenti...
Caricamento degli argomenti esistenti...
==================================================
Accesso negato per l'utente 'root'@'localhost'
Impossibile connettersi al database.

Hostname: localhost
Username: root
Password: 1234
database: vb4

Modifica lo script o imposta queste variabili d'ambiente:

export DB_HOST="localhost"
export DB_NAME="vbulletin"
export DB_PW=""
export DB_USER="root"
export TABLE_PREFIX="vb_"
export ATTACHMENT_DIR '/path/to/your/attachment/folder'

Uscita.

Di seguito puoi vedere che riesco ad accedere al database utilizzando le stesse credenziali e ho validato il nome del database e il prefisso della tabella.

root@uat-app:/var/www/discourse# mysql -uroot -p1234 -hlocalhost
Benvenuto nel monitor MariaDB. I comandi terminano con ; o \g.
Il tuo ID connessione MariaDB è 70
Versione del server: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab e altri.

Digita 'help;' o '\h' per ottenere aiuto. Digita '\c' per cancellare l'istruzione di input corrente.

MariaDB [(none)]> use vb4;
Lettura delle informazioni sulla tabella per il completamento dei nomi di tabella e colonna
Puoi disattivare questa funzione per un avvio più rapido con -A

Database cambiato
MariaDB [vb4]> select * from information_schema.tables where table_schema = 'vb4' and table_name = 'vbulletinpost'
    -> ;
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME    | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME         | UPDATE_TIME         | CHECK_TIME          | TABLE_COLLATION   | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT | MAX_INDEX_LENGTH   | TEMPORARY |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| def           | vb4          | vbulletinpost | BASE TABLE | MyISAM |      10 | Dynamic    |    1037509 |            356 |   370191960 | 281474976710655 |     53087232 |         0 |        1046506 | 2020-11-14 14:27:01 | 2020-11-14 14:27:28 | 2020-11-14 14:27:32 | latin1_swedish_ci |     NULL |                |               | 288230376151710720 | N         |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
1 riga nel set (0.001 sec)

MariaDB [vb4]>

Inoltre, ho esportato le immagini degli avatar da /admincp/avatar.php?do=storage e le ho salvate in tre cartelle diverse come segue:

/shared/vbulletin/signaturepics/
/shared/vbulletin/customprofilepics/
/shared/vbulletin/customavatars/

Devo quindi specificare la cartella padre in questo modo? Oppure devo prendere il contenuto delle tre cartelle e metterlo tutto in una sola?

export ATTACHMENT_DIR='/shared/vbulletin'

L’unica ipotesi che mi viene in mente è che la tua password contenga caratteri strani?

In realtà non sono altro che caratteri alfabetici e numerici. Comunque, ho appena riprovato e confermato che non funziona finché non imposto esplicitamente la password. Ho anche notato che le istruzioni devono essere aggiornate, quindi incollo qui quello che funziona per me.

Le istruzioni devono essere aggiornate. Ecco cosa funziona per me a partire da novembre 2020. Si noti che è effettivamente meglio eseguire questa importazione utilizzando screen, poiché l’importazione richiederà ore, e l’uso di nohup probabilmente non sarà utile poiché lo script di importazione aggiornerà costantemente il numero di ogni elemento importato, rendendo il file stdout probabilmente molto grande.

Installare il Database per i Dati vBulletin

Scaricare gli Ultimi Pacchetti

Si noti che MySQL non è più disponibile a meno che il repository Oracle MySQL non venga aggiunto esplicitamente all’elenco dei repository. MariaDB ha sostituito MySQL.

root@uat-app:~# apt-get update
root@uat-app:~# apt-get install libmariadb-dev
root@uat-app:~# apt-get install default-mysql-server

Avviare il Database

root@uat-app:~# service mysql status
[info] MariaDB è arrestata..
root@uat-app:~#
root@uat-app:~# service mysql start
[ ok ] Avvio del server database MariaDB: mysqld.
root@uat-app:~# service mysql status
[info] /usr/bin/mysqladmin Ver 9.1 Distrib 10.3.25-MariaDB, per debian-linux-gnu su x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab e altri.

Versione del server 10.3.25-MariaDB-0+deb10u1
Versione del protocollo 10
Connessione Localhost tramite socket UNIX
Socket UNIX /var/run/mysqld/mysqld.sock
Tempo di attività: 4 secondi

Thread: 7 Domande: 461 Query lente: 0 Aperture: 177 Pulizia tabelle: 1 Tabelle aperte: 31 Query al secondo in media: 115.250.

Installare i Gem per la Connettività al Database

Di seguito si mostra che l’ultimo ‘bundle’ non accetta alcune delle flag nelle istruzioni originali e c’è la necessità di disattivare la modalità ‘deployment’.

root@uat-app:~# echo "gem 'mysql2', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# echo "gem 'php_serialize', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle install --no-deployment --without test --without development --path vendor/bundle'
[DEPRECATED] La flag `--path` è deprecata perché si basa sul fatto che venga ricordata tra le invocazioni di bundler, cosa che bundler non farà più nelle versioni future. Si prega invece di utilizzare `bundle config set path 'vendor/bundle'` e di smettere di usare questa flag
[DEPRECATED] La flag `--without` è deprecata perché si basa sul fatto che venga ricordata tra le invocazioni di bundler, cosa che bundler non farà più nelle versioni future. Si prega invece di utilizzare `bundle config set without 'development'` e di smettere di usare questa flag
Stai cercando di installare in modalità deployment dopo aver modificato
il tuo Gemfile. Esegui `bundle install` altrove e aggiungi il
Gemfile.lock aggiornato al controllo versione.

Se questa è una macchina di sviluppo, rimuovi il blocco del file /var/www/discourse/Gemfile eseguendo `bundle config unset deployment`.

Le dipendenze nel tuo gemfile sono cambiate

Hai aggiunto al Gemfile:
* mysql2
* php_serialize

Aggiornare la Configurazione ed Esegui di Nuovo l’Installazione

Verifica tramite CLI

La verifica della configurazione ha confermato che è impostata in modalità ‘deployment’.

root@uat-app:/var/www/discourse# bundle config list
Le impostazioni sono elencate in ordine di priorità. Il valore superiore verrà utilizzato.
deployment
Impostato per la tua app locale (/var/www/discourse/.bundle/config): true

jobs
Impostato per la tua app locale (/var/www/discourse/.bundle/config): 4

retry
Impostato per la tua app locale (/var/www/discourse/.bundle/config): 3

path
Impostato per la tua app locale (/var/www/discourse/.bundle/config): "vendor/bundle"

without
Impostato per la tua app locale (/var/www/discourse/.bundle/config): [:development, :test]

Verifica Ispezionando il File di Configurazione

Di seguito si esegue la stessa verifica ispezionando il file di configurazione.

root@uat-app:/var/www/discourse# cat /var/www/discourse/.bundle/config
---
BUNDLE_DEPLOYMENT: "true"
BUNDLE_JOBS: "4"
BUNDLE_RETRY: "3"
BUNDLE_PATH: "vendor/bundle"
BUNDLE_WITHOUT: "development:test"

Aggiornare la Configurazione

root@uat-app:/var/www/discourse# bundle config set path 'vendor/bundle'
La tua applicazione ha impostato path su "vendor/bundle". Questo sovrascriverà il valore globale che stai attualmente impostando
root@uat-app:/var/www/discourse# bundle config set without 'development:test'
La tua applicazione ha impostato without su "development:test". Questo sovrascriverà il valore globale che stai attualmente impostando
root@uat-app:/var/www/discourse# bundle config unset deployment

Validare di Nuovo la Configurazione

root@uat-app:/var/www/discourse# bundle config list
Le impostazioni sono elencate in ordine di priorità. Il valore superiore verrà utilizzato.
path
Impostato per la tua app locale (/var/www/discourse/.bundle/config): "vendor/bundle"
Impostato per l'utente corrente (/root/.bundle/config): "vendor/bundle"

without
Impostato per la tua app locale (/var/www/discourse/.bundle/config): [:development, :test]
Impostato per l'utente corrente (/root/.bundle/config): [:development, :test]

jobs
Impostato per la tua app locale (/var/www/discourse/.bundle/config): 4

retry
Impostato per la tua app locale (/var/www/discourse/.bundle/config): 3

Tentare di Eseguire di Nuovo l’Installazione

Esegui di nuovo l’installazione per i Gem ed esci dal contenitore.

root@uat-app:/var/www/discourse# su discourse -c 'bundle install'
...........
Bundle completo! 125 dipendenze Gemfile, 163 gem ora installate.
Le gem nei gruppi development e test non sono state installate.
Le gem bundler sono installate in `./vendor/bundle`
root@uat-app:/var/www/discourse# exit

Creare la Cartella per i Dati vBulletin

Creare la Cartella

[root@uat standalone]# pwd
/var/discourse/shared/standalone
[root@uat standalone]# mkdir vbulletin

Copiare il Database vBulletin

[root@uat standalone]# scp <login user>@<vbulletin server IP>:/home/backup/vbulletin/vbulletin-2020-11-14-03:30:01.sql.bz2 ./vbulletin/.

Decomprimere il Database vBulletin

[root@uat containers]# docker exec -it app bash
root@uat-app:/# cd /shared/vbulletin
root@uat-app:/shared/vbulletin# bunzip2 vbulletin-2020-11-14-03\:30\:01.sql.bz2

Configurare la Fonte dei Dati

Creare il Database vb4

root@uat-app:/shared/vbulletin# mysql -uroot -p -e 'CREATE DATABASE vb4'
Inserisci password:

Importare vBulletin in MariaDB

root@uat-app:/shared/vbulletin# mysql -uroot -p vb4 < vbulletin-2020-11-14-03\:30\:01.sql
Inserisci password:

Decomprimere gli Archivi dei Profili

[root@uat vbulletin]# tar xvfz signaturepics.tar.gz
[root@uat vbulletin]# tar xvfz customavatars.tar.gz
[root@uat vbulletin]# tar xvfz customprofilepics.tar.gz

Aggiornare la Password Root del Database

root@uat-app:/var/www/discourse# mysql -uroot -p
Inserisci password:
Benvenuto nel monitor MariaDB. I comandi terminano con ; o \g.
Il tuo ID connessione MariaDB è 77
Versione del server: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab e altri.

Digita 'help;' o '\h' per l'aiuto. Digita '\c' per cancellare l'istruzione di input corrente.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
Query OK, 0 righe interessate (0.001 sec)

MariaDB [(none)]> quit
Bye

Importare in Discourse

Impostare i Dettagli di Connessione alla Fonte dei Dati

[root@uat vbulletin]# export DB_NAME="vb4"
[root@uat vbulletin]# export DB_USER="root"
[root@uat vbulletin]# export DB_PW="1234"
[root@uat vbulletin]# export TABLE_PREFIX="vbulletin"
[root@uat vbulletin]# export ATTACHMENT_DIR='/shared/vbulletin'
[root@uat vbulletin]# export TIMEZONE="America/Vancouver"
[root@uat vbulletin]# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost vuole vb4
Caricamento gruppi esistenti...
Caricamento utenti esistenti...
Caricamento categorie esistenti...
Caricamento post esistenti...
Caricamento topic esistenti...

importazione gruppi...
15 / 15 (100.0%) [3272 elementi/min] n]
importazione utenti
117 / 11033 ( 1.1%) [145 elementi/min] in]

Quindi il problema con la tua connessione iniziale al database era la mescolanza di librerie?

Non credo. Ho appena modificato esplicitamente la password ed è stato possibile eseguirlo. Ora sto riscontrando un problema durante l’importazione dei messaggi privati. Sto vedendo molte voci come le seguenti. Hai idea di cosa sia?

importazione dei messaggi privati...
      139 / 177409 (  0.1%)  [399 elementi/min]  uno degli ID dei partecipanti è nil -- [nil, 270]
pm-149 non ha un destinatario (a:1:{i:486;s:5:"TonyN";})
      364 / 177409 (  0.2%)  [418 elementi/min]  uno degli ID dei partecipanti è nil -- [nil, 276]
pm-420 non ha un destinatario (a:1:{i:623;s:14:"the other side";})
      571 / 177409 (  0.3%)  [414 elementi/min]  uno degli ID dei partecipanti è nil -- [nil, 445]
pm-702 non ha un destinatario (a:1:{i:767;s:6:"greatg";})
      572 / 177409 (  0.3%)  [414 elementi/min]  uno degli ID dei partecipanti è nil -- [nil, 445]
      605 / 177409 (  0.3%)  [416 elementi/min]  uno degli ID dei partecipanti è nil -- [nil, 461]

O non quegli utenti sono stati importati per qualche motivo (la mancanza di un indirizzo email è stata una causa, ma dovrebbe essere risolto ora), oppure per qualche altro motivo il codice che cerca i nomi utente importati non funziona (magari a causa della maiuscola/minuscola del nome utente?).

@pfaffman sì, sembra proprio così, anche se non è chiaro su alcuni dettagli specifici. Diamo un’occhiata al primo, per esempio.

1. Cosa significa pm-149?
2. Per a:1:{i:486;s:5:"TonyN";}, il testo “TonyN” sembra essere il nome utente, ma cosa rappresentano gli altri numeri?
3. E [nil, 270]? Cosa indica 270?

Se riesco a capire di cosa si lamenta, posso almeno provare a consultare il database per vedere se ci sono problemi nei dati. Ma non sono sicuro di cosa significhino realmente queste cose.

A proposito, ho anche notato che tutti i forum importati hanno i permessi impostati per tutti. Questo significa che i forum riservati solo ai moderatori sono stati impostati come visibili a tutti. C’è un modo per controllare questo?

Scusa. Non ricordo abbastanza bene da spiegarlo. Questo è tutto il aiuto gratuito che posso offrire su questo argomento.

Certo. Vedi Understanding groups and category permissions

Alcuni importatori si impegnano a importare i gruppi, ma pochi di loro sanno come applicare tali autorizzazioni alle categorie che vengono importate. Dovrai sistemarle manualmente.

Seguendo le istruzioni di @titusc, sembra che abbia problemi nell’importare il database…

root@DO-Discourse-app:/shared/vbulletin# mysql -uroot -p vb4 < CC12-Sat-Full-Backup.sql
Inserisci la password:
ERRORE 1265 (01000) alla riga 4928: Dati troncati per la colonna 'method' alla riga 1
root@DO-Discourse-app:/shared/vbulletin#

Hai qualche suggerimento su cosa stia cercando?

N/D Sono errori nel database originale…