O django-debug-toolbar não aparece

132

Eu olhei para outras perguntas e não consigo descobrir ...

Fiz o seguinte para instalar o django-debug-toolbar:

  1. pip instala django-debug-toolbar
  2. adicionado às classes de middleware:
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    # Uncomment the next line for simple clickjacking protection:
    # 'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)

3 INTERNAL_IPS adicionados:

INTERNAL_IPS = ('174.121.34.187',)

4 Adicionado debug_toolbar aos aplicativos instalados

Não estou recebendo nenhum erro ou qualquer coisa, e a barra de ferramentas não aparece em nenhuma página, nem mesmo em administrador.

Eu até adicionei o diretório dos modelos debug_toolbar ao meu TEMPLATE_DIRS

python  django  django-debug-toolbar 
— AlexBrand
fonte
9
Se você estiver usando o Vagrant, verifique se INTERNAL_IPSestá correto. Uma maneira de verificar é em uma visualização, imprima request.META['REMOTE_ADDR']e adicione-a INTERNAL_IPS.
— Will
1
Isso pode ajudar alguém. Eu estava tentando adicionar '*'os IPs internos, mas isso não funciona. Você precisa inserir IPs específicos.
— Luv33preet 17/0518
Na minha settings.py, agora é MIDDLEWARE apenas, não MIDDLEWARE_CLASSES
— Bertie

Respostas:

174

Pergunta estúpida, mas você não mencionou, então ... O que está DEBUGdefinido? Não será carregado a menos que seja True.

Se ainda não estiver funcionando, tente adicionar '127.0.0.1' INTERNAL_IPStambém.

ATUALIZAR

Este é um movimento de última hora esforço, você não deve ter de fazer isso, mas ele vai mostrar claramente se há apenas algum problema de configuração ou se há algum problema maior.

Adicione o seguinte ao settings.py:

def show_toolbar(request):
    return True
SHOW_TOOLBAR_CALLBACK = show_toolbar

Isso removerá efetivamente todas as verificações pela barra de ferramentas de depuração para determinar se ela deve ou não ser carregada; sempre será apenas carregado. Apenas deixe isso para fins de teste; se você esquecer e iniciar com ele, todos os seus visitantes também verão sua barra de ferramentas de depuração.

Para configuração explícita, consulte também os documentos oficiais de instalação aqui .

EDIT (17/6/2015):

Aparentemente, a sintaxe da opção nuclear mudou. Agora está em seu próprio dicionário:

def show_toolbar(request):
    return True
DEBUG_TOOLBAR_CONFIG = {
    "SHOW_TOOLBAR_CALLBACK" : show_toolbar,
}

Seus testes usam este dicionário.

— Chris Pratt
fonte
3
Sim, há um problema maior acontecendo aqui. Se você estiver usando algo diferente de runserverreiniciar. Caramba, reinicie runservertambém. Verifique se suas alterações no settings.py foram realmente salvas / confirmadas. Você pode tentar remover os arquivos * .pyc. No * nix, você pode fazer isso simplesmente a find . -name "*.pyc" -exec rm {} \;partir da raiz do projeto. Por fim, execute python manage.py shelle execute from django.conf import settingse verifique o valor de settings.INSTALLED_APPs.
— Chris Pratt
3
Não sei ao certo o que você quer dizer com a última pergunta, mas se você está se referindo INTERNAL_IPS, essas são para o cliente, não para o servidor (Django). Em outras palavras, você colocar no seu endereço de IP de modo que você pode ver de depuração barra de ferramentas, não importa o IP do site pode ser executado.
— Chris Pratt
10
INTERNAL_IPS me pegou também .. Obrigado pela informação
— Lee
12
ou mesmoSHOW_TOOLBAR_CALLBACK = lambda x: True
— John Mee
6
@ Schillingt sim, desculpas eu deveria ter verificado isso. Eu acho que tive que correr collectstaticpara fazer tudo parecer.
— Rob Grant
80

A barra de ferramentas de depuração deseja que o endereço IP em request.META ['REMOTE_ADDR'] seja definido na configuração INTERNAL_IPS. Coloque uma declaração impressa em uma de suas visualizações como:

print("IP Address for debug-toolbar: " + request.META['REMOTE_ADDR'])

E, em seguida, carregue essa página. Verifique se o IP está na sua configuração INTERNAL_IPS em settings.py.

Normalmente, eu acho que você seria capaz de determinar o endereço facilmente olhando o endereço IP do seu computador, mas no meu caso, eu estou executando o servidor em uma Caixa Virtual com encaminhamento de porta ... e quem sabe o que aconteceu. Apesar de não o ver em nenhum lugar no ifconfig no VB ou no meu próprio sistema operacional, o IP que apareceu na chave REMOTE_ADDR foi o que fez o truque de ativar a barra de ferramentas.

— timothyashaw
fonte
2
Eu estava chegando à minha página via nginx proxy pass, então o remote_addr era meu proxy e não meu ip real. Eu precisava adicionar meu endereço IP de proxy INTERNAL_IPSe ele começou a funcionar.
— Kurt
1
Na minha máquina convidada no VirtualBox, minha máquina host é vista como 10.0.0.2, se puder ajudar alguém. :)
— mrmuggles
MUITO útil para verificar IP se você usar um pouco de virtualização como VAGRANT
— andilabs
3
Na janela de encaixe, meu REMOTE_ADDR não era o que eu teria assumido.
— Aaron McMillin
28

A versão estável atual 0.11.0 requer o seguinte para que a barra de ferramentas seja mostrada:

Arquivo de configurações:

  1. DEBUG = True
  2. INTERNAL_IPSpara incluir o endereço IP do navegador, em oposição ao endereço do servidor. Se estiver navegando localmente, deve ser INTERNAL_IPS = ('127.0.0.1',). Se estiver navegando remotamente, apenas especifique seu endereço público .
  3. O aplicativo debug_toolbar a ser instalado, ou seja, INSTALLED_APPS = (..., 'debug_toolbar',)
  4. A classe de middleware da barra de ferramentas de depuração a ser adicionada, ie MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Deve ser colocado o mais cedo possível na lista.

Arquivos de modelo:

  1. Deve ser do tipo text/html
  2. Deve ter uma </html>tag de fechamento

Arquivos estáticos:

Se você estiver exibindo conteúdo estático, certifique-se de coletar css, js e html fazendo: 

./manage.py collectstatic

Nota sobre as próximas versões do django-debug-toolbar

As versões mais recentes de desenvolvimento adicionaram padrões para os pontos de configuração 2, 3 e 4, o que torna a vida um pouco mais simples, no entanto, como em qualquer versão de desenvolvimento, ela possui bugs. Eu descobri que a versão mais recente do git resultou em um ImproperlyConfigurederro ao executar o nginx / uwsgi.

De qualquer forma, se você deseja instalar a versão mais recente do github, execute:

pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git#egg=django-debug-toolbar

Você também pode clonar um commit específico fazendo: 

pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git@ba5af8f6fe7836eef0a0c85dd1e6d7418bc87f75#egg=django_debug_toolbar
— não voltar
fonte
2
realmente tag seu <body> </ body> que é necessário não </ html>
— Zgr3doo
20

Eu tentei de tudo, desde a configuração DEBUG = True, até INTERNAL_IPSo endereço IP do meu cliente e até a configuração manual da barra de ferramentas de depuração do Django (observe que versões recentes fazem todas as configurações automaticamente, como adicionar o middleware e URLs). Nada funcionou em um servidor de desenvolvimento remoto (embora funcionasse localmente). A única coisa que funcionou foi configurar a barra de ferramentas da seguinte maneira:

DEBUG_TOOLBAR_CONFIG = {
    "SHOW_TOOLBAR_CALLBACK" : lambda request: True,
}

Isso substitui o método padrão que decide se a barra de ferramentas deve ser mostrada e sempre retorna true.

— Anoyz
fonte
16

Docker

Se você estiver desenvolvendo com um servidor Django em um contêiner do Docker com janela de encaixe, as instruções para ativar a barra de ferramentas não funcionarão. O motivo está relacionado ao fato de que o endereço real ao qual você precisaria adicionar INTERNAL_IPSserá algo dinâmico, como 172.24.0.1. Em vez de tentar definir dinamicamente o valor de INTERNAL_IPS, a solução direta é substituir a função que habilita a barra de ferramentas, no seu settings.py, por exemplo:

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': lambda _request: DEBUG
}


Isso também deve funcionar para outras situações de roteamento dinâmico, como vagrant.

Aqui estão mais alguns detalhes para os curiosos. O código em django_debug_tool que determina se deve mostrar a barra de ferramentas examina o valor da REMOTE_ADDRseguinte maneira:

if request.META.get('REMOTE_ADDR', None) not in INTERNAL_IPS:
       return False

portanto, se você realmente não souber o valor REMOTE_ADDRdevido ao roteamento do docker dinâmico, a barra de ferramentas não funcionará. Você pode usar o comando docker network para ver os valores IP dinâmicos, por exemplodocker network inspect my_docker_network_name

— Mark Chackerian
fonte
15

Eu tenho a barra de ferramentas funcionando perfeitamente. Com estas configurações:

  1. DEBUG = True
  2. INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
  3. DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
  4. O middleware é o primeiro elemento em MIDDLEWARE_CLASSES:
MIDDLEWARE_CLASSES = (
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
)

Espero que ajude

— César
fonte
2
Você provavelmente deve redigir seu endereço IP da sua resposta. Como a maioria das pessoas está executando banda larga atualmente e a maioria das conexões de banda larga raramente altera o endereço IP, se é que existe. Você provavelmente não quer isso por aí nas interwebs.
— Chris Pratt
192.168. *. * É um endereço IP local interno atribuído ao computador pelo roteador. O endereço IP externo é diferente.
— Robeezy
@ rpod é exatamente por isso que alguém editou para isso.
— Yuji 'Tomita' Tomita
Se você estiver usando o Um arquivo Verdadeiro Config, e só querem Debug Toolbar no dev, em vez de adicioná-lo ao MIDDLEWARE_CLASSES em base.pyque você pode querer adicionar isso ao seu local.py: MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES.
— Rob Grant
12

Adicione 10.0.2.2ao seu INTERNAL_IPS no Windows, ele é usado com o vagrant internamente

INTERNAL_IPS = ('10 .0.2.2 ')

Isso deve funcionar.

— Bas Koopmans
fonte
1
Confirmei que isso corrigiu meu problema usando o Vagrant no OSX.
— Josh
Esta é a solução mais correta e mais provável e o mais simples :) Confirmado trabalhar usando errante no Windows 7
— mislavcimpersak
6

Eu tive o mesmo problema e finalmente o resolvi depois de pesquisar no Google.

Em INTERNAL_IPS, você precisa ter o endereço IP do cliente .

— Farhan Hafeez
fonte
4

Outra coisa que pode fazer com que a barra de ferramentas permaneça oculta é se ela não conseguir encontrar os arquivos estáticos necessários. Os modelos debug_toolbar usam a tag de modelo {{STATIC_URL}}, portanto, verifique se há uma pasta em seus arquivos estáticos chamada barra de ferramentas de depuração.

O comando de gerenciamento coletivo estático deve cuidar disso na maioria das instalações.

— AgDude
fonte
3

Eu tentei a configuração do cookiecutter-django do pydanny e funcionou para mim:

# django-debug-toolbar
MIDDLEWARE_CLASSES = Common.MIDDLEWARE_CLASSES + ('debug_toolbar.middleware.DebugToolbarMiddleware',)
INSTALLED_APPS += ('debug_toolbar',)

INTERNAL_IPS = ('127.0.0.1',)

DEBUG_TOOLBAR_CONFIG = {
    'DISABLE_PANELS': [
        'debug_toolbar.panels.redirects.RedirectsPanel',
    ],
    'SHOW_TEMPLATE_CONTEXT': True,
}
# end django-debug-toolbar

Acabei de modificá-lo adicionando, em 'debug_toolbar.apps.DebugToolbarConfig'vez do 'debug_toolbar'mencionado nos documentos oficiais do django-debug-toolbar , como estou usando o Django 1.7.

— metakermit
fonte
2

Um acréscimo às respostas anteriores:

se a barra de ferramentas não aparecer, mas carregar no html (verifique o html do site em um navegador, role para baixo)

o problema pode ser que os arquivos estáticos da barra de ferramentas de depuração não foram encontrados (você também pode ver isso nos logs de acesso do seu site, por exemplo, erros 404 para /static/debug_toolbar/js/toolbar.js)

Pode ser corrigido da seguinte maneira (exemplos para nginx e apache):

configuração nginx:

location ~* ^/static/debug_toolbar/.+.(ico|css|js)$ {
    root [path to your python site-packages here]/site-packages/debug_toolbar;
}

configuração do apache:

Alias /static/debug_toolbar [path to your python site-packages here]/site-packages/debug_toolbar/static/debug_toolbar

Ou:

manage.py collectstatic

mais sobre collectstatic aqui: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic

Ou mova manualmente a pasta debug_toolbar dos arquivos estáticos debug_toolbar para a pasta de arquivos estáticos definida

— Prumo
fonte
2

No meu caso, foi outro problema que ainda não foi mencionado aqui: eu tinha o GZipMiddleware na minha lista de middlewares.

Como a configuração automática da barra de ferramentas de depuração coloca o middleware da barra de ferramentas de debug no topo, ele apenas "vê" o HTML compactado com gzip, ao qual não pode adicionar a barra de ferramentas.

Eu removi o GZipMiddleware nas minhas configurações de desenvolvimento. Definir a configuração da barra de ferramentas de depuração manualmente e colocar o middleware após o GZip também deve funcionar.

— RemcoGerlich
fonte
Mesmo ativar o GZip no nível da visualização gzip_pagefaz com que a barra de ferramentas desapareça. docs.djangoproject.com/en/2.0/topics/http/decorators/…
— Brachamul
2

No meu caso, eu só precisava remover os arquivos compilados python ( *.pyc)

— dnaranjo
fonte
Obrigado por este comentário, me salvou de um colapso mental esta manhã. Se tudo estiver correto - e esse projeto estiver funcionando antes -, tente e veja se o problema está resolvido. O DDT HTML / JS estava na página, tudo parecia bem, mas ainda não aparecia. Eu limpei os arquivos pyc e ele começou a aparecer novamente
— Shane
2

django 1.8.5:

Eu tive que adicionar o seguinte ao arquivo url.py do projeto para obter a exibição da barra de ferramentas de depuração. Depois que a barra de ferramentas de depuração é exibida.

 from django.conf.urls import include
 from django.conf.urls import patterns
 from django.conf import settings


  if settings.DEBUG:
      import debug_toolbar
      urlpatterns += patterns('',
              url(r'^__debug__/', include(debug_toolbar.urls)),
              )

django 1.10: e superior:

from django.conf.urls import include, url
from django.conf.urls import patterns
from django.conf import settings


if settings.DEBUG:

  import debug_toolbar
  urlpatterns =[
         url(r'^__debug__/', include(debug_toolbar.urls)),
         ] + urlpatterns

Além disso, não esqueça de incluir o debug_toolbar no seu middleware. A barra de ferramentas Debug é implementada principalmente em um middleware. Habilite-o no seu módulo de configurações da seguinte maneira: (versões mais recentes do django)

MIDDLEWARE = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
#

Middleware à moda antiga: (é necessário ter o teclado _CLASSES no Middleware)

MIDDLEWARE_CLASSES = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
# ...
]
— Stryker
fonte
1

Este não foi o caso deste autor específico, mas eu apenas tenho lutado com a barra de ferramentas Debug que não aparece e depois de fazer tudo o que eles apontaram, descobri que havia um problema com a ordem do MIDDLEWARE. Portanto, colocar o middleware no início da lista poderia funcionar. A minha é a primeira:

MIDDLEWARE_CLASSES = ( 'debug_toolbar.middleware.DebugToolbarMiddleware', 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'dynpages.middleware.DynpageFallbackMiddleware', 'utils.middleware.UserThread', )

— Anderson Santos
fonte
0

você precisa garantir que exista uma tag de fechamento nos seus modelos.

Meu problema é que não há tags html regulares nos meus modelos, apenas exibo o conteúdo em texto sem formatação. Eu o resolvi herdando todos os arquivos html de base.html, que possui uma tag.

— user1552891
fonte
0

Para mim, isso foi tão simples quanto digitar 127.0.0.1:8000na barra de endereços, e não localhost:8000aparentemente não corresponder ao INTERNAL_IPS.

— TimStaley
fonte
0

Eu tenho o mesmo problema, resolvi-o olhando o log de erros do Apache. Eu peguei o apache rodando no mac os x com mod_wsgi A pasta tamplete do debug_toolbar não estava sendo carregada

Amostra de log:

==> /private/var/log/apache2/dummy-host2.example.com-error_log <==
[Sun Apr 27 23:23:48 2014] [error] [client 127.0.0.1] File does not exist: /Library/WebServer/Documents/rblreport/rbl/static/debug_toolbar, referer: http://127.0.0.1/

==> /private/var/log/apache2/dummy-host2.example.com-access_log <==
127.0.0.1 - - [27/Apr/2014:23:23:48 -0300] "GET /static/debug_toolbar/css/toolbar.css HTTP/1.1" 404 234 "http://127.0.0.1/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0"

Acabei de adicionar esta linha ao meu arquivo VirtualHost:

Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar
  • Claro que você deve alterar seu caminho python
— Andre Manzano
fonte
0

Eu tive o mesmo problema usando o Vagrant. Resolvi esse problema adicionando ::ffff:192.168.33.1ao INTERNAL_IPS como exemplo abaixo.

INTERNAL_IPS = (
    '::ffff:192.168.33.1',
)

Lembrando que 192.168.33.10é o IP da minha rede privada no Vagrantfile.

— Adriano Silva
fonte
0

Eu tive esse problema e tive que instalar a barra de ferramentas de depuração da fonte.

A versão 1.4 tem um problema em que está oculto se você usar o PureCSS e aparentemente outras estruturas CSS.

Este é o commit que corrige isso.

Os documentos explicam como instalar a partir do código-fonte.

— Petko M
fonte
0

Para quem estiver usando a depuração do modelo Pycharm 5, não está funcionando em algumas versões. Corrigido no 5.0.4, versões afetadas - 5.0.1, 5.0.2 Verificar problema

Passe muito tempo para descobrir isso. Talvez ajude alguém

— wolendranh
fonte
0

No código em que eu estava trabalhando, várias pequenas solicitações foram feitas durante o tratamento da solicitação principal (é um caso de uso muito específico). Eles foram pedidos tratados pelo mesmo thread do Django. A barra de ferramentas de depuração do Django (DjDT) não espera esse comportamento e inclui as barras de ferramentas do DjDT na primeira resposta e, em seguida, remove seu estado para o encadeamento. Portanto, quando a solicitação principal foi enviada de volta ao navegador, o DjDT não foi incluído na resposta.

Lições aprendidas: O DjDT salva seu estado por thread. Remove o estado de um encadeamento após a primeira resposta.

— jozo
fonte
0

O que me pegou é um navegador desatualizado!

Percebeu que ele carrega algumas folhas de estilo da barra de ferramentas de depuração e imaginou que poderia ser um problema de front-end.

— ogurets
fonte
0

Eu sei que essa pergunta é um pouco antiga, mas hoje eu instalei o django-toolbar com o docker e me deparei com o mesmo problema, isso resolveu para mim

INTERNAL_IPS = ["127.0.0.1", "10.0.2.2"]

import socket
hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
INTERNAL_IPS += [".".join(ip.split(".")[:-1] + ["1"]) for ip in ips]

Como li em um comentário, o problema é que o docker usa um ip dinâmico. Para resolver isso, podemos obter o ip do código acima

— Esequiel Albornoz
fonte
-1

Uma coisa estúpida me entendeu: se você usar o apache wsgi, lembre-se de tocar no arquivo .wsgi para forçar a recompilação do código. desperdice 20 minutos do meu tempo para depurar o erro estúpido :(

— igameland
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.