Nach einem Restore haben alle internen Links die Test-URL-Domain, was alle Links bricht. Ich bin mir nicht sicher, warum die korrekte Site-URL nicht übernommen wurde. Gibt es Lösungen, wie man das anders machen kann, ohne in den Code/die Datenbank zu gehen, um eine Massensuche und -ersetzung durchzuführen?
Ich habe überlegt, eine Wiederherstellung durchzuführen?
Sie müssen in die Datenbank gehen und eine Massensuche/-ersetzung durchführen.
Dafür gibt es ein Werkzeug:
RAILS_ENV=production discourse remap //alt.domain //neu.domain
Sie können es wie beschrieben beheben, aber das sollte nicht passieren.
Haben Sie das Backup mit /admin/backups erstellt und wiederhergestellt?
Haben beide Systeme den Hostnamen korrekt eingestellt?
Danke. Das sah einfach genug aus. Ich habe die App aufgerufen und das ausgeführt, aber es scheint die Instanzen der URLs in den Beiträgen nicht geändert zu haben.
Dies war die Neuzuordnung:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Dies wurde ausgeführt und in der „Standard“-DB abgeschlossen. Es dauerte ein paar Minuten und meldete dann „erledigt“ ohne Fehler.
Ich habe mir einige ausgewählte Beiträge angesehen und nichts schien sich an den URLs der Beiträge geändert zu haben.
Ich habe einige neu erstellt, um zu testen, wo ich dev.domain.com anstelle des Live-domain.com in den Links gesehen habe, aber sie blieben gleich.
Dann habe ich dasselbe ausgeführt, aber ohne das https:// und erhielt diesen Fehler:
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.
Ich vermute, dass es eine Chat-Nachricht in der DB gibt, die dazu führt, dass sie stoppt, bin mir aber nicht sicher, warum. Ich nehme an, ich muss das irgendwie in der DB sehen, denn wie Sie wissen, ist mein üblicher Ausflug in die Verwaltung von Discourse nie in der DB.
Schließlich habe ich die ursprüngliche Neuzuordnung erneut ausgeführt. Es dauerte ein paar Minuten und meldete „erledigt“ ohne Fehler:
RAILS_ENV=production discourse remap //https://sub.domain.com //https://domain.com
Vielleicht muss ich Beiträge neu backen, um die Früchte zu sehen?
Ich dachte, ein Beitrags-Neubau sei die gleiche Aktion, aber auf Beitragsbasis.
Oder die App neu bauen?
Das sollte sein
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Der Grund für // ist, dass es http://, https:// und protokolllose URLs übereinstimmt und keine E-Mail-Adressdomänen übereinstimmt.
Was passiert, wenn Sie das tun?
Ja, okay, dann derselbe Fehler wieder:
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.
Also benutze ich zumindest den richtigen Schreibbefehl, die Dinge sehen besser aus! 
Keine weiteren Ideen?
Abgesehen von dieser Rails-Remapping-Blockade dachte ich, vielleicht, wenn ich die Datenbank sichere und erneut wiederherstelle, könnte sie die Link-URLs während des Wiederherstellungsprozesses korrekt neu zuordnen?
Der Fehler, auf den ich immer noch stoße, scheint der gleiche oder ein sehr ähnlicher zu sein wie der Stoppfehler hier, der eine Korrektur benötigte:
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))=…
Beim Versuch des Remappings:
RAILS_ENV=production discourse remap //sub.domain.com //domain.com
Vielleicht hat @david hier eine Einsicht?
Sieht das eher wie ein Fehler aus?
Diese Tabelle hat Links mit beiden dieser Domains, also erhältst du beim Versuch, sie neu zuzuordnen, einen doppelten Schlüssel. Es ist kein Fehler. Du versuchst, einen doppelten Schlüssel zu erstellen.
Du könntest die Einträge in dieser Tabelle entfernen, die die Apex-Domain haben. Eine bessere Idee ist es, www anstelle der Apex-Domain zu verwenden.
Danke. Meine einzige Sorge ist, dass dieses Discourse-Deployment ebenfalls das Nicht-www / SSL-Problem hat, z. B. How to add ssl to non-www domain?, aber ich werde die von Ihnen vorgeschlagene Neuzuordnung versuchen und wenn sie funktioniert, wird sie mich zwingen, auch das Nicht-www-Problem zu lösen!
Die Neuzuordnung hat wie von @pfaffman vorgeschlagen funktioniert, war aber tatsächlich der Katalysator für die Lösung, nicht die Lösung an sich. Sie hat mir geholfen herauszufinden, was ich falsch gemacht habe, sie hat meine Augen neu zugeordnet!
Wenn ich den Fehler richtig gelesen hätte, d.h. aufgepasst. Hätte ich das schon viel früher gelöst, da ich gesehen hätte, dass die Schlüsselinformationen in der Fehlermeldung enthalten waren.
Alles, was ich tun musste, war, die vom Stoppfehler angezeigte Beitragsnummer …/p/123456789 in die URL aufzunehmen, um direkt zu navigieren und jeden Beitrag manuell zu korrigieren.
Dies geschah bei der Mehrheit in einem zweiten Neuzuordnungsdurchlauf, um die www aus der ersten Neuzuordnung in die Apex-Nicht-www-URL umzuwandeln, wie es ursprünglich erforderlich war.
Jetzt sollten interne URLs nur noch Apex-Links enthalten.
Dies löst einige der www-SSL-Umleitungen, bei denen es viele ältere interne www-Links gab. Es löst nicht, wenn ein Benutzer www in die Adressleiste eingibt oder von der WWW selbst zurücklinkt, aber es sollte alle intern generierten Links angehen. Ich warte ab, wie sich dies auf die Google-Indexierung auswirkt, bevor ich weitere Schritte in dieser Angelegenheit unternehme.
Vielleicht von Interesse. Für Entwickler.
Ich habe viele Stopps bei duplicate key value violates unique constraint “unique_post_links” gefunden. Diese traten auf, wenn ein Beitrag verschoben wurde und Discourse den „Fortsetzung von …. “ mit Hotlink einschloss, aber wenn die geteilten Beiträge Zitate zum selben Punkt enthielten, würde dies die Neuzuordnung stoppen.
Dies verursachte die Mehrheit der Stoppfehler.
Die Lösung war, einen der doppelten internen Linkbacks zu entfernen oder sie in Klammern zu setzen (funktionierte nicht immer), und die Neuzuordnung würde nach einem erneuten Durchlauf fortgesetzt.
Andere Stopps wurden verursacht, indem Benutzer manuell die gleichen Bedingungen für einen Beitrag erstellten, indem sie denselben Link zu einem Beitrag erneut posteten, ohne zu erkennen, dass das Zitat auch zurücklinkte, vielleicht historische Gewohnheiten, Stile usw. spielen hier eine Rolle und zeigen an, dass viele Benutzer immer noch nicht erkennen, wie viel Discourse mit Links handhabt, um das Leben einfacher zu machen, oh die Ironie!
Nach der Neuzuordnung hätte ich die Bearbeitungen rückgängig machen können, aber es waren nicht so viele, dass es einen Unterschied gemacht hätte, und es gab immer noch einen korrekten Link zurück zur internen Discourse-Quelle des Beitrags oder Zitats.
Hoffentlich kehrt dies die Mehrheit der Google-Deindexierung von Zehntausenden von Seiten in unindizierten grauen Schwebezustand um.
Ein wenig Wissen ist eine gefährliche Sache! 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.