Ho eseguito un ripristino e tutti i collegamenti interni hanno il dominio dell’URL di test, il che interrompe tutti i collegamenti e non sono sicuro del motivo per cui non ha assunto l’URL del sito corretto. Senza entrare nel codice/db per fare una sostituzione di massa, ci sono soluzioni per farlo in un altro modo?
Stavo pensando di fare un ripristino?
Dovrai accedere al database ed eseguire una ricerca/sostituzione di massa.
Esiste uno strumento per questo:
RAILS_ENV=production discourse remap //old.domain //new.domain
Puoi correggerlo come descritto, ma non dovrebbe succedere.
Hai eseguito e ripristinato il backup utilizzando /admin/backups?
Entrambi i sistemi hanno l’hostname impostato correttamente?
Grazie. Sembrava abbastanza facile. Ho inserito l’app e l’ho eseguita, ma sembra che non abbia modificato le istanze degli URL nei post.
Questo è stato il remap:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Questo è stato eseguito e completato sul DB “default”, ha richiesto alcuni minuti e poi ha riportato “fatto” senza errori.
Ho controllato alcuni post scelti e nulla sembrava essere cambiato negli URL dei post.
Ho ricostruito alcuni per testare dove ho visto dev.domain.com invece del domain.com live nei link, ma sono rimasti gli stessi.
Quindi ho eseguito lo stesso ma senza https:// e ho ottenuto questo errore:
Remapping tables on default...
Error: ERROR: duplicate key value violates unique constraint "index_post_hotlinked_media_on_post_id_and_url_md5"
DETAIL: Key (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) already exists.
The remap has only been partially applied due to the error above. Please re-run the script again.
Suppongo che ci sia un messaggio di chat nel DB che ne causa l’arresto, ma non sono sicuro del perché. Immagino di doverlo vedere in qualche modo nel DB, come puoi capire, la mia solita incursione nella gestione di discourse non avviene mai nel DB.
Infine, ho rieseguito il remap originale, ha richiesto alcuni minuti e ha riportato “fatto” senza errori:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Forse devo rifare il bake dei post per vederne i frutti?
Pensavo che una ricostruzione del post fosse la stessa azione ma su base post per post.
O ricostruire l’app?
Dovrebbe essere
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Il motivo di // è che corrisponde a http://, https:// e URL senza protocollo, e non corrisponde a domini di indirizzi e-mail.
Cosa succede quando lo fai?
Sì ok, poi lo stesso errore di nuovo:
Rimappatura delle tabelle predefinite...
Errore: ERRORE: la violazione del vincolo di unicità della chiave duplicata "index_post_hotlinked_media_on_post_id_and_url_md5"
DETTAGLIO: La chiave (post_id, md5(url::text))=(1001176, 547048fcd29cdac60) esiste già.
La rimappatura è stata applicata solo parzialmente a causa dell'errore sopra. Si prega di rieseguire nuovamente lo script.
Quindi almeno sto usando il comando di scrittura corretto, le cose stanno migliorando! 
Nessun’altra idea?
A parte questo stallo nel re-mapping di Rails, pensavo che forse se avessi eseguito il backup del db ed eseguito nuovamente il ripristino, avrebbe potuto re-mappare correttamente gli URL dei link durante il processo di ripristino?
L’errore che sto ancora riscontrando sembra essere ripetuto o molto simile all’errore di arresto che necessitava di una correzione qui:
Errore: ERRORE: violazione del valore di chiave duplicato del vincolo univoco "index_post_hotlinked_media_on_post_id_and_url_md5"
DETTAGLIO: Chiave (post_id, md5(url::text))=...
Quando si tenta la rimappatura:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Forse @david potrebbe avere un’intuizione qui?
Questo sembra più un bug?
Quella tabella ha collegamenti con entrambi quei domini, quindi quando tenti di rimapparli ottieni una chiave duplicata. Non è un bug. Stai tentando di creare una chiave duplicata.
Puoi rimuovere gli elementi da quella tabella che hanno il dominio di livello superiore. Un’idea migliore è usare www invece del dominio di livello superiore.
Grazie. La mia unica preoccupazione è che anche questo deployment di Discourse soffra del problema non-www / SSL, ad esempio How to add ssl to non-www domain?, ma proverò il remapping che suggerisci e se funzionerà mi costringerà a risolvere anche il problema non-www!
Il remapping ha funzionato come suggerito da @pfaffman, ma è stato in realtà il catalizzatore della soluzione, non la soluzione di per sé, mi ha aiutato a capire cosa stavo sbagliando, mi ha rimappato gli occhi!
Se avessi letto l’errore correttamente, cioè prestando attenzione, l’avrei risolto molto tempo fa poiché avrei visto che le informazioni chiave erano nel messaggio di errore.
Tutto ciò che dovevo fare era includere il numero del post segnalato dall’errore di stop …/p/123456789 nell’URL per navigare direttamente e correggere manualmente ogni post.
Questo è accaduto per la maggior parte in una seconda esecuzione di remapping per convertire il www dal primo remapping all’URL apex non-www come era l’esigenza originale.
Ora gli URL interni dovrebbero includere solo link apex.
Questo risolve parte del reindirizzamento SSL www dove c’erano molti link interni www legacy. Non risolve un utente che digita www nella barra degli indirizzi o un link di ritorno sul WWW stesso per ora, ma dovrebbe affrontare tutti quelli generati internamente. Attendo di vedere come influenzerà l’indicizzazione di Google prima di fare altro su questo problema.
Forse di interesse. Per gli sviluppatori.
Ho trovato molti stop su duplicate key value violates unique constraint “unique_post_links”, questi si sono verificati quando un post è stato spostato e discourse ha incluso il “Continuato da …. “ con hotlink, ma se i post divisi includevano blocchi citati nello stesso punto, allora avrebbe fermato il remapping.
Questo ha causato la maggior parte degli errori di stop.
La soluzione è stata rimuovere uno dei link interni duplicati o racchiuderli tra parentesi (non sempre ha funzionato) e il remapping sarebbe proseguito una volta rieseguito.
Altri stop sono stati causati da utenti che creavano manualmente le stesse condizioni sul post ripubblicando lo stesso link a un post senza rendersi conto che anche la citazione rimandava indietro, forse abitudini storiche, stili, ecc. entrano in gioco qui indicando che molti utenti ancora non si rendono conto di quanto discourse gestisca i link per semplificare la vita, oh l’ironia!
Dopo il remapping avrei potuto annullare le modifiche, ma non erano così tante da fare la differenza e c’era ancora un link corretto al sorgente discourse interno del post o alla citazione.
Spero che questo inverta la maggior parte della de-indicizzazione di Google di decine di migliaia di pagine in un limbo grigio non indicizzato.
Un po’ di conoscenza è una cosa pericolosa! 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.