django-debug-toolbar nie pojawia się

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:

  1. pip install django-debug-toolbar
  2. 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

Odpowiedzi:

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
28

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

Plik ustawień:

  1. DEBUG = True
  2. 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 .
  3. Aplikacja debug_toolbar do zainstalowania, tj INSTALLED_APPS = (..., 'debug_toolbar',)
  4. 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:

  1. Musi być odpowiedniego typu text/html
  2. 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:

  1. DEBUG = True
  2. INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
  3. DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
  4. 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
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.