web-dev-qa-db-fra.com

django-debug-toolbar n'apparaît pas

J'ai regardé d'autres questions et je n'arrive pas à comprendre ... 

J'ai fait ce qui suit pour installer Django-debug-toolbar:

  1. pip installer Django-debug-toolbar
  2. ajouté aux classes 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 ajouté:

INTERNAL_IPS = ('174.121.34.187',)

4 Ajouté debug_toolbar aux applications installées

Je ne reçois aucune erreur ou quoi que ce soit, et la barre d'outils n'apparaît sur aucune page, pas même admin.

J'ai même ajouté le répertoire des modèles debug_toolbar à mon TEMPLATE_DIRS

pythondjangodjango-debug-toolbar
117
AlexBrand

Question stupide, mais vous ne l'avez pas mentionnée, alors ... Quel est le paramètre DEBUG? Il ne se chargera que si True.

Si cela ne fonctionne toujours pas, essayez également d'ajouter '127.0.0.1' à INTERNAL_IPS.

UPDATE

Il s’agit d’un mouvement ultime, vous ne devriez pas avoir pour le faire, mais cela montrera clairement s’il ya simplement un problème de configuration ou un problème plus important.

Ajoutez les éléments suivants à settings.py:

def show_toolbar(request):
    return True
SHOW_TOOLBAR_CALLBACK = show_toolbar

Cela supprimera effectivement toutes les vérifications effectuées par la barre d’outils de débogage afin de déterminer si elle devrait ou non se charger elle-même; il faudra toujours juste charger. Laissez-le uniquement à des fins de test. Si vous oubliez et lancez avec, tous vos visiteurs auront également la possibilité de voir votre barre d’outils de débogage.

Pour une configuration explicite, reportez-vous également à la documentation d'installation officielle ici .

EDIT (17/06/2015):

Apparemment, la syntaxe de l'option nucléaire a changé. C'est maintenant dans son propre dictionnaire:

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

Leurs tests utilisent ce dictionnaire.

162
Chris Pratt

La barre d’outils de débogage veut que l’adresse IP dans request.META ['REMOTE_ADDR'] soit définie dans le paramètre INTERNAL_IPS. Ajoutez une déclaration dans l'un de vos points de vue, par exemple:

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

Et puis chargez cette page. Assurez-vous que IP est dans votre paramètre INTERNAL_IPS dans settings.py. 

Normalement, je penserais que vous seriez capable de déterminer facilement l'adresse en regardant l'adresse IP de votre ordinateur, mais dans mon cas, j'exécute le serveur dans une boîte virtuelle avec une redirection de port ... et qui sait ce qui s'est passé. Bien que ifconfig ne l'ait jamais vu dans VB ou dans mon propre système d'exploitation, l'adresse IP apparaissant dans la clé REMOTE_ADDR était ce qui a rendu l'astuce d'activer la barre d'outils.

74
timothyashaw

Si tout le reste est correct, il se peut également que votre modèle ne possède pas de balise <body> de fermeture explicite—

Remarque: la barre d'outils de débogage ne s'affichera que si le type MIME de la réponse est text/html ou application/xhtml + xml et contient une balise de fermeture.

43
user1569050

La version stable actuelle 0.11.0 exige que les éléments suivants soient vrais pour que la barre d'outils soit affichée: 

Fichier de configuration:

  1. DEBUG = True
  2. INTERNAL_IPS pour inclure l'adresse IP de votre navigateur, par opposition à l'adresse du serveur. Si vous naviguez localement, cela devrait être INTERNAL_IPS = ('127.0.0.1',). Si vous naviguez à distance, simplement indiquez votre adresse publique } _. 
  3. L'application debug_toolbar à installer est i.e INSTALLED_APPS = (..., 'debug_toolbar',) 
  4. La classe de middleware de la barre d’outils de débogage à ajouter est, par exemple, MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Il devrait être placé le plus tôt possible dans la liste.

Fichiers de modèle:

  1. Doit être de type text/html
  2. Doit avoir une balise de fermeture </html>

Fichiers statiques:

Si vous servez du contenu statique, assurez-vous de collecter les fichiers css, js et html en procédant comme suit: 

./manage.py collectstatic

Note sur les prochaines versions de Django-debug-toolbar

Les versions de développement les plus récentes ont ajouté des valeurs par défaut pour les paramètres des points 2, 3 et 4, ce qui simplifie un peu la vie, cependant, comme dans toute version de développement, elle comporte des bogues. J'ai constaté que la dernière version de git entraînait une erreur ImproperlyConfigured lors de l'exécution de nginx/uwsgi. 

Quoi qu'il en soit, si vous voulez installer la dernière version de github, exécutez:

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

Vous pouvez également cloner un commit spécifique en faisant: 

pip install -e git+https://github.com/Django-debug-toolbar/Django-debug-toolbar.git@ba5af8f6fe7836eef0a0c85dd1e6d7418bc87f75#Egg=Django_debug_toolbar
24
donturner

J'ai tout essayé, du paramètre DEBUG = True aux paramètres INTERNAL_IPS de l'adresse IP de mon client, en passant par la configuration manuelle de Django Debug Toolbar (notez que les versions récentes effectuent automatiquement toutes les configurations, telles que l'ajout du middleware et des URL). Rien ne fonctionnait dans un serveur de développement distant (même s'il fonctionnait localement) . La SEULE chose qui a fonctionné a été la configuration de la barre d'outils comme suit:

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

Ceci remplace la méthode par défaut qui décide si la barre d'outils doit être affichée et renvoie toujours la valeur true.

17
Anoyz

J'ai la barre d'outils qui fonctionne parfaitement. Avec cette configuration:

  1. DEBUG = True
  2. INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
  3. DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
  4. Le middleware est le premier élément de 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',
)

J'espère que ça aide

14
César

Ajoutez 10.0.2.2 à votre INTERNAL_IPS sous Windows, il est utilisé avec vagrant en interne

INTERNAL_IPS = ( '10 .0.2.2 ', )

Cela devrait marcher.

12
Bas Koopmans

J'ai eu le même problème et finalement résolu après une recherche sur Google. 

Dans INTERNAL_IPS, vous devez avoir l'adresse IP du client.

6
Farhan Hafeez

Une autre chose qui peut rendre la barre d’outils cachée est si elle ne peut pas trouver les fichiers statiques requis. Les modèles debug_toolbar utilisent la balise de modèle {{STATIC_URL}}. Assurez-vous donc qu'il existe un dossier dans vos fichiers statiques appelé barre d'outils débogage.

Le commandement de gestion collectstatic devrait s’occuper de cela dans la plupart des installations.

4
AgDude

Docker

Si vous développez avec un serveur Django dans un répertoire Docker container avec menu fixe, les instructions permettant d'activer la barre d'outils ne fonctionnent pas. La raison est liée au fait que l'adresse réelle que vous devez ajouter à INTERNAL_IPS va être quelque chose de dynamique, comme 172.24.0.1. Plutôt que d'essayer de définir dynamiquement la valeur INTERNAL_IPS, la solution la plus simple consiste à remplacer la fonction qui active la barre d'outils, dans votre settings.py, par exemple:

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


Cela devrait également fonctionner pour d'autres situations de routage dynamiques, comme vagabond .

Voici quelques détails supplémentaires pour les curieux. Le code dans Django_debug_tool qui détermine s'il faut afficher la barre d'outils examine la valeur de REMOTE_ADDR comme ceci:

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

par conséquent, si vous ne connaissez pas la valeur de REMOTE_ADDR en raison de votre routage de menu fixe, la barre d'outils ne fonctionnera pas. Vous pouvez utiliser la commande docker network pour afficher les valeurs IP dynamiques, par exemple docker network inspect my_docker_network_name.

3
Mark Chackerian

J'ai essayé la configuration de cookiecutter-Django de pydanny et cela a fonctionné pour moi:

# 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

Je viens de le modifier en ajoutant 'debug_toolbar.apps.DebugToolbarConfig' au lieu de 'debug_toolbar' comme mentionné dans la documentation officielle de Django-debug-toolbar , car j'utilise Django 1.7.

3
metakermit

Un ajout aux réponses précédentes:

si la barre d'outils n'apparaît pas, mais qu'elle se charge dans le code HTML (vérifiez le code HTML de votre site dans un navigateur, faites défiler vers le bas)

le problème peut être que les fichiers statiques de la barre d’outils de débogage ne sont pas trouvés (vous pouvez également le voir dans les journaux d’accès de votre site, par exemple, 404 erreurs pour /static/debug_toolbar/js/toolbar.js)

Il peut ensuite être corrigé de la manière suivante (exemples pour nginx et Apache):

nginx config:

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

Apache config:

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

Ou:

manage.py collectstatic

plus sur collectstatic ici: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic

Ou déplacez manuellement le dossier debug_toolbar des fichiers statiques debug_toolbar dans votre dossier de fichiers statiques

2
Bob

Django 1.8.5:

J'ai dû ajouter ce qui suit au fichier url.py du projet pour obtenir l'affichage de la barre d'outils de débogage. Après que la barre d'outils de débogage est affichée.

 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: et supérieur:

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

N'oubliez pas non plus d'inclure la barre d'outils debug_tool à votre middleware ..__ La barre d'outils Debug est principalement implémentée dans un middleware. Activez-le dans votre module de configuration comme suit: (Versions plus récentes de Django)

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

Middleware de style ancien: (besoin d'avoir le travail clé _CLASSES dans le middleware)

MIDDLEWARE_CLASSES = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
# ...
]
2
Stryker

Dans mon cas, je devais simplement supprimer les fichiers compilés par Python (*.pyc)

1
dnaranjo

Ce n’était pas le cas pour cet auteur en particulier, mais j’ai eu du mal à ne pas afficher la barre d’outils de débogage et, après avoir fait tout ce qu’ils ont signalé, j’ai découvert que c’était un problème avec l’ordre de MIDDLEWARE. Donc, mettre le middleware au début de la liste pourrait fonctionner. Le mien est le premier:

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', )

1
Anderson Santos

Dans mon cas, c’était un autre problème qui n’a pas encore été mentionné: j’avais GZipMiddleware dans ma liste de middlewares.

Comme la configuration automatique de la barre d’outils de débogage place le middleware de la barre d’outils de débogage en haut, elle obtient uniquement le "voir" le code HTML compressé, auquel il ne peut pas ajouter la barre d’outils.

J'ai supprimé GZipMiddleware dans mes paramètres de développement. Configurer manuellement la configuration de la barre d'outils de débogage et placer le middleware après / GZip devrait également fonctionner.

1
RemcoGerlich

Pour moi, c'était aussi simple que de taper 127.0.0.1:8000 dans la barre d'adresse, plutôt que localhost:8000 qui ne correspond apparemment pas à INTERNAL_IPS.

0
TimStaley

J'ai eu ce problème et j'ai dû installer la barre d'outils de débogage à partir du source.

La version 1.4 a un problème où il est caché si vous utilisez PureCSS et apparemment d'autres frameworks CSS.

This est le commit qui corrige cela.

La documentation explique comment installer à partir du source.

0
Petko M

vous devez vous assurer qu'il y a une balise de fermeture dans vos modèles. 

Mon problème est qu'il n'y a pas de balises HTML normales dans mes modèles, je viens d'afficher le contenu en clair. Je l'ai résolu en héritant de chaque fichier HTML de base.html, qui contient une balise.

0
user1552891

J'ai le même problème, je l'ai résolu en consultant le journal des erreurs d'Apache . L'Apache s'exécutant sur mac os x avec mod_wsgi Le dossier tamplete de debug_toolbar n'était pas chargé

Exemple 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"

Je viens d'ajouter cette ligne à mon fichier VirtualHost:

Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar
  • Bien sûr, vous devez changer votre chemin python
0
Andre Manzano

Dans le code sur lequel je travaillais, plusieurs petites requêtes ont été effectuées lors du traitement de la requête principale (c'est un cas d'utilisation très spécifique). C'étaient des demandes traitées par le même fil de Django. La barre d'outils de débogage de Django (DjDT) n'attend pas ce comportement et inclut les barres d'outils de DjDT dans la première réponse, puis elle supprime son état pour le thread. Ainsi, lorsque la requête principale a été renvoyée au navigateur, DjDT n'a pas été inclus dans la réponse.

Leçons apprises: DjDT enregistre son état par thread. Il supprime l'état d'un thread après la première réponse.

0
jozo

Conditions préalables

Assurez-vous que 'Django.contrib.staticfiles' est correctement configuré et ajoutez debug_toolbar à votre paramètre INSTALLED_APPS:

INSTALLED_APPS = [
    # ...
    'Django.contrib.staticfiles',
    # ...
    'debug_toolbar',
]

STATIC_URL = '/static/'

URLconf

Ajoutez les URL de la barre d’outils de débogage à la URLconf de votre projet comme suit:

from Django.conf import settings
from Django.conf.urls import include, url  # For Django versions before 2.0
from Django.urls import include, path  # For Django versions from 2.0 and up

if settings.DEBUG:
    import debug_toolbar
    urlpatterns = [
        path('__debug__/', include(debug_toolbar.urls)),

        # For Django versions before 2.0:
        # url(r'^__debug__/', include(debug_toolbar.urls)),

    ] + urlpatterns

Middleware

La barre d'outils de débogage est principalement implémentée dans un middleware. Activez-le dans votre module de paramètres comme suit:

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

Middleware ancien:

MIDDLEWARE_CLASSES = [
    # ...
    'debug_toolbar.middleware.DebugToolbarMiddleware',
    # ...
]

IP internes

La barre d'outils de débogage est affichée uniquement si votre IP est répertoriée dans le paramètre INTERNAL_IPS. (Vous pouvez modifier cette logique avec l'option SHOW_TOOLBAR_CALLBACK.) Pour le développement local, vous devez ajouter «127.0.0.1» à INTERNAL_IPS.

Alors ça va marcher. Et aussi vérifier lien https://Django-debug-toolbar.readthedocs.io/en/latest/installation.html

0
copy channel

J'ai eu le même problème en utilisant Vagrant. J'ai résolu ce problème en ajoutant ::ffff:192.168.33.1 à l'exemple INTERNAL_IPS, comme ci-dessous. 

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

Rappelant que 192.168.33.10 est l’adresse IP de mon réseau privé dans Vagrantfile.

0
Adriano Silva

Ce qui m'a valu un navigateur obsolète!

Remarqué que cela charge certaines feuilles de style à partir de la barre d’outils de débogage et supposé que cela pourrait être un problème frontal.

0
ogurets

Pour toutes les personnes utilisant Pycharm 5, le débogage des modèles ne fonctionne pas dans certaines versions. Corrigé dans la version 5.0.4, versions affectées - 5.0.1, 5.0.2 Consulter issue

Passez beaucoup de temps à le découvrir. Peut-être aidera quelqu'un

0
wolendranh