Sie scheinen in Ordnung zu funktionieren, aber die Einstellung hat einen Punkt, der anzeigt, dass sie überschrieben wurden?
Irgendeine Idee, was hier los ist?
PS Ich habe versucht, nach „custom header links“ zu suchen, aber ich kann kein Thema finden, das dieses Problem erwähnt.
Ich glaube, du hast diese Einstellung geändert. Du hast also die Standardeinstellung überschrieben, was sehr wahrscheinlich ist, da dies der Zweck dieser Einstellung ist. Die Standardeinstellung ist eher ein Beispiel, da du die Theme-Komponente verwendest, um benutzerdefinierte Links hinzuzufügen. Mit der Reset-Schaltfläche könntest du die Einstellung auf die Standardeinstellung zurücksetzen.
Es war sehr seltsam. Als ich meine Seite zum ersten Mal ansah, hatte sie neue Links (extern, beliebt, Datenschutz), aber meine Links waren immer noch in den Feldern. Ich habe auf Zurücksetzen geklickt und meine benutzerdefinierte Linkkonfiguration verloren. Glücklicherweise habe ich den Text jedes einzelnen gespeichert und sie wieder hinzugefügt, wobei ich die neuen Links entfernt habe. Na ja. Software ist seltsam.
Ich war auch darüber verwundert.. Tatsächlich wurde der Name der Einstellungsvariable geändert, siehe DEV: Rename `Custom_header_links` settings to `custom_header_links` (… · discourse/discourse-custom-header-links@5006125 · GitHub
@tgxworld Es gibt einen Fehler im neuesten Update der Theme-Komponente. Sie benennt die Einstellung mithilfe einer Migration um, aber zu diesem Zeitpunkt wurde der ursprüngliche Einstellungsname bereits umbenannt in settings.yml. Die Migration funktioniert also nicht, da sie nicht mehr auf die alte Einstellung zugreifen kann. Diese Art von Migrationen sollte in zwei separaten Schritten erfolgen (und, angesichts der Funktionsweise von Theme-Komponenten-Migrationen, mit viel Zeit dazwischen).
Alle, die diese Theme-Komponente aktualisieren, verlieren also ihre Einstellungen.
FWIW Ich denke, wenn Sie die Einstellung erneut speichern, anstatt sie zurückzusetzen, wird alles gut.
Soweit ich weiß, funktioniert das nur, wenn die Theme-Komponente separat in der GUI aktualisiert wird, nicht wenn die TC als Teil eines größeren Updates (d. h. der Rake-Aufgabe) aktualisiert wird.
Ich glaube, es funktioniert, wenn Sie Ihre gesamte Website aktualisieren, beachten Sie, dass die Links jetzt die Standardeinstellungen sind, und dann die Theme-Einstellung custom header links erneut speichern.
Es ist jedoch leicht, das nicht zu tun und stattdessen auf Zurücksetzen zu klicken. 
Das hat für mich funktioniert. Es hat eine ganze Weile gedauert, bis ich herausfand, was los war, da die Einstellung korrekt aussah. Ich habe es behoben, indem ich die Theme-Komponente aus meinem Standard-Theme entfernt habe (da sie die Website aktiv verschlechterte) und festgestellt habe, dass sie jetzt mit dem anderen Theme funktionierte.
Ich bin froh, dass die Korrektur so einfach war, dass ich hineingefallen bin, aber es war ein Schock, die Links nach dem Aktualisieren von Discourse geändert zu finden. 
Wir ziehen die überschriebenen Theme-Einstellungen aus der Datenbank, die den Schlüssel der Einstellung speichert, sodass der Inhalt von settings.yml die Migrationen überhaupt nicht beeinflusst. Was ich hier vermute, ist, dass wir den Cache nicht leeren?
Das war nicht unsere Designabsicht. Da wir keine Kontrolle darüber haben, wie Themes aktualisiert werden, können wir keine 2-Schritt-Migration durchführen.
Dies war kürzlich eine Regression in unserem Migrationssystem, bei der der Cache für ein Thema nach der Ausführung von Themeneinstellungen nicht aktualisiert wird. Dies wurde behoben in
Das stimmt also nicht, denn die Einstellungen gehen tatsächlich nicht verloren, sondern der Cache verwendet nur den Standardwert der Einstellung anstelle der Überschreibungen in der Datenbank.
Vielen Dank für die Erklärung und Ihre schnellen Maßnahmen.
Habe gerade das gleiche Problem nach dem Update der Easy Footer-Komponente. Alle benutzerdefinierten Einstellungen sind im Frontend und im Backend-UI verschwunden.
Dies verursacht einige Verwirrung bei den Community Managern. Wenn sie dann im Backend auf “Zurücksetzen” klicken, dauert es einige Zeit, alle Einstellungen neu zu konfigurieren, beim Footer-Komponente sogar noch mehr als bei den Header-Links.
Es scheint, dass wir glaubten, dies sei auf ein Problem im Kern zurückzuführen, das behoben wurde, als der obige PR zusammengeführt wurde.\n\nWissen Sie, welche Version (Commit) von Discourse sie ausgeführt haben, als Sie die Theme-Komponente aktualisiert haben?
Ja, ich wollte gerade meinen Beitrag bearbeiten. Das ist sowohl im neuesten stabilen Branch, 3.2, passiert. Ich schätze, es sollte aber auch für die stabile Version behoben werden, sonst müssten alle Änderungen an den Komponenteneinstellungen auf eine höhere Version angeheftet werden?
Ah, ja. @tgxworld Denken wir darüber nach, welcher Ansatz hier am sinnvollsten ist, um stabile (Backporting des Kern-Fixes oder Auferlegung einiger Einschränkungen für die Kompatibilität in Komponenten, die Einstellungen-Migrationen verwenden).
Das wurde bereits vor 2 Tagen erledigt FIX: Update themes javascript cache after running themes migrations (… · discourse/discourse@39dffcb · GitHub
@manuel Was ist der Commit-Hash deiner Installation?
Oh ja, mein Fehler, habe diesen Server nicht aktualisiert! Tut mir leid Leute, es ist nur auf Staging, aber ein Kunde hat sich gemeldet, warum alles zurückgesetzt ist.
