Ich habe die Assets überprüft und sie waren noch da. Ich betreibe eine Nicht-Produktionsinstanz, um Dinge zu testen. Dort war es dasselbe. Auf dieser Seite habe ich das UI-Update durchgeführt, aber es wurde schlimmer, es erschienen mehr fehlende Assets.
Hier ist eine seltsame Wendung: Wir sind vor fast einem Jahr von Discourse-Hosting zu Self-Hosting gewechselt. Bei der Überprüfung von Konsolenfehlern meldet das fehlende Bild eine 403 zurück an einen Discourse-Server.
Die Theme-Dateien zeigen die erwartete Self-Hosting-URL, nicht die 403
In diesem Screenshot ist die 403 eine Discourse-Datei, die darüber/darunter liegenden sind auf dem erwarteten Self-Hosting-Server
Ich beantworte gerne Fragen, falls dies mehr als ein Einzelfall ist, und würde mich auch freuen, wenn mir jemand die notwendigen Konsolenbefehle zum korrekten Neuaufbau posten könnte.
Ich bin mir z.B. nicht sicher, ob ich eine Neuordnung vom alten Discourse-Server zum neuen Self-Hosting-Server durchführen möchte, wenn das bereits geschehen ist und bisher korrekt war, wie ich dachte.
Jemand anderes hatte kürzlich ein ähnliches Problem, und ich glaube, das lag daran, dass die S3-Assets beim Wechsel von Discourse-Hosting zu Self-Hosting nicht einbezogen/neu zugeordnet wurden?
Ich bin mir nicht sicher, ob das hilfreich ist, aber ich dachte, ich werfe es mal ein.
Der andere Nicht-Produktionsstandort hat ebenfalls keine Avatare mehr, ein neues Problem ebenfalls.
Ein kurzer Blick auf den Systemavatar zeigt, dass er zu einer Discourse-URL zurückgekehrt ist.
Wie kommt es zu dieser scheinbar zufälligen Änderung
Das ist der Nicht-Produktionsserver, der öffentliche zeigt die Dateien korrekt an, obwohl er nicht funktioniert. Es gibt keine Pläne, eine Sicherung darauf zu versuchen
Als Sie discourse.org-Hosting verlassen haben, haben Sie versäumt, ein Backup anzufordern, das Ihre Uploads enthielt. Daher haben Sie diese seit Ihrem Weggang aus deren S3-Bucket verwendet.
Wenn Sie Glück haben, können Sie den Support per E-Mail kontaktieren und darum bitten, dass sie diese wiederherstellen. Wenn sie dies tun können, müssen Sie diese Assets auf Ihren lokalen Speicher herunterladen, bevor sie sie endgültig löschen.
Vielen Dank für Ihre Antwort, ich weiß sie sehr zu schätzen, besonders angesichts Ihres Fachwissens.
Als wir dies taten, wie ich jetzt zurückblicke, musste Discourse nur eine “Box ankreuzen, damit Uploads in Ihre Sicherungsdatei aufgenommen werden”, und dann haben wir sie heruntergeladen, und ich habe die anschließende SSH durchgeführt, um sie neu zuzuordnen.
Die Vorstellung, dass wir Discourse-Server verwendeten, ergibt mit meinem begrenzten Wissen darüber, wie das alles funktioniert, keinen Sinn. Können Sie das bitte weiter erläutern?
Sie speichern Uploads in einem S3-Bucket. Das Kontrollkästchen „Uploads einschließen“ schließt nur lokale Uploads ein, nicht die auf S3.
Es gibt eine versteckte Website-Einstellung include_s3_uploads_in_backups. Wenn Sie Ihren Dienst kündigen, wird diese standardmäßig aktiviert. Wenn Sie sie bitten, diese Einstellung zu aktivieren, werden sie dies tun. Aber wenn Sie einfach ein Backup erhalten, bevor Sie Ihren Dienst kündigen, werden die Uploads in S3 nicht berücksichtigt, nur die auf lokaler Speicherung (und davon gibt es keine).
Aber vielleicht irre ich mich und Sie haben nur ein paar Themes, bei denen Discourse-Assets fest einprogrammiert sind. Das ist sicherlich bei dem Theme in Ihren Bildern der Fall.
Das Theme hat derzeit die korrekte lokale URL, wie hier und in der Konsole zu sehen ist, doch der Fehler unten liest von Discourse. Wie kann ich das korrigieren? Ich verstehe es nicht einmal
