Plugin per aiutare a mappare i thread pre-migrazione dopo la migrazione

Sviluppatore
1

Ciao, io e il mio gruppo di pazzi idioti siamo molto vicini a migrare finalmente il nostro forum Vbulletin3 in Discourse dopo aver scritto uno script ad hoc che è finalmente riuscito a migrare tutti i 21 milioni di risposte dal database originale a Discourse.

Ora abbiamo il problema dei link agli argomenti/risposte scritti nelle risposte stesse.

Nella migrazione che abbiamo scritto, scriviamo una mappatura degli ID degli “vecchi” argomenti e post e a cosa corrispondono in Discourse.

Ad esempio:

   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

Quello a cui stavo pensando ora è un plugin che semplicemente intercetti i link al vecchio formato del forum e li trasformi con riferimento al nuovo thread/risposta.

Quindi, ad esempio, qualcosa come:

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

Attiverebbe una ricerca di query utilizzando topics_custom_field per il valore 123456, troverebbe il topic_id di Discourse, quindi eseguirebbe una query sulla tabella topic_links con quell’ID e troverebbe l’url. Infine, lo sostituirebbe nel post sul lato client (supponendo che venga utilizzato JavaScript per manipolare il contenuto).

Qualcosa di simile per i post.

Tuttavia, non riesco a trovare buoni esempi su come iniziare a creare qualcosa del genere per Discourse.
Qualcuno può darmi qualche suggerimento, esempio o plugin che farebbe qualcosa di simile (controllare le risposte per una sottostringa e sostituirla, interrogare l’API? DB? per un valore per recuperarne un altro?).

Grazie

2

Questo esiste già nel core, si chiama Permalinks e l’importatore VB4 esistente ha codice per questo

Dovresti inserire qualcosa come /showthread\\.php\\?(\\d*)/thread/\\1 nell’impostazione permalink_normalizations.

2 Mi Piace
3

Solo per confermare, dovrei eseguire questa logica dopo che la migrazione è stata completata, giusto?
Quindi ripassa tutte le risposte e cambia i permalink.

4

Cosa intendi con modifiche? Hai già i permalink?

5

Quando migriamo il contenuto di una risposta con, ad esempio: https://oldforum.something.com/showthread.php?t=123456 non sa quale id avrà quell’argomento su Discourse… vero?

6

funzionerà se utilizzi il codice sopra per creare permalink.

showthread.php?t= si riferisce a un argomento/discussione e non a una risposta, tra l’altro

1 Mi Piace
7

Stavo solo usando quel link come esempio :slight_smile:

Sfortunatamente non possiamo usare quel codice perché l’importazione impiega un’eternità per importare 20 milioni di post e l’importazione di massa semplicemente non funziona. Mancano dei pezzi.

Ecco perché abbiamo dovuto scrivere il nostro script di migrazione. Fa tutto (pm, utenti, gruppi di utenti, categorie, discussioni, risposte) in circa 6 ore con 4 core, 8 GB di RAM, ma abbiamo notato che mancavano i permalink :slight_smile:

8

Forse potresti considerare la soluzione di mappatura nginx per i pre-permalink? Redirect vBulletin URLs to Discourse URLs

1 Mi Piace
9

Abbiamo discusso internamente e faremo semplicemente una seconda passata quando tutte le risposte saranno state migrate.

Grazie per aver condiviso idee con me Richard :heart:

10

Il tuo script ha creato gli import_id? Se sì, anche se non hai creato i permalink, puoi elaborarli abbastanza rapidamente per crearli.

11

Sì, Jay, lo facciamo.

Stavamo cercando di evitare di scorrere nuovamente tutte le oltre 20 milioni di risposte, ma ci siamo resi conto che soluzioni alternative (plugin, reindirizzamento nginx, ecc.) sarebbero piuttosto complicate o si baserebbero su fattori esterni che ne farebbero una soluzione raffazzonata, quindi semplicemente scorreremo nuovamente le risposte ed elaboreremo i permalink. Aggiungerà del tempo alla migrazione, ma si spera non troppo.

Tutto il resto è “cotto” al volo poiché sappiamo cosa “grezzo” deve essere convertito in HTML.

Per i permalink non possiamo farlo poiché se viene aggiunto un permalink con una modifica, potrebbe fare riferimento a un topic non ancora elaborato (ID topic più alto) e questi non vengono trovati nella tabella topics_custom_field al momento della sua elaborazione.

12

Non so come tu possa aver creato topic_custom_fields senza prima creare l’argomento. Penserei che potresti fare qualcosa come

TopicCustomField.each do |tcf|

e creare i permalink, ma c’è molto che non so del tuo codice.

13

Permettimi di chiarire:

I topic e tutte le loro risposte vengono importati seguendo gli ID dei topic dal più piccolo al più grande nel database vbulletin. Ciò significa anche che stiamo importando in ordine cronologico.

Tuttavia, ciò porterebbe a pensare che se mai trovassi un riferimento a un altro topic, si tratterebbe sempre di uno che è già esistito.

Ma ci sono casi in cui ciò non è vero, solo un paio di esempi:

  • Topic diviso con un commento che ha portato alla divisione. La divisione avverrebbe con un ID maggiore ma esistente in un topic con un ID minore.
  • Modifica per i futuri lettori in cui i post dei vecchi topic fanno riferimento a quelli più recenti.

Quindi, sì, mentre topic_custom_field viene generato e riempito durante il progredire dell’importazione, come spiegato nel primissimo topic, non è affidabile farlo “al volo” perché non si può essere sicuri di trovare sempre la giusta corrispondenza tra gli ID.

È necessario un altro passaggio dopo il completamento dell’importazione completa.

Per quanto riguarda TopicCustomField.each do |tcf|, non sono sicuro di cosa farebbe la parte tcf. Ruby non è una lingua che ho imparato. Il nostro script è scritto in C# poiché la maggior parte delle persone che si sono offerte di lavorarci lo usano già per lavoro.

1 Mi Piace