Ich habe eine einige Monate alte Staging-Kopie einer WP-Website. Ich dachte, ich würde versuchen, wie die SSO mit dem Forum funktioniert (geschlossen für Anmeldungen, noch nicht gestartet) und dann später mit der Produktionsseite verbinden, die in der Zwischenzeit etwas mehr Benutzer hinzugefügt haben wird. Würde dies Discourse verwirren? Ich würde es mit einer Handvoll Benutzern aus dem Staging versuchen, wie die Dinge funktionieren, aber was passiert mit ihnen, wenn die Verbindung auf die andere Seite umgeschaltet wird? Ihre WP-Benutzer-ID und E-Mail bleiben jedoch gleich.
Wenn die WP-Benutzer-ID und die E-Mail-Adresse auf Ihrer Produktions- und Staging-Site gleich sind, können Sie zur Produktions-Site wechseln, ohne Änderungen auf Discourse-Seite vornehmen zu müssen.
Es wäre ratsam, noch einmal zu überprüfen, ob die Benutzer-IDs übereinstimmen. Ich erinnere mich, dass bei Staging- und Produktions-Sites von WP Engine keine Garantie dafür bestand, dass die Benutzer-IDs zwischen Produktion und Staging übereinstimmen – sie verwenden völlig getrennte Datenbanken. Stellen Sie sicher, dass dies bei Ihren Produktions- und Staging-Sites nicht der Fall ist.
Wenn Sie sich nicht sicher sind, ob die Benutzer-IDs zwischen Produktion und Staging übereinstimmen und der Parameter require_activation nicht auf true im SSO-Payload gesetzt ist, können Sie alle vorhandenen SingleSignOnRecord-Einträge aus der Discourse-Datenbank sicher löschen, bevor Sie zur Produktions-Site wechseln. Wenn sich bestehende Benutzer zum ersten Mal über WordPress bei Discourse anmelden, findet Discourse sie anhand ihrer E-Mail-Adresse und erstellt einen neuen SingleSignOnRecord für sie.
Vorhandene SingleSignOnRecord-Einträge können von der Rails-Konsole mit folgendem Befehl gelöscht werden:
SingleSignOnRecord.destroy_all
Wenn der Parameter require_activation im SSO-Payload auf true gesetzt ist, können Sie die SSO-Einträge auf Discourse-Seite trotzdem löschen. Bevor sich bestehende Benutzer von Ihrer Produktions-Site bei Discourse anmelden können, müssen Sie ihre E-Mail-Adressen in WordPress als verifiziert markieren. Details dazu, wie Sie dies von ihren WordPress-Profilseiten aus tun können, finden Sie hier: Validate Email Addresses with the WP Discourse plugin.
Wenn Sie eine Staging-WordPress-Site haben, empfehle ich Ihnen dringend, auch ein Staging-Discourse-Forum zu haben. Auf diese Weise müssen Sie sich keine Sorgen machen, was passieren könnte, wenn Sie Ihr Staging-WordPress mit einem Produktions-Discourse verbinden.
Dies ist ein gängiges Szenario – jemand erstellt eine Website auf einem WordPress-Hosting-Service (z. B. WP Engine), testet Dinge auf der standardmäßigen Staging-Site und wechselt dann zur Produktion. Ich habe dieselbe Frage mehrmals beantwortet, als ich den Discourse-Support durchführte. Eine permanente separate Staging-Site für Discourse war im Allgemeinen keine Option (oder wirklich notwendig).
Ja, Sie haben Recht, es ist ein relativ häufiges Szenario.
Nichtsdestotrotz, wenn Ihr WordPress in Produktion ist, wie es bei diesem Kerl der Fall zu sein scheint ( @Firsh korrigieren Sie mich, wenn ich falsch liege), dann denke ich, dass das potenzielle Risiko / die Kosten für die Vermischung von Staging- und Produktionsumgebungen die Zeit- und Kostenersparnis durch die einfache Einrichtung einer separaten Discourse-Instanz überwiegen. Dies gilt unter der Annahme, dass Ihr Staging eine Kopie Ihrer Produktion ist (was oft der Fall ist).
Sofern es keine organisatorischen Einschränkungen für die Einrichtung neuer Instanzen gibt (in diesem Fall sollten Sie wahrscheinlich ohnehin eine separate Staging-Umgebung haben), ist es relativ günstig und einfach, eine separate Discourse-Instanz auf DigitalOcean, Vultr usw. einzurichten und Probleme zu vermeiden, die aus der Kreuzkontamination von Staging <> Produktion entstehen könnten. Wahrscheinlich sparen Sie dabei Zeit (und Geld als Zeit). Sie können sie einfach ausschalten, wenn Sie fertig sind.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.