Hallo. Wenn ich versuche, in/über „Empfohlen“ zu installieren, wo das Bit aufgeführt ist, erhalte ich: „500 Fehler“
Wenn ich zur Vorschau gehe, sehe ich dies in der Mitte der Seite:
Irgendwelche Vorschläge, warum das so ist?
Ich vermute, dass meine Verbindung zum Dienst tatsächlich verweigert wird, aber… warum.
Es scheint, dass dies nicht der richtige Link ist. Wenn Sie den aus dem OP verwenden, sollte er einwandfrei funktionieren - GitHub - discourse/discourse-custom-header-links
Wenn Sie mir sagen können, wo Sie versucht haben, diesen Link zu installieren, werde ich prüfen, ob wir ihn aktualisieren können.
Wenn ich es mit git versuche – GitHub - discourse/discourse-custom-header-links
bekomme ich denselben “500 Fehler”
Hmm. 
Es scheint für mich einwandfrei zu funktionieren (sowohl aus dem Bereich „Beliebt“ als auch durch Einfügen des Links https://github.com/discourse/discourse-custom-header-links).
Könnten Sie als Alternative auf die Schaltfläche „Diese Theme-Komponente installieren“ im OP klicken?
Das kann ich nicht tun, da ich davon ausgehe, dass meine Website, die ein Testlabor ist, öffentlich zugänglich sein müsste, richtig?
Das mag die alten Links erklären. Ist es auf dem neuesten Stand?
Ich denke, eine andere Alternative wäre, die ZIP herunterzuladen und sie auf diese Weise hochzuladen:
Alles scheint in Ordnung zu sein, sidekiq funktioniert, keine offensichtlichen Fehler oder Warnungen.
Einige andere Dinge - z. B. Kategoriebanner - wurden über popular okey installiert.
Version 3.0.5 / 461966e028
Ich werde zip ausprobieren
FWIW, die neueste stable-Version ist 3.1 (und tests-passed mindestens 3.2.0.beta1-dev), daher denke ich, dass Sie ein Upgrade durchführen müssen. 
Ich bin mir nicht sicher, ob das funktioniert hat – vielleicht hat die Zerstörung und Neuerstellung des Containers funktioniert – aber jetzt mit dem Update auf Version 3.0.6 kann Discourse CHL über popular installieren.
Ich bekomme diesen Fehler jetzt für alle/jedes Thema und jede Komponente.
Funktionieren diese? Ich frage, weil ich, wenn ich auf „Vorschau“ gehe, zu Folgendem weitergeleitet werde: Theme Creator mit einem Popup und einer Schaltfläche „Thema anzeigen“, die mich zu „https://discourse.theme-creator.io/c/discourse/1“ führt.
Wie haben Sie Discourse installiert? Ist dies eine Standardinstallation? Haben Sie auf die aktuelle Version 3.1 aktualisiert?
Ja. Übrigens – sollte die „Standard“-Installation die Entwicklerversion (bei mir wird 3.2.0.beta1-dev angezeigt) enthalten?
In einigen Protokollen sehe ich:
…
Processing by Admin::ThemesController#import as */*
Parameters: {"remote"=>"https://github.com/discourse/discourse-category-banners"}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 2ms (Views: 0.4ms | ActiveRecord: 0.0ms | Allocations: 1273)
Failed to process hijacked response correctly : Timeout::Error : Timeout::Error
Könnte die Tatsache, dass ich einen Nginx-Proxy extern zum Host/Knoten habe, eine Rolle spielen? (Alles scheint normal zu funktionieren)
Vom Container aus kann ich diese URIs mit curl abrufen — von view einer Komponente, die mit 500 fehlschlägt — nur ein ok.
Gibt es eine Möglichkeit, für diese Teile eine detailliertere Fehlersuche zu erhalten?
Über zip installierte Komponenten scheinen okey zu funktionieren.
Ja, der Standardzweig ist „Tests bestanden“ (siehe auch Understanding Discourse release channels).
Das Suffix „dev“ wurde kürzlich hinzugefügt.
From Discourse 3.2: adding -dev suffix to beta versions under active development
Vielleicht ein Performance-Problem. Genug RAM? Andere Prozesse, die die gesamte CPU auslasten?
Ich würde das nicht denken, 4 Kerne, 8 GB RAM und es ist nur ein frisch installiertes Labor – in dem Moment, in dem Discourse auf diese Weise ausfällt, kann ich curl innerhalb des Containers, dieselbe URI, problemlos aufrufen.
Was hier hilfreich wäre, ist, wenn ich wüsste, wie ich die Protokolle ausführlicher/debuggter erhalten/erstellen kann – wenn devel hier liest, kann er vielleicht Ratschläge dazu geben.
tail -f /var/discourse/shared/standalone/log/rails/production.log
oder innerhalb des Containers
/shared/log/rails/production.log
Wenn ich das noch einmal durchgehe, vermute ich, dass Sie ein Docker-Konfigurationsproblem haben und nicht auf GitHub zugreifen können. Aber ich bin mir nicht sicher, wie das sein könnte, wenn Sie eine Standardinstallation vorgenommen haben, da die Plugins aus dem Container geklont worden wären.
Dies sind die Protokolle, die ich bereits zuvor eingefügt habe – ich hoffe immer noch, dass diese ausführlicher und aussagekräftiger gestaltet werden können.
Ich sagte auch in meinem letzten Kommentar, dass ich diese sehr URI der Komponente, die die GitHub-URI ist, problemlos innerhalb des Containers curlen kann – denkst du wirklich, dass deine Aussage, Docker-Konfiguration, das Problem sein könnte?
Es muss eine Reihe von Faktoren gewesen sein — Container neu aufbauen, DNS des Hosts, … — es funktioniert jetzt, keine 500-Fehler.