Valutazione pre-migrazione per un grande forum Drupal 7

Migrazione
1

Ciao a tutti, possiedo e gestisco quello che credo sia uno dei più grandi forum basati su Drupal su Internet, con quasi 2 milioni di post. Drupal 7 sta morendo, e Drupal 8/9 si stanno trasformando più in un framework per programmatori web che in un sistema di gestione dei contenuti pronto all’uso. Le nuove versioni di Drupal semplicemente non offrono i moduli di terze parti di cui ho bisogno affinché il mio forum continui con le sue funzioni di base, e grazie alle gioie di PHP e alle molte altre stranezze di Drupal, l’aggiornamento sarebbe altrettanto infernale quanto la migrazione a una piattaforma completamente diversa. Quindi dovrò ingoiare il rospo e migrare a qualcos’altro. Sono abbastanza sicuro che dovrà essere Discourse a causa di un aspetto unico dello stile della mia comunità di forum: sono l’unico moderatore, e non è il mio lavoro a tempo pieno. Quindi, nel corso degli anni, ho utilizzato i framework flessibili Rules e Flag in Drupal per creare un sistema frammentato di moderazione della comunità di spam e post offensivi, con rimozione automatica dei post e/o chiusura degli account utente a determinate soglie basate su quanto è nuovo l’utente e quanti utenti lo hanno segnalato, tenendo conto anche della novità e dell’attività di segnalazione recente degli utenti che segnalano. In altre parole, è quasi esattamente ciò che Discourse ha implementato. Sono davvero felice di vedere che Discourse ha riconosciuto il valore della moderazione della comunità e ha implementato un sistema così completo e ben studiato “out-of-the-box”. Drupal 7 era ed è tuttora l’unico CMS sufficientemente flessibile da consentire questo tipo di funzionalità personalizzate senza essere uno sviluppatore esperto, cosa che non sono. Quindi sembra che passerò a Discourse. Tuttavia, ho alcune preoccupazioni.

  1. Sistema di moderazione della comunità: Il nostro forum sta attualmente valutando un’installazione playground di Discourse. Sono impressionato da quanto sia completo e ben studiato l’intero sistema. Ma la comunità ha notato alcune stranezze:
    • Non mi piace affatto come nasconde i post rimossi automaticamente dietro “Visualizza contenuti ignorati”. Se un post è abbastanza brutto da essere rimosso dalla comunità, è o altamente offensivo o puro spam, e non voglio che i visitatori o gli utenti abbiano nemmeno l’opzione di visualizzarlo. Questo è particolarmente problematico nel caso di argomenti che sono spam o hanno un titolo offensivo. E i crawler dei motori di ricerca non vedrebbero il contenuto spam nascosto? È possibile configurare il tempo senza intervento dell’utente prima che un post spam nascosto automaticamente venga completamente eliminato dalla vista pubblica? E per quanto riguarda gli argomenti e i post che sono stati segnalati dalla comunità come inappropriati?
    • Ho letto qui che “Nota: tutti i valori menzionati sopra sono le impostazioni predefinite. Possono essere modificati dagli amministratori nelle impostazioni del sito” per quanto riguarda le soglie che portano alla rimozione del post e/o al silenzio dell’utente, ma non vedo quelle impostazioni granulari nella mia istanza di test di Discourse. Tutto ciò che riesco a trovare è “sensibilità nascondi post” e “sensibilità silenzia nuovo utente”, ma non capisco a cosa si riferisca effettivamente quella sensibilità in termini concreti.
    • Vorrei rimuovere la motivazione “fuori tema” per segnalare un post. La nostra comunità di forum è molto rilassata in questo senso e ha una cultura del forum in cui i post fuori tema sono molto comuni e ben accettati. Aggiornamento: Sembra che questo possa funzionare.
  2. Migrazione dei messaggi privati: Il forum attuale ha quasi un milione di thread di messaggi privati utilizzando il modulo Drupal 7 privatemsg, e lo script di migrazione Drupal → Discourse non lo gestisce. Questa sembra un’omissione importante, perché nonostante sia un modulo di terze parti (nel tipico stile Drupal) è fondamentalmente la funzionalità di messaggistica privata de facto che gli amministratori di Drupal 7 utilizzano.
  3. Conversione del formato dei post: Sfortunatamente, il forum attuale utilizza un mix di post in puro HTML e Textile. Capisco che lo script di migrazione possa gestire il puro HTML (correggetemi se sbaglio) ma non Textile. Se possibile, vorrei convertire i post Textile in HTML o Markdown, a seconda di cosa sia più facile. Mi è stato detto che Pandoc può essere agganciato allo script di migrazione, ma che ciò aumenterebbe enormemente il tempo di migrazione. Ho cercato moduli Drupal per convertire il formato dei post esistenti, ma ho trovato solo questo, che non supporta l’elaborazione batch per l’enorme quantità di post, e non supporta il paradigma dei “commenti” di Drupal, che costituiscono la stragrande maggioranza dei “post” da convertire. Quindi ho pensato di fare una sorta di ricerca/sostituzione offline sul file di dump del database con sed, simile a quanto descritto qui. Suggerimenti o soluzioni sarebbero benvenuti. Sono un utente Linux esperto e ho lavorato occasionalmente con regexp, ma non sono ancora bravo. Modifica: Questo è un’opzione interessante per trovare/sostituire una volta che i dati grezzi sono in Discourse.
  4. Annunci: Sono davvero felice di vedere che il Plugin Annunci per Discourse sembra essere maturato molto da quando l’ho esaminato l’ultima volta. Capisco che gli annunci interni mi permetteranno di posizionare banner immagine in punti specifici con un link di destinazione quando cliccati, e che se più annunci sono assegnati allo stesso punto verranno selezionati casualmente, corretto? Tuttavia, non ho idea di come gestire il paradigma mobile. Nel mio forum attuale ho un banner orizzontale in alto e tre banner verticali nella barra laterale sinistra, nessuno dei quali sarebbe fattibile per gli utenti mobili nell’interfaccia reattiva di Discourse. Modifica: Potrebbe essere necessario modificare il Plugin Annunci per le mie esigenze, offerta a pagamento qui.
  5. Permalink: Lo schema degli URL di Drupal ha due componenti principali: /node/XXXXXXX e collegamenti a commenti specifici all’interno di quei nodi /comment/YYYYYYY#comment-YYYYYYY (YYYYYYY è lo stesso in entrambe le occorrenze). Lo script di migrazione Drupal 7 → Discourse manterrà automaticamente quei collegamenti in modo che i collegamenti nei post ad altri thread o post funzionino ancora e mantengano la SEO? Che dire di un file sitemap.xml per i motori di ricerca?
  6. Elaborazione batch: Durante la migrazione verrà eseguita in batch? Cosa succede se incontra un errore, dopo averlo corretto continuerà o richiederà di ricominciare dall’inizio?
  7. Utenti con vecchi dispositivi Apple: Naturalmente capisco i pericoli dell’utilizzo di browser obsoleti. Per Windows e vecchi dispositivi Android c’è quasi sempre un modo per installare un browser moderno compatibile con Discourse. Ma sono preoccupato per uno dei miei utenti che afferma di avere un Mac del 2015 che non riceve aggiornamenti e non ha modo di installare nulla oltre alla vecchia versione di Safari che gli mostra avvisi di deprecazione con Discourse. So molto poco sui dispositivi Apple a parte il fatto che sono molto più bloccati. È davvero così difficile installare altri browser moderni su di essi?
  8. Archiviazione immagini / caricamenti: I miei utenti e io amiamo la facilità di caricamento delle immagini in Discourse, ma sono un po’ preoccupato per lo spazio di archiviazione e i costi. L’opzione migliore a lungo termine sarebbe probabilmente quella di montare un volume di archiviazione di rete sul VPS, se necessario. Se inizialmente configurassi Discourse con la posizione di caricamento predefinita, causerebbe problemi spostarlo su un volume diverso in seguito?
  9. Backup:
    • Vorrei che ci fosse un sistema per backup differenziali, o meglio ancora, deduplicati. Attualmente uso Duplicity con Amazon S3 per il mio forum Drupal, e i costi sono incredibilmente bassi per una lunghissima cronologia di revisioni. Qualcuno sa a memoria quanto tempo dopo la creazione di un archivio S3 una regola può farlo passare a Glacier?
    • L’interfaccia di backup di Discourse consente di eliminare gli archivi in Amazon S3? So che è un po’ estremo, ma vorrei disabilitare quella funzionalità, perché ho configurato i miei bucket S3 con solo permessi PUT, GET e LIST per impedire a un hacker sul sistema compromesso di eliminare i miei backup remoti. Quindi una regola del ciclo di vita S3 entra in gioco ed elimina i vecchi archivi dal lato server dopo un certo periodo di tempo.
  10. Plugin Stop Forum Spam: Non voglio usare Akismet, ma ho sempre avuto buoni risultati con StopForumSpam.com per prevenire la creazione di molti account spammer. Qualcuno sa se il plugin per Discourse ha soglie configurabili per quanti hit un nome utente, IP o indirizzo email dovrebbe avere nel database per essere rifiutato? Modifica: No, non li ha. Richiesto qui. Inoltre, sfortunatamente, non interviene per impedire effettivamente la creazione di account se hanno abbastanza hit nel database SFS come fa in Drupal.

Scusa per il lungo post. Grazie in anticipo a tutti per i vostri spunti, e molti ringraziamenti all’intero progetto Discourse per questo eccellente prodotto.

2

Mi sono appena imbattuto in questo:

applica una serie di trasformazioni basate su regexp, come la sostituzione dei tag BBCode con Markdown

È stato aggiornato l’ultima volta nel 2016, non sono sicuro se sia ancora un’opzione pertinente.

È ancora rilevante? Nello script di importazione di Drupal vedo codice come:

 create_posts(results, total: total_count, offset: offset) do |row|
        topic_mapping = topic_lookup_from_imported_post_id("nid:#{row['nid']}")
 end

 def create_permalinks
    puts '', 'creazione permalink...'

    Topic.listable_topics.find_each do |topic|
      begin
        tcf = topic.custom_fields
        if tcf && tcf['import_id']
          node_id = tcf['import_id'][/nid:(\d+)/, 1]
          slug = "/topic/#{node_id}"
          Permalink.create(url: slug, topic_id: topic.id)
        end
1 Mi Piace
3

Lo script in genere estrae 1000 post alla volta.

Tiene traccia di ciò che è stato elaborato, quindi le esecuzioni successive possono saltare i dati già elaborati. Negli script che ho toccato includo anche un’impostazione import_after che accelera ulteriormente le esecuzioni successive caricando solo i dati recenti (utile anche per testare solo con un piccolo sottoinsieme dei dati).

Dovrei esaminare più attentamente per vedere se i post sono inclusi nei permalink. In genere non lo sono, ma è possibile farlo.

Vorrai tutti i tuoi caricamenti su S3, quindi il tuo backup includerà solo il dump del database. Non puoi fare molto per ottimizzare questo. Puoi lasciare che discourse mantenga un certo numero o dirgli di non farlo (o semplicemente impostare il numero di backup su un numero grande) e lasciare che le tue regole lo gestiscano.

1 Mi Piace
4

Oh, questo è un ottimo punto. Ora che ci penso, verrò comunque addebitato per lo spazio di archiviazione dei caricamenti su S3, sia che i caricamenti vadano direttamente (e solo) su S3, sia che siano all’interno di più tarball dal backup di Discourse.

E per quanto riguarda l’utilizzo di un bucket senza permessi di eliminazione per i backup di Discourse?

5

Ma se sono su S3 allora hai una sola copia.

Sospetto che funzionerà se discourse non ha il permesso di eliminare, anche se non lo so.

6

Giusto, e con gli incredibili livelli di ridondanza dei dati di S3, ciò sarebbe generalmente considerato un modo responsabile di archiviare gli upload? Non ho armeggiato di recente con le opzioni di S3, ma credo che abbiano anche regole del ciclo di vita per recuperare i file eliminati per un certo periodo di tempo? Sto pensando nel caso in cui gli upload vengano in qualche modo eliminati a causa di una chiamata errata da parte di Discourse, sia essa un (improbabile e massiccio) bug di codifica o un errore dell’utente. O un evento di hacking, tornando alla mia preoccupazione originale riguardo ai permessi di eliminazione sul bucket.

7

Sì, puoi attivare il versioning in modo che i file non vengano eliminati quando vengono contrassegnati come eliminati. Se non ti interessa quanto spazio stai pagando, puoi farlo. Quando Discourse elimina un file perché non è più utilizzato, lo sposta in una cartella “tombstone” per un po’ prima di eliminarlo definitivamente. Ti consiglio di fidarti di Discourse per la gestione dei file. Non so se impedire l’accesso in eliminazione possa causare problemi.

Puoi mettere i backup su un bucket separato con permessi diversi (ma stesse credenziali) se lo desideri.

1 Mi Piace
8

Domanda per @pfaffman o chiunque altro metta upload su S3 – So che dipende da un milione di fattori, ma avete almeno informazioni aneddotiche sui costi per la larghezza di banda e le richieste S3 per un forum medio-grande con i suoi upload su S3? Grazie mille!

1 Mi Piace
9

Piccolo aggiornamento qui: Quindi, quello che penso di fare è mantenere i miei caricamenti locali; dovrei avere abbastanza spazio di archiviazione locale per ora e la possibilità di espanderlo con volumi di archiviazione aggiuntivi se necessario. Semplicemente non voglio affrontare la complessità e la spesa di una CDN e i costi imprevedibili dello storage a oggetti e, soprattutto, i costi di trasferimento per il serving di immagini del sito web live. Poi farò backup automatici S3 su Backblaze B2, inclusi i caricamenti e l’opzione s3 disable cleanup. Il prezzo di Backblaze è così basso che non dovrebbe essere un problema conservare qualche settimana di backup giornalieri anche con i caricamenti ridondanti. Si scopre che Backblaze B2 ha due opzioni molto semplici per i bucket che sono proprio ciò di cui ho bisogno: 1) regole automatiche del ciclo di vita per eliminare i file dopo X giorni e 2) impedire l’eliminazione o la modifica dei file per N giorni (per prevenire la piccola possibilità che il server venga hackerato e l’hacker utilizzi le credenziali memorizzate per eliminare i miei backup remoti). Ho testato questo e sembra funzionare bene; ho provato a eliminare un archivio di backup dall’interfaccia grafica di Discourse che era proibito dall’eliminazione da parte di Backblaze, e semplicemente non ha fatto nulla.

Solo per chiarire per me e per gli altri: è possibile eseguire automaticamente il backup dei caricamenti sullo storage locale su S3 se l’opzione backup with uploads è abilitata (predefinita), giusto?

1 Mi Piace
10

Sì. Per impostazione predefinita, i caricamenti locali sono inclusi nel file di backup.

1 Mi Piace