Hi. When I try to install, in/via “Recommended” where the bit is listed, I get: “500 error”
When I go to preview I get this in the centre of the page:
Any suggestion on why that is?
I am guessing that my connection to the service is in fact denied but… why.
It looks like that’s not the correct link. If you use the one from the OP it should work fine - GitHub - discourse/discourse-custom-header-links
If you can tell me where were you trying to install that link from I’ll have a check to see if we can update that.
Hmm. 
It seems to be working fine for me (both from the ‘Popular’ section and pasting the https://github.com/discourse/discourse-custom-header-links link).
Could you try the ‘install this theme component’ button in the OP as an alternative?
I cannot do that as I understand my site, which is a test-lab, would have to be publicly accessible, right?
That may explain the old links. Is it up-to-date?
I think another alternative could be to download the zip and upload it that way:
Everything seems to be working a ok, sidekiq is, no obvious errors nor warnings.
Some other bits - e.g category banners - installed via popular okey.
ver. 3.0.5 / 461966e028
I’ll try zip
FWIW, the latest stable version is 3.1 (and tests-passed at least 3.2.0.beta1-dev) so I think you do need to upgrade. 
Not sure if that did it - perhaps destruction & creation of the container did - but now with updated to 3.0.6 version, Discourse can install CHL via popular.
I keep getting that error for all/any theme &| component now.
Do these work - I’m asking for when I go to “Preview” I get redirected to: Theme Creator with a pup-up and a button “View Theme” which if I go for I end up at ‘discourse - Theme Creator’
How did you install discourse? Is this a standard install? Did you upgrade to the current 3.1 version?
Yes. btw - should “standard” install end up having dev release (mine shows 3.2.0.beta1-dev) ?
In some logs I see:
…
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
Would the fact that I have Nginx proxy external to the host/node play a role in it? (everything seems to work normal)
From within container I can curl those URIs — of view of some component which fail with 500 — just a ok.
Is there a way to get more verbose debug for those bits?
Components installed via zip seem to work okey.
Yes, the default branch is “tests passed” (see also Why does Discourse always install "beta" versions by default?).
The “dev” suffix was added recently.
From Discourse 3.2: adding -dev suffix to beta versions under active development
Maybe a performance issue. Enough ram? Other stuff taking all the cpu?
I’d not think so, 4 core 8GB of RAM and it’s only freshly installed lab - the very moment Discourse fails that way I can curl, within the container, that same URI just fine.
What I think would be helpful here is if I knew how to get/make logs more verbose/debugged - if devel reads here perhaps can advice on that.
tail -f /var/discourse/shared/standalone/log/rails/production.log
or inside the container
/shared/log/rails/production.log
Looking back over this, my guess is that you have a docker config problem and it cannot access github. But I’m not sure how that could be true if you did a standard install, as it would have cloned plugins from inside the container.
These are the logs I pasted already, earlier - I still hope those could be made more verbose & telling.
I also said, in my last comment, that I can curl those very URI of the component which is Github URI, just fine, within the container - you think what you said, docker config, might be the issue really?
Must have been a number of factors — rebuilding container, host’s DNS, … — it works now, no 500 errors.