132

Spojrzałem na inne pytania i nie mogę tego zrozumieć ...

Wykonałem następujące czynności, aby zainstalować pasek narzędzi django-debug:

pip install django-debug-toolbar
dodane do klas oprogramowania pośredniego:

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 Dodane INTERNAL_IPS:

INTERNAL_IPS = ('174.121.34.187',)

4 Dodano pasek debug_toolbar do zainstalowanych aplikacji

Nie otrzymuję żadnych błędów ani niczego, a pasek narzędzi nie pojawia się na żadnej stronie, nawet na panelu administracyjnym.

Dodałem nawet katalog szablonów debug_toolbar do mojego TEMPLATE_DIRS

python django django-debug-toolbar AlexBrand
źródło

9

Jeśli używasz Vagrant, upewnij się, że INTERNAL_IPSjest poprawny. Jednym ze sposobów sprawdzenia jest widok, wydrukowanie pliku request.META['REMOTE_ADDR'], a następnie dodanie go do pliku INTERNAL_IPS.

Will

1

To może komuś pomóc. Próbowałem dodać '*'wewnętrzne adresy IP, ale to nie działa. Musisz wprowadzić konkretne adresy IP.

Luv33preet

W moim settings.py jest to teraz tylko MIDDLEWARE, a nie MIDDLEWARE_CLASSES

bertie

174

Głupie pytanie, ale o nim nie wspomniałeś, więc ... Co jest DEBUGustawione? Nie załaduje się, chyba że jest True.

Jeśli nadal nie działa, spróbuj również dodać „127.0.0.1” do INTERNAL_IPS.

AKTUALIZACJA

To ostatnia próba, nie powinieneś tego robić, ale wyraźnie pokaże, czy jest tylko jakiś problem z konfiguracją, czy też jest jakiś większy problem.

Dodaj następujące elementy do settings.py:

def show_toolbar(request):
    return True
SHOW_TOOLBAR_CALLBACK = show_toolbar

To skutecznie usunie wszystkie sprawdzenia przez pasek narzędzi debugowania, aby określić, czy powinien, czy nie powinien się ładować; zawsze będzie się ładować. Pozostaw to tylko do celów testowych, jeśli zapomnisz i uruchomisz z nim, wszyscy odwiedzający zobaczą również pasek narzędzi debugowania.

Aby uzyskać jawną konfigurację, zapoznaj się również z oficjalną dokumentacją dotyczącą instalacji tutaj .

EDYCJA (17.06.2015):

Najwyraźniej zmieniła się składnia opcji jądrowej. Jest teraz w swoim własnym słowniku:

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

Ich testy wykorzystują ten słownik.

Chris Pratt
źródło

3

Tak, więc jest tu jakiś większy problem. Jeśli używasz czegoś innego niż runserverponowne uruchomienie. Heck, zrestartuj runserverteż. Upewnij się, że zmiany settings.py faktycznie został zapisany / zaangażowani. Możesz spróbować usunąć pliki * .pyc. W * nix możesz to zrobić po prostu z find . -name "*.pyc" -exec rm {} \;poziomu katalogu głównego projektu. Na koniec uruchom, python manage.py shellwykonaj from django.conf import settingsi sprawdź wartość settings.INSTALLED_APPs.

Chris Pratt

3

Nie jestem pewien, co masz na myśli w ostatnim pytaniu, ale jeśli odnosisz się do niego INTERNAL_IPS, są one przeznaczone dla klienta, a nie serwera (Django). Innymi słowy, wpisujesz swój adres IP, abyś mógł zobaczyć pasek narzędzi debugowania, bez względu na adres IP, na którym działa witryna.

Chris Pratt

10

INTERNAL_IPS też mnie dopadł. Dzięki za informację

Lee,

12

lub nawetSHOW_TOOLBAR_CALLBACK = lambda x: True

John Mee

6

@schillingt tak, przepraszam, że powinienem to sprawdzić. Myślę, że musiałem biec, collectstaticżeby wszystko się ukazało.

Rob Grant

80

Pasek narzędzi debugowania chce, aby adres IP w request.META [„REMOTE_ADDR”] był ustawiony w ustawieniu INTERNAL_IPS. Wrzuć wydrukowane oświadczenie w jednym ze swoich widoków, takich jak:

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

A następnie załaduj tę stronę. Upewnij się, że adres IP jest w ustawieniu INTERNAL_IPS w settings.py.

Normalnie pomyślałbym, że byłbyś w stanie łatwo określić adres, patrząc na adres IP twojego komputera, ale w moim przypadku uruchamiam serwer w wirtualnej skrzynce z przekierowaniem portów ... i kto wie, co się stało. Pomimo tego, że nie widziałem go nigdzie w ifconfig na VB lub moim własnym systemie operacyjnym, adres IP, który pojawił się w kluczu REMOTE_ADDR, był tym, co spowodowało aktywację paska narzędzi.

timothyashaw
źródło

2

Dostałem się do mojej strony przez Nginx proxy pass, więc zdalny_addr był moim proxy, a nie moim prawdziwym adresem IP. Musiałem dodać mój adres IP proxy do INTERNAL_IPSi zaczęło działać.

Kurt

1

Z mojego komputera gościa w VirtualBox mój komputer hosta jest wyświetlany jako 10.0.0.2, jeśli może to komuś pomóc. :)

mrmuggles

BARDZO przydatne do SPRAWDZANIA IP, jeśli używasz wirtualizacji, takiej jak VAGRANT

andilabs

3

W dockerze mój REMOTE_ADDR nie był tym, co bym przypuszczał.

Aaron McMillin

50

Jeśli wszystko inne jest w porządku, możliwe, że w Twoim szablonie brakuje wyraźnego <body>tagu zamykającego.

Uwaga: Pasek narzędzi debugowania wyświetli się tylko wtedy, gdy typ MIME odpowiedzi to text / html lub application / xhtml + xml i zawiera tag zamykający.

user1569050
źródło

W moim przypadku dodawanie do settings.py DEBUG_TOOLBAR_CONFIG = {'INSERT_BEFORE':'</head>'}zadziałało

wojteck

28

Obecna stabilna wersja 0.11.0 wymaga spełnienia następujących warunków, aby pasek narzędzi był wyświetlany:

Plik ustawień:

DEBUG = True
INTERNAL_IPSaby dołączyć adres IP przeglądarki, a nie adres serwera. Jeśli przeglądasz lokalnie, tak powinno być INTERNAL_IPS = ('127.0.0.1',). Jeśli przeglądasz zdalnie, po prostu podaj swój adres publiczny .
Aplikacja debug_toolbar do zainstalowania, tj INSTALLED_APPS = (..., 'debug_toolbar',)
Klasa oprogramowania pośredniczącego paska narzędzi debugowania, która ma zostać dodana, tj MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Powinien zostać umieszczony jak najwcześniej na liście.

Pliki szablonów:

Musi być odpowiedniego typu text/html
Musi mieć </html>tag zamykający

Pliki statyczne:

Jeśli obsługujesz treści statyczne, pamiętaj, aby zebrać pliki css, js i html, wykonując:

./manage.py collectstatic

Uwaga o nadchodzących wersjach django-debug-toolbar

Nowsze wersje deweloperskie dodały wartości domyślne dla punktów ustawień 2, 3 i 4, co sprawia, że życie jest nieco prostsze, jednak tak jak każda wersja rozwojowa ma błędy. Okazało się, że najnowsza wersja z gita spowodowała ImproperlyConfiguredbłąd podczas uruchamiania przez nginx / uwsgi.

Tak czy inaczej, jeśli chcesz zainstalować najnowszą wersję z github, uruchom:

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

Możesz również sklonować określone zatwierdzenie, wykonując:

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

donturner
źródło

2

w rzeczywistości jest to tag <body> </body>, który jest konieczny, a nie </html>

Zgr3doo

20

Próbowałem wszystkiego, od ustawień DEBUG = True, po ustawienia INTERNAL_IPSadresu IP mojego klienta, a nawet ręczne konfigurowanie paska narzędzi Django Debug (zwróć uwagę, że ostatnie wersje automatycznie wprowadzają wszystkie konfiguracje, takie jak dodawanie oprogramowania pośredniego i adresów URL). Nic nie działało na zdalnym serwerze programistycznym (chociaż działało lokalnie). Jedyną rzeczą, która działała, była konfiguracja paska narzędzi w następujący sposób:

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

Zastępuje to domyślną metodę, która decyduje, czy pasek narzędzi ma być wyświetlany, i zawsze zwraca wartość true.

Anoyz
źródło

16

Doker

Jeśli programujesz z serwerem Django w kontenerze Docker z dockerem, instrukcje włączania paska narzędzi nie działają. Powód jest związany z faktem, że rzeczywisty adres, do którego należałoby dodać, INTERNAL_IPSbędzie czymś dynamicznym, na przykład 172.24.0.1. Zamiast próbować dynamicznie ustawiać wartość INTERNAL_IPS, prostym rozwiązaniem jest zastąpienie funkcji, która włącza pasek narzędzi settings.py, na przykład:

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

Powinno to również działać w innych sytuacjach związanych z routingiem dynamicznym, takich jak włóczęga.

Oto więcej szczegółów dla ciekawskich. Kod w django_debug_tool, który określa, czy wyświetlić pasek narzędzi, sprawdza wartość w REMOTE_ADDRnastępujący sposób:

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

więc jeśli tak naprawdę nie znasz wartości z REMOTE_ADDRpowodu dynamicznego routingu dockera, pasek narzędzi nie będzie działał. Możesz na przykład użyć polecenia docker network, aby zobaczyć dynamiczne wartości IPdocker network inspect my_docker_network_name

Mark Chackerian
źródło

15

Mam pasek narzędzi działający idealnie. W tej konfiguracji:

DEBUG = True
INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
Oprogramowanie pośredniczące jest pierwszym elementem w 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',
)

Mam nadzieję, że to pomoże

César
źródło

2

Prawdopodobnie powinieneś zredagować swój adres IP z odpowiedzi. Ponieważ większość ludzi korzysta obecnie z łączy szerokopasmowych, a większość połączeń szerokopasmowych rzadko zmienia adres IP, jeśli w ogóle. Prawdopodobnie nie chcesz, żeby kręciło się to w sieciach.

Chris Pratt

192.168. *. * To wewnętrzny lokalny adres IP przypisany do komputera przez router. Zewnętrzny adres IP jest inny.

Robeezy

@rpod właśnie dlatego ktoś go do tego zredagował.

Yuji 'Tomita' Tomita

Jeśli używasz jeden prawdziwy plik konfiguracyjny, a jedynie chcą Debug Toolbar w dev, zamiast dodawania go do middleware_classes w base.pyciebie chcieć dodać go do local.py: MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES.

Rob Grant

12

Dodaj 10.0.2.2do swojego INTERNAL_IPS w systemie Windows, jest używany wewnętrznie z włóczęgą

INTERNAL_IPS = ('10 .0.2.2 ',)

To powinno działać.

Bas Koopmans
źródło

1

Potwierdzono, że to rozwiązało mój problem z używaniem Vagrant na OSX.

Josh

To jest najbardziej poprawne i najbardziej prawdopodobne rozwiązanie i najprostsze :) Potwierdzona praca z vagrantem na Windows 7

mislavcimpersak

6

Miałem ten sam problem i ostatecznie rozwiązałem go po pewnym googlowaniu.

W INTERNAL_IPS musisz mieć adres IP klienta .

Farhan Hafeez
źródło

4

Inną rzeczą, która może spowodować, że pasek narzędzi pozostanie ukryty, jest to, że nie może znaleźć wymaganych plików statycznych. Szablony debug_toolbar używają tagu szablonu {{STATIC_URL}}, więc upewnij się, że w Twoich statycznych plikach znajduje się folder o nazwie debug toolbar.

W większości instalacji powinno się tym zająć polecenie zarządzania zbiorczego.

AgDude
źródło

3

Wypróbowałem konfigurację z cookiecutter-django pydanny'ego i zadziałała:

# 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

Po prostu zmodyfikowałem go, dodając 'debug_toolbar.apps.DebugToolbarConfig'zamiast tego, 'debug_toolbar'jak wspomniano w oficjalnej dokumentacji django-debug-toolbar , ponieważ używam Django 1.7.

metakermit
źródło

2

Dodatek do poprzednich odpowiedzi:

jeśli pasek narzędzi nie pojawia się, ale ładuje się w html (sprawdź html swojej witryny w przeglądarce, przewiń w dół)

problem może polegać na tym, że nie znaleziono statycznych plików paska narzędzi debugowania (możesz to również zobaczyć w dziennikach dostępu do witryny, np. błędy 404 dla /static/debug_toolbar/js/toolbar.js)

Można to naprawić w następujący sposób (przykłady dla nginx i apache):

Konfiguracja nginx:

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

konfiguracja apache:

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

Lub:

manage.py collectstatic

więcej o collectstatic tutaj: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic

Lub ręcznie przenieś folder debug_toolbar plików statycznych debug_toolbar do ustawionego folderu plików statycznych

Pion
źródło

2

W moim przypadku był to kolejny problem, o którym jeszcze nie wspomniano: na mojej liście programów pośredniczących miałem GZipMiddleware.

Ponieważ automatyczna konfiguracja paska narzędzi debugowania umieszcza oprogramowanie pośrednie paska narzędzi debugowania na górze, otrzymuje on tylko „zobacz” spakowany kodem HTML HTML, do którego nie może dodać paska narzędzi.

Usunąłem GZipMiddleware w moich ustawieniach programistycznych. Ręczne skonfigurowanie konfiguracji paska narzędzi debugowania i umieszczenie oprogramowania pośredniego po GZip powinno również działać.

RemcoGerlich
źródło

Nawet włączenie GZip na poziomie widoku gzip_pagepowoduje zniknięcie paska narzędzi. docs.djangoproject.com/en/2.0/topics/http/decorators/ ...

Brachamul

2

W moim przypadku wystarczyło usunąć skompilowane pliki Pythona ( *.pyc)

dnaranjo
źródło

Dziękuję za ten komentarz, uratował mi to załamanie psychiczne dzisiejszego ranka. Jeśli wszystko inne wygląda dobrze - a ten projekt działał wcześniej dla mnie dobrze - spróbuj tego i zobacz, czy to rozwiązuje. Na stronie był kod DDT HTML / JS, wszystko wyglądało dobrze, ale nadal się nie wyświetlało. Wyczyściłem pliki pyc i zaczęły się ponownie pojawiać

Shane

2

django 1.8.5:

Musiałem dodać następujące elementy do pliku url.py projektu, aby wyświetlić pasek narzędzi debugowania. Następnie zostanie wyświetlony pasek narzędzi debugowania.

 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: i nowsze:

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

Nie zapomnij również dołączyć paska debug_toolbar do oprogramowania pośredniego. Pasek narzędzi debugowania jest głównie zaimplementowany w oprogramowaniu pośrednim. Włącz go w swoim module ustawień w następujący sposób: (nowsze wersje django)

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

Oprogramowanie pośredniczące w starym stylu: (trzeba mieć klucz _CLASSES w oprogramowaniu pośrednim)

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

Stryker
źródło

1

Nie dotyczyło to tego konkretnego autora, ale po prostu zmagałem się z tym, że pasek narzędzi debugowania nie wyświetlał się i po wykonaniu wszystkiego, co wskazali, okazało się, że to problem z zamówieniem MIDDLEWARE. Umieszczenie oprogramowania pośredniego na początku listy może więc zadziałać. Mój jest pierwszy:

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
źródło

0

musisz upewnić się, że w szablonach znajduje się tag zamykający.

Mój problem polega na tym, że w moich szablonach nie ma zwykłych tagów HTML, po prostu wyświetlam treść w postaci zwykłego tekstu. Rozwiązałem to dziedzicząc każdy plik html z base.html, który ma tag.

user1552891
źródło

0

Dla mnie było to tak proste, jak wpisanie 127.0.0.1:8000w pasku adresu, a nie to, localhost:8000co najwyraźniej nie pasowało do INTERNAL_IPS.

TimStaley
źródło

0

Mam ten sam problem, rozwiązałem go, przeglądając dziennik błędów Apache. Mam apache działający na Mac OS X z mod_wsgi Tamplete folder debug_toolbar nie był ładowany

Próbka dziennika:

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

Po prostu dodaję tę linię do mojego pliku VirtualHost:

Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar

Oczywiście musisz zmienić ścieżkę do Pythona

Andre Manzano
źródło

0

Miałem ten sam problem z Vagrantem. Rozwiązałem ten problem, dodając ::ffff:192.168.33.1do INTERNAL_IPS, jak na poniższym przykładzie.

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

Pamiętając, że 192.168.33.10jest to adres IP w mojej prywatnej sieci w Vagrantfile.

Adriano Silva
źródło

0

Miałem ten problem i musiałem zainstalować pasek narzędzi debugowania ze źródła.

Wersja 1.4 ma problem, gdzie jest ukryta, jeśli używasz PureCSS i najwyraźniej innych frameworków CSS.

To jest zatwierdzenie, które to naprawia.

Dokumentacja wyjaśnia, jak zainstalować ze źródła.

Petko M
źródło

0

Dla każdego, kto używa Pycharm 5 - debugowanie szablonów nie działa w niektórych wersjach. Naprawiono w wersji 5.0.4, dotyczy wersji - 5.0.1, 5.0.2 Sprawdź problem

Poświęć dużo czasu, aby się tego dowiedzieć. Może komuś pomoże

wolendranh
źródło

0

W kodzie, nad którym pracowałem, podczas obsługi głównego żądania pojawiło się wiele małych żądań (jest to bardzo specyficzny przypadek użycia). Były to żądania obsługiwane przez ten sam wątek Django. Pasek narzędzi debugowania Django (DjDT) nie oczekuje takiego zachowania i dołącza paski narzędzi DjDT do pierwszej odpowiedzi, a następnie usuwa stan wątku. Więc kiedy główne żądanie zostało wysłane z powrotem do przeglądarki, DjDT nie został uwzględniony w odpowiedzi.

Wyciągnięte wnioski: DjDT zapisuje swój stan na wątek. Usuwa stan wątku po pierwszej odpowiedzi.

jozo
źródło

0

To, co mnie dało, to przestarzała przeglądarka!

Zauważyłem, że ładuje niektóre arkusze stylów z paska narzędzi debugowania i zgadłem, że może to być problem z interfejsem.

ogurets
źródło

-1

Jedna głupia rzecz mnie dopadła ... że jeśli używasz apache wsgi, pamiętaj, aby dotknąć pliku .wsgi, aby wymusić ponowną kompilację kodu. po prostu zmarnuj 20 minut mojego czasu na debugowanie głupiego błędu :(

igameland
źródło

django-debug-toolbar nie pojawia się

Odpowiedzi:

Doker