132

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

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

pip installer django-debug-toolbar
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 Ajout de INTERNAL_IPS:

INTERNAL_IPS = ('174.121.34.187',)

4 Ajout de la barre d'outils debug_toolbar aux applications installées

Je n'obtiens aucune erreur ou quoi que ce soit, et la barre d'outils n'apparaît sur aucune page, pas même l'administrateur.

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

python django django-debug-toolbar

— AlexBrand
source

9

Si vous utilisez Vagrant, assurez-vous que votre INTERNAL_IPSest correct. Une façon de vérifier est dans une vue, imprimez votre request.META['REMOTE_ADDR'], puis ajoutez-le à votre INTERNAL_IPS.

— Sera

1

Cela pourrait aider quelqu'un. J'essayais en ajoutant '*'les adresses IP internes, mais cela ne fonctionne pas. Vous devez entrer des adresses IP spécifiques.

— Luv33preet

Dans mes paramètres.py, il s'agit désormais uniquement de MIDDLEWARE, pas de MIDDLEWARE_CLASSES

— bertie

174

Question stupide, mais vous ne l'avez pas mentionnée, alors ... Qu'est-ce qui est DEBUGréglé? Il ne se chargera que si c'est True.

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

METTRE À JOUR

C'est un mouvement de dernière minute, vous ne devriez pas avoir à le faire, mais cela montrera clairement s'il y a simplement un problème de configuration ou s'il y a un problème plus important.

Ajoutez ce qui suit à settings.py:

def show_toolbar(request):
    return True
SHOW_TOOLBAR_CALLBACK = show_toolbar

Cela supprimera efficacement toutes les vérifications de la barre d'outils de débogage pour déterminer s'il doit ou non se charger; il se chargera toujours simplement. Ne laissez cela qu'à des fins de test, si vous oubliez et lancez avec, tous vos visiteurs pourront également voir votre barre d'outils de débogage.

Pour une configuration explicite, consultez également la documentation d'installation officielle ici .

MODIFIER (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.

— Chris Pratt
source

3

Ouais, il y a donc un problème plus important ici. Si vous utilisez autre chose que runserverassurez-vous de le redémarrer. Heck, redémarrez runserveraussi. Assurez-vous que vos modifications apportées à settings.py ont bien été enregistrées / validées. Vous voudrez peut-être essayer de supprimer les fichiers * .pyc. Dans * nix, vous pouvez le faire simplement avec find . -name "*.pyc" -exec rm {} \;depuis la racine du projet. Enfin, exécutez python manage.py shellet exécutez from django.conf import settingset vérifiez la valeur de settings.INSTALLED_APPs.

— Chris Pratt

3

Je ne suis pas sûr de ce que vous entendez par la dernière question, mais si vous faites référence à INTERNAL_IPS, ce sont pour le client et non le serveur (Django). En d' autres termes, vous mettez dans votre adresse IP afin que vous , peu importe ce que le site IP pouvez voir débogage barre d' outils, peut être exécuté.

— Chris Pratt

10

INTERNAL_IPS m'a eu aussi .. Merci pour l'info

— Lee

12

ou mêmeSHOW_TOOLBAR_CALLBACK = lambda x: True

— John Mee

6

@schillingt oui, excuses j'aurais dû vérifier ça. Je pense que j'ai dû courir collectstaticpour tout faire apparaître.

— Rob Grant

80

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 imprimée dans l'une de vos vues comme celle-ci:

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

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

Normalement, je pense que vous seriez capable de déterminer l'adresse facilement en regardant l'adresse IP de votre ordinateur, mais dans mon cas, j'exécute le serveur dans une boîte virtuelle avec redirection de port ... et qui sait ce qui s'est passé. Bien que je ne le vois nulle part dans ifconfig sur le VB ou mon propre système d'exploitation, l'adresse IP qui apparaît dans la clé REMOTE_ADDR est ce qui a fait le tour de l'activation de la barre d'outils.

— timothyashaw
source

2

J'arrivais à ma page via le proxy nginx, donc remote_addr était mon proxy et non ma vraie adresse IP. J'avais besoin d'ajouter mon adresse IP proxy INTERNAL_IPSet cela a commencé à fonctionner.

— Kurt

1

Depuis ma machine invitée dans VirtualBox, ma machine hôte est considérée comme 10.0.0.2, si elle peut aider quelqu'un. :)

— mrmuggles

TRES utile pour CHECK IP si vous utilisez une virtualisation comme VAGRANT

— andilabs

3

Dans docker, mon REMOTE_ADDR n'était pas ce que j'aurais supposé.

— Aaron McMillin

50

Si tout le reste va bien, il se peut également que votre modèle ne comporte pas de <body>balise de fermeture explicite .

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

— user1569050
source

Dans mon cas, l'ajout à settings.py a DEBUG_TOOLBAR_CONFIG = {'INSERT_BEFORE':'</head>'}fonctionné

— wojteck

28

La version stable actuelle 0.11.0 nécessite que les choses suivantes soient vraies pour que la barre d'outils soit affichée:

Fichier de paramètres:

DEBUG = True
INTERNAL_IPSpour 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, spécifiez simplement votre adresse publique .
L'application debug_toolbar à installer ie INSTALLED_APPS = (..., 'debug_toolbar',)
La classe middleware de la barre d'outils de débogage à ajouter ie MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Il doit être placé le plus tôt possible dans la liste.

Fichiers modèles:

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

Fichiers statiques:

Si vous diffusez du contenu statique, assurez-vous de collecter les css, js et html en faisant:

./manage.py collectstatic

Remarque sur les versions à venir de django-debug-toolbar

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

Dans tous les cas, si vous souhaitez 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

— Donturner
source

2

en fait sa balise <body> </body> qui n'est pas nécessaire </html>

— Zgr3doo

20

J'ai tout essayé, de la configuration DEBUG = Trueaux paramètres en INTERNAL_IPSpassant par l'adresse IP de mon client, et même en configurant manuellement la barre d'outils de débogage Django (notez que les versions récentes font toutes les configurations automatiquement, comme l'ajout du middleware et des URL). Rien n'a fonctionné dans un serveur de développement distant (bien que cela fonctionne localement). La SEULE chose qui a fonctionné était de configurer la barre d'outils comme suit:

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

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

— Anoyz
source

16

Docker

Si vous développez avec un serveur Django dans un conteneur Docker avec docker, les instructions d'activation de la barre d'outils ne fonctionnent pas. La raison est liée au fait que l'adresse réelle que vous auriez besoin d'ajouter INTERNAL_IPSsera quelque chose de dynamique, comme 172.24.0.1. Plutôt que d'essayer de définir dynamiquement la valeur de INTERNAL_IPS, la solution 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 le vagabond.

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

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

donc si vous ne connaissez pas réellement la valeur de en REMOTE_ADDRraison de votre routage dynamique de docker, la barre d'outils ne fonctionnera pas. Vous pouvez utiliser la commande docker network pour voir les valeurs IP dynamiques, par exempledocker network inspect my_docker_network_name

— Mark Chackerian
source

15

J'ai la barre d'outils qui fonctionne parfaitement. Avec ces configurations:

DEBUG = True
INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
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

— César
source

2

Vous devriez probablement biffer votre adresse IP de votre réponse. Étant donné que la plupart des gens utilisent le haut débit ces jours-ci et que la plupart des connexions haut débit changent rarement d'adresse IP, voire jamais. Vous ne voulez probablement pas que cela traîne sur les interwebs.

— Chris Pratt

192.168. *. * Est une adresse IP locale interne attribuée à l'ordinateur par le routeur. L'adresse IP externe est différente.

— Robeezy

@rpod, c'est exactement pourquoi quelqu'un l'a modifié.

— Yuji 'Tomita' Tomita

Si vous utilisez l'un fichier de configuration est vrai, et ne veulent Debug Toolbar en dev, au lieu de l' ajouter aux MIDDLEWARE_CLASSES en base.pyvous pourriez vouloir ajouter à votre local.py: MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES.

— Rob Grant

12

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

INTERNE_IPS = ('10 .0.2.2 ',)

Cela devrait fonctionner.

— Bas Koopmans
source

1

Confirmé, cela a résolu mon problème en utilisant Vagrant sur OSX.

— Josh

C'est la solution la plus correcte et la plus probable et la plus simple :)

— Travail

6

J'ai eu le même problème et je l'ai finalement résolu après quelques recherches sur Google.

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

— Farhan Hafeez
source

4

Une autre chose qui peut faire en sorte que la barre d'outils reste cachée est qu'elle ne trouve pas les fichiers statiques requis. Les modèles debug_toolbar utilisent la balise de modèle {{STATIC_URL}}, alors assurez-vous qu'il existe un dossier dans vos fichiers statiques appelé barre d'outils de débogage.

La commande de gestion collectstatic devrait s'en occuper sur la plupart des installations.

— AgDude
source

3

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.

— metakermit
source

2

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

si la barre d'outils n'apparaît pas, mais qu'elle se charge dans le html (vérifiez votre site html 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 des erreurs 404 pour /static/debug_toolbar/js/toolbar.js)

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

config nginx:

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

config apache:

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 vers votre dossier de fichiers statiques défini

— Bob
source

2

Dans mon cas, c'était un autre problème qui n'a pas encore été mentionné ici: 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, il obtient seulement le "voir" le HTML gzippé, auquel il ne peut pas ajouter la barre d'outils.

J'ai supprimé GZipMiddleware dans mes paramètres de développement. La configuration manuelle de la configuration de la barre d'outils de débogage et le placement du middleware après GZip devraient également fonctionner.

— RemcoGerlich
source

Même l'activation de GZip au niveau de la vue avec gzip_pagefait disparaître la barre d'outils. docs.djangoproject.com/en/2.0/topics/http/decorators/…

— Brachamul

2

Dans mon cas, j'avais juste besoin de supprimer les fichiers compilés python ( *.pyc)

— dnaranjo
source

Merci pour ce commentaire, il m'a évité une dépression ce matin. Si tout le reste semble correct - et que ce projet fonctionnait auparavant très bien pour moi - essayez ceci et voyez si cela le résout. Le DDT HTML / JS était sur la page, tout avait l'air bien, mais il n'apparaissait toujours pas. J'ai effacé les fichiers pyc et ils ont recommencé à apparaître

— Shane

2

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 s'affiche.

 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 debug_toolbar dans votre 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: (django versions plus récentes)

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

Intergiciel de style ancien: (besoin d'avoir le keywork _CLASSES dans l'intergiciel)

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

— Stryker
source

1

Ce n'était pas le cas pour cet auteur spécifique, mais j'ai juste eu du mal à ne pas afficher la barre d'outils de débogage et après avoir fait tout ce qu'ils ont indiqué, j'ai découvert que c'était un problème avec l'ordre 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', )

— Anderson Santos
source

0

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 régulières dans mes modèles, j'affiche simplement le contenu en texte brut. Je l'ai résolu en héritant de chaque fichier html de base.html, qui a une balise.

— user1552891
source

0

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

— TimStaley
source

0

J'ai eu le même problème, je l'ai résolu en regardant le journal des erreurs d'Apache. J'ai fait fonctionner l'apache sur mac os x avec mod_wsgi Le dossier tamplete de debug_toolbar n'était pas en cours de chargement

Exemple de journal:

==> /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

— André Manzano
source

0

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

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

192.168.33.10Je me souviens que c'est l'adresse IP de mon réseau privé dans Vagrantfile.

— Adriano Silva
source

0

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

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

C'est le commit qui corrige cela.

Les documents expliquent comment installer à partir des sources.

— Petko M
source

0

Pour tous ceux qui utilisent Pycharm 5, le débogage des modèles ne fonctionne pas dans certaines versions. Fixe à 5.0.4, affectées vesions - 5.0.1, 5.0.2 Check out question

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

— Wolendranh
source

0

Dans le code sur lequel je travaillais, plusieurs petites requêtes ont été faites lors du traitement de la requête principale (c'est un cas d'utilisation très spécifique). C'étaient des requêtes traitées par le même thread de Django. La barre d'outils de débogage de Django (DjDT) ne s'attend pas à ce comportement et inclut les barres d'outils de DjDT à 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.

— jozo
source

0

Ce qui m'a donné est un navigateur obsolète!

Remarqué qu'il charge certaines feuilles de style à partir de la barre d'outils de débogage et a deviné qu'il pourrait s'agir d'un problème frontal.

— ogurets
source

0

Je sais que cette question est un peu ancienne, mais aujourd'hui, j'ai installé django-toolbar avec docker et suis tombé sur le même problème, cela l'a résolu pour moi

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]

Comme je l'ai lu dans un commentaire, le problème est que docker utilise une adresse IP dynamique, pour résoudre ce problème, nous pouvons obtenir l'adresse IP à partir du code ci-dessus

— Esequiel Albornoz
source

-1

Une chose stupide m'a fait ... que si vous utilisez apache wsgi, n'oubliez pas de toucher le fichier .wsgi pour forcer la recompilation de votre code. gaspille juste 20 minutes de mon temps pour déboguer l'erreur stupide :(

— igameland
source

django-debug-toolbar ne s'affiche pas

Docker