Posso cambiare il sito utilizzato come provider (da staging a prod)?

Ho una copia di staging di un sito WP di qualche mese. Pensavo di provare come funziona l’SSO con il forum (chiuso alle iscrizioni, non ancora lanciato) e poi collegarlo in seguito con il sito di produzione, che nel frattempo avrà più utenti. Ciò confonderebbe Discourse? Proverei con una manciata di utenti dallo staging per vedere come funzionano le cose, ma cosa succede loro quando la connessione viene cambiata per utilizzare l’altro sito? Il loro ID utente e la loro email WP rimangono gli stessi, però.

1 Mi Piace

Se l’ID utente WP e l’email sono gli stessi sui tuoi siti di produzione e staging, puoi passare all’utilizzo del sito di produzione senza dover apportare modifiche dal lato Discourse.

Sarebbe una buona idea ricontrollare per assicurarsi che gli ID utente siano gli stessi. Mi sembra di ricordare che con i siti di staging e produzione di WP Engine non vi fosse alcuna garanzia che gli ID utente corrispondessero tra produzione e staging, poiché utilizzano database completamente separati. Assicurati che non sia questo il caso per i tuoi siti di produzione e staging.

Se non sei sicuro che gli ID utente corrispondano tra produzione e staging, e il parametro require_activation non è impostato su true nel payload SSO, puoi eliminare in sicurezza tutte le voci SingleSignOnRecord esistenti dal database Discourse prima di passare al sito di produzione. La prima volta che gli utenti esistenti accedono a Discourse tramite WordPress, Discourse li troverà in base al loro indirizzo email e genererà un nuovo SingleSignOnRecord per loro.

Le voci SingleSignOnRecord esistenti possono essere eliminate dalla console Rails con:

SingleSignOnRecord.destroy_all

Se il parametro require_activation è impostato su true nel payload SSO, puoi comunque eliminare i record SSO dal lato Discourse. Prima che gli utenti esistenti possano accedere a Discourse dal tuo sito di produzione, dovrai contrassegnare i loro indirizzi email come verificati su WordPress. I dettagli su come farlo dalle loro pagine del profilo WordPress sono qui: Validate Email Addresses with the WP Discourse plugin.

Se hai un sito WordPress di staging, ti consiglio vivamente di avere anche un forum Discourse di staging. In questo modo non dovrai preoccuparti di cosa potrebbe succedere se collegassi il tuo WordPress di staging a un Discourse di produzione.

Questo è uno scenario comune: qualcuno crea un sito su un servizio di hosting WordPress (ad esempio WP Engine), testa le cose sul sito di staging predefinito, quindi passa alla produzione. Ho risposto alla stessa domanda più volte quando facevo supporto per Discourse. Un sito di staging separato e permanente per Discourse generalmente non era un’opzione (o non era realmente necessario).

1 Mi Piace

Sì, hai ragione, è uno scenario relativamente comune.

Tuttavia, se il tuo Wordpress è in produzione, come sembra essere il caso di questo tizio (@Firsh, correggimi se sbaglio), allora penso che il rischio potenziale / costo di mescolare ambienti di staging e produzione superi qualsiasi tempo e costo risparmiato semplicemente creando un’istanza Discourse separata. Questo presuppone che il tuo staging sia una copia della tua produzione (cosa che spesso accade).

A meno che non ci siano restrizioni organizzative sulla creazione di nuove istanze (nel qual caso dovresti probabilmente avere comunque un ambiente di staging separato), è relativamente economico e facile creare un’istanza Discourse separata su DigitalOcean, Vultr, ecc., ed evitare qualsiasi problema che potrebbe derivare dall’impollinazione incrociata Staging <> Produzione. Probabilmente risparmierai tempo (e denaro-come-tempo) facendolo. Puoi semplicemente spegnerla quando hai finito.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.