Es ist also bestätigt, dass das Problem darin bestand, dass ich vor einigen Jahren, als ich S3 zum ersten Mal einzurichten versuchte, enable_s3_uploads in der Datenbank gesetzt habe, was dazu führt, dass die Wiederherstellung nicht funktioniert, da versucht wird, nach S3 hochzuladen, aber nicht genügend Informationen vorhanden sind. (Seufz. Aber die Wiederherstellung der Multisite/S3-Instanz schlägt fehl, da einige Dateien „nicht nach S3 migriert wurden“.)
Ich frage mich, ob es sinnvoll wäre, die S3-Upload-Einstellungen komplett auszublenden. Ich bin ziemlich sicher, dass nichts Gutes dabei herauskommen kann, sie im UX zu setzen. Aber es kann praktisch sein, S3-Uploads in der Datenbank einzustellen. . . . vielleicht.
Die auf die Standardinstallation wiederhergestellte Installation zeigt keine Uploads an, da sie Folgendes tut:
Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)
Der Pfad, nach dem gesucht wird, ist /var/www/discourse/public/default/original/1X/ anstelle von /var/www/discourse/public/uploads/default/original/1X/
… . .
Und das liegt daran, dass ich eine Neuzuordnung vorgenommen habe, um die S3-Bucket-Referenzen zu korrigieren, was die Pfade in den lokalen URLs kaputt gemacht hat.
Ich denke, das ist vielleicht zu sehr im Detail, um für irgendjemanden nützlich zu sein. Obwohl ich immer noch denke, dass es eine gute Idee ist, die S3-Upload-Variablen aus dem UX auszublenden.