Can't see wagtail user bar

[Taehwan Kim]

Hello!

I have some question to ask.

First I can't see wagtail user bar when I am using with browser sync(I am not sure, I tried to track down why but.. can't :( )

I think the opacity of iframe of wagtail-userbar must set to 1, but some reason it doesn't.

Second, When I use django-debug-toolbar, it appears in the wagtail-userbar section also, how can I remove that?

Please Help.

Thanks!

[Brett Grace]

For the duplicate debug toolbar, see: https://github.com/torchbox/wagtail/issues/244

If you're talking about browser sync, the node-based testing assistant, I would check to see whether all of the browsers are actually getting authenticated properly. E.g., do you have appropriate credentials to open /admin? Just guessing, this issue still seems to be open: https://github.com/BrowserSync/browser-sync/issues/124

[Taehwan Kim]

Thanks for your help! Brett

Wagtail userbar button is there, just it is invisible. And I am sure that I am authenticated.

I can click it and it takes me to the wagtail admin site normally

When I turn off browser sync(http://www.browsersync.io/), I can see wagtail userbar. :(

And about debug tool bar I tried like this in django 1.8.4

def custom_show_toolbar(request):

    return not request.get_full_path().startswith('/userbar/')

DEBUG_TOOLBAR_CONFIG = {

    'SHOW_TOOLBAR_CALLBACK': 'gentlecoffee.settings.dev.custom_show_toolbar',

}

It does nothing. :(

What am I missing?

[Brett Grace]

For the toolbar issue, I'm definitely using that approach in my own code and it works fine. It might be a version issue with the toolbar, or the settings aren't getting picked up in your environment. Try adding some tracing statements to make sure your custom configuration is being found and loaded.

On the user bar thing, yeah, I have seen that too, I have no idea. It happened once I turned https on. Might be a Wagtail version issue, since it doesn't happen on 1.0 sites but still happens on my 0.8 site.

[Robin Eriksen]

Did you ever find a solution to this problem?

I am experiencing the exact same problem. Through the Firefox debugger I can see that the css/js static content is 0 bytes, even though the amazon S3 bucket states that the files have data. I have also tried to redo collectstatic to no avail.

[Benedikt Breinbauer]

@Brett: I think only step 1 is necessary, at least for us, step 2 loads assets via % static % which is a relative url anyways?

On Tuesday, 26 January 2016 23:14:03 UTC+1, Brett Grace wrote:

Are you talking about the Wagtail userbar not appearing? I happened to finally get curious enough about this literally just a few days ago. It was happening for me on sites after I switched them over to using SSL. The JavaScript that injects the userbar wasn't using the correct protocol scheme to load the stylesheet, and the browser was refusing to load insecure resources (http) when the connection was made over https (reporting 0 bytes is typical in this scenario if I recall correctly). If you don't have SSL involved, then this may not apply, although I suppose this might happen across different origins, too, if you have Content Source Restrictions in place. I haven't gotten around to filing a bug or submitting a pull request for this, but in short you need to:

1) make sure that request.is_secure returns True. This is doesn't work as expected if you are using nginx or something else for SSL termination, you need to pass a header through and tell Django to look for it when getting the value of request.is_secure. (Google should turn up results on how to do this). You can tell if this is an issue if you visit your page on https and bring up the JavaScript console. If the value of wagtail.userbar.origin is "http://example.com" and you are visiting "https://example.com", then you are getting the wrong value for request.is_secure

2) modify or override wagtailadmin/templates/wagtailadmin/userbar/frame.html -- with the change above, it should be the case that wagtail.userbar.origin is set correctly, but it doesn't seem to be used in line 12. If I replace line 12 with:

u.src = wagtail.userbar.origin + '/{% static "wagtailadmin/js/userbar_embed.js" %}';

... then the userbar appears as expected. Anyway, I think that was the intention for that line of code. There might be a way to do this with a protocol relative URL, which would be simpler, but the browser didn't seem to like it, and I only spent a few minutes on it.

[Brett Grace]

Yeah, you're right. I kind of alluded to being surprised that it didn't work with a relative URL, so I must have been looking at a cached result since I was debugging in anger.

[Brett Grace]

I'm posting a corrected (simplified) version, and deleting the original reply, since Benedikt Breinbauer noted I had an extraneous step:

----

Are you talking about the Wagtail userbar not appearing? I happened to finally get curious enough about this literally just a few days ago. It was happening for me on sites after I switched them over to using SSL. The JavaScript that injects the userbar wasn't using the correct protocol scheme to load the stylesheet, and the browser was refusing to load insecure resources (http) when the connection was made over https (reporting 0 bytes is typical in this scenario if I recall correctly). If you don't have SSL involved, then this may not apply, although I suppose this might happen across different origins, too, if you have Content Source Restrictions in place. I haven't gotten around to filing a bug or submitting a pull request for this, but in short you need to:

1) make sure that request.is_secure returns True. This is doesn't work as expected if you are using nginx or something else for SSL termination, you need to pass a header through and tell Django to look for it when getting the value of request.is_secure. (Google should turn up results on how to do this). You can tell if this is an issue if you visit your page on https and bring up the JavaScript console. If the value of wagtail.userbar.origin is "http://example.com" and you are visiting "https://example.com", then you are getting the wrong value for request.is_secure

2) there is no step 2 but make sure you restart your server to pick up changes if you have template caching on.

On Tuesday, January 26, 2016 at 12:55:04 PM UTC-8, Robin Eriksen wrote:

[Robin Eriksen]

Thanks to all the helpful questions and answers, they really helped me find the solution, which was to add this to my settings:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

On Friday, September 11, 2015 at 4:30:36 PM UTC+2, Taehwan Kim wrote: