Ik heb andere vragen bekeken en kom er niet uit…
Ik heb het volgende gedaan om django-debug-toolbar te installeren:
- pip install django-debug-toolbar
- toegevoegd aan middleware-klassen:
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 toegevoegd:
INTERNAL_IPS = (‘174.121.34.187’,)
4 debug_toolbar toegevoegd aan geïnstalleerde apps
Ik krijg geen foutmeldingen of iets dergelijks, en de werkbalk verschijnt op geen enkele pagina, zelfs niet op admin.
Ik heb zelfs de directory van de debug_toolbar-sjablonen toegevoegd aan mijn TEMPLATE_DIRS
Antwoord 1, autoriteit 100%
Domme vraag, maar je hebt het niet genoemd, dus… Waar staat DEBUGop ingesteld? Het wordt niet geladen tenzij het Trueis.
Als het nog steeds niet werkt, probeer dan ook ‘127.0.0.1’ toe te voegen aan INTERNAL_IPS.
UPDATE
Dit is een uiterste inspanning, u zou dit niet moetendoen, maar het zal duidelijk laten zien of er alleen een configuratieprobleem is of dat er een groter probleem is.
Voeg het volgende toe aan settings.py:
def show_toolbar(request):
return True
SHOW_TOOLBAR_CALLBACK = show_toolbar
Dat verwijdert effectief alle controles door de debug-werkbalk om te bepalen of het zichzelf wel of niet moet laden; het zal altijd gewoon laden. Laat dat alleen staan voor testdoeleinden, als u het vergeet en ermee start, krijgen al uw bezoekers ook uw debug-werkbalk te zien.
Zie voor expliciete configuratie ook de officiële installatiedocumenten hier.
BEWERKEN (17-6-2015):
Blijkbaar is de syntaxis voor de nucleaire optie veranderd. Het staat nu in zijn eigen woordenboek:
def show_toolbar(request):
return True
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK" : show_toolbar,
}
Hun testsgebruiken dit woordenboek .
Antwoord 2, autoriteit 46%
Debug-werkbalk wil dat het ip-adres in request.META[‘REMOTE_ADDR’] wordt ingesteld in de INTERNAL_IPS-instelling. Gooi een afdrukverklaring in een van uw weergaven, zoals:
print("IP Address for debug-toolbar: " + request.META['REMOTE_ADDR'])
En laad dan die pagina. Zorg ervoor dat IP in uw INTERNAL_IPS-instelling in settings.py staat.
Normaal gesproken zou ik denken dat u het adres gemakkelijk kunt bepalen door naar het ip-adres van uw computer te kijken, maar in mijn geval gebruik ik de server in een virtuele box met port forwarding… en wie weet wat er is gebeurd . Ondanks dat ik het nergens zag in ifconfig op de VB of mijn eigen besturingssysteem, was het IP dat verscheen in de REMOTE_ADDR-sleutel wat deed de truc om de werkbalk te activeren.
Antwoord 3, autoriteit 28%
Als al het andere in orde is, kan het ook zijn dat uw sjabloon geen expliciete afsluitende <body>-tag heeft—
Antwoord 4, autoriteit 17%
Docker
Als je ontwikkelt met een Django-server in een Docker-container met docker, werken de instructies voor het inschakelen van de werkbalk niet. De reden is gerelateerd aan het feit dat het werkelijke adres dat je zou moeten toevoegen aan INTERNAL_IPSiets dynamischs zal zijn, zoals 172.24.0.1.
In plaats van te proberen de waarde van INTERNAL_IPSdynamisch in te stellen, is de eenvoudige oplossing om de functie die de werkbalk inschakelt te vervangen in uw settings.py, bijvoorbeeld:
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': lambda _request: DEBUG
}
Dit zou ook moeten werken voor andere dynamische routeringssituaties, zoals Vagrant of Heroku.
Hier zijn wat meer details voor nieuwsgierigen. De code in django_debug_tool die bepaalt of de werkbalk moet worden weergegeven, onderzoekt de waarde van REMOTE_ADDRals volgt:
if request.META.get('REMOTE_ADDR', None) not in INTERNAL_IPS:
return False
dus als u de waarde van REMOTE_ADDRniet echt weet vanwege uw dynamische docker-routing, zal de werkbalk niet werken. U kunt de opdracht docker network gebruiken om de dynamische IP-waarden te zien, bijvoorbeeld docker network inspect my_docker_network_name
Antwoord 5, autoriteit 16%
De huidige stabiele versie 0.11.0 vereist dat de volgende dingen waar zijn om de werkbalk te laten zien:
Instellingenbestand:
DEBUG = TrueINTERNAL_IPSom het IP-adres van uw browser op te nemen, in plaats van het serveradres. Als u lokaal bladert, moet ditINTERNAL_IPS = ('127.0.0.1',)zijn. Als u op afstand surft, hoeft u alleen maar uw openbare adres op te geven.- De debug_toolbar-app die moet worden geïnstalleerd, bijv.
INSTALLED_APPS = (..., 'debug_toolbar',) - De middleware-klasse voor de debug-werkbalk die moet worden toegevoegd, bijv.
MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Het moet zo vroeg mogelijk in de lijst worden geplaatst.
Sjabloonbestanden:
- Moet van het type
text/html - Moet een afsluitende
</html>-tag hebben
zijn
Statische bestanden:
Als u statische inhoud aanbiedt, zorg er dan voor dat u de css, js en html verzamelt door het volgende te doen:
./manage.py collectstatic
Opmerking over aankomende versies van django-debug-toolbar
Nieuwere ontwikkelingsversies hebben standaardinstellingen toegevoegd voor de instellingen 2, 3 en 4, wat het leven echter een beetje eenvoudiger maakt, zoals bij elke ontwikkelingsversie die bugs heeft. Ik ontdekte dat de nieuwste versie van git resulteerde in een ImproperlyConfigured-fout bij het doorlopen van nginx/uwsgi.
Hoe dan ook, als je de nieuwste versie van github run wilt installeren:
pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git#egg=django-debug-toolbar
Je kunt ook een specifieke commit klonen door het volgende te doen:
pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git@ba5af8f6fe7836eef0a0c85dd1e6d7418bc87f75#egg=django_debug_toolbar
Antwoord 6, autoriteit 13%
Ik heb alles geprobeerd, van het instellen van DEBUG = Truetot het instellen van INTERNAL_IPStot het IP-adres van mijn klant, en zelfs het handmatig configureren van de Django Debug Toolbar (merk op dat recente versies alle configuraties automatisch, zoals het toevoegen van de middleware en URL’s). Niets werkte in een externe ontwikkelingsserver (hoewel het lokaal werkte).
Het ENIGE dat werkte, was de werkbalk als volgt configureren:
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK" : lambda request: True,
}
Dit vervangt de standaardmethode die bepaalt of de werkbalk moet worden weergegeven, en retourneert altijd waar.
Antwoord 7, autoriteit 8%
Ik heb de werkbalk gewoon perfect werkend. Met deze configuraties:
DEBUG = TrueINTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}- De middleware is het eerste element in
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', )
Ik hoop dat het helpt
Antwoord 8, autoriteit 6%
Voeg 10.0.2.2toe aan uw INTERNAL_IPS op Windows, het wordt intern gebruikt met zwerver
INTERNAL_IPS = (
‘10.0.2.2’,
)
Dit zou moeten werken.
Antwoord 9, autoriteit 3%
Ik had hetzelfde probleem en heb het na wat googlen uiteindelijk opgelost.
In INTERNAL_IPS moet u het IP-adres van de clienthebben.
Antwoord 10, autoriteit 2%
Een ander ding dat ervoor kan zorgen dat de werkbalk verborgen blijft, is als het de vereiste statische bestanden niet kan vinden. De debug_toolbar-sjablonen gebruiken de sjabloontag {{ STATIC_URL }}, dus zorg ervoor dat er een map in uw statische bestanden is met de naam debug-werkbalk.
De opdracht collectstatic management zou dit op de meeste installaties moeten regelen.
Antwoord 11, autoriteit 2%
Een aanvulling op eerdere antwoorden:
als de werkbalk niet verschijnt, maar wordt geladen in de html (controleer de html van uw site in een browser, scroll naar beneden)
het probleem kan zijn dat statische debug-werkbalkbestanden niet worden gevonden (je kunt dit dan ook zien in de toegangslogboeken van je site, bijvoorbeeld 404-fouten voor /static/debug_toolbar/js/toolbar.js)
Het kan dan op de volgende manier worden opgelost (voorbeelden voor nginx en apache):
nginx-configuratie:
location ~* ^/static/debug_toolbar/.+.(ico|css|js)$ {
root [path to your python site-packages here]/site-packages/debug_toolbar;
}
apache-configuratie:
Alias /static/debug_toolbar [path to your python site-packages here]/site-packages/debug_toolbar/static/debug_toolbar
Of:
manage.py collectstatic
meer over collectstatic hier: https://docs.djangoproject. com/en/dev/ref/contrib/staticfiles/#collectstatic
Of verplaats handmatig de debug_toolbar map met debug_toolbar statische bestanden naar uw ingestelde statische bestanden map
Antwoord 12, autoriteit 2%
Ik heb de configuratie geprobeerd van pydanny’s cookiecutter-djangoen het werkte voor mij:
# 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
Ik heb het zojuist aangepast door 'debug_toolbar.apps.DebugToolbarConfig'toe te voegen in plaats van 'debug_toolbar'zoals vermeld in de officiële django-debug-toolbar-documenten, aangezien ik Django 1.7 gebruik.
Antwoord 13, autoriteit 2%
django 1.8.5:
Ik moest het volgende toevoegen aan het project url.py-bestand om de debug-werkbalk weer te geven. Daarna wordt de foutopsporingswerkbalk weergegeven.
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:en hoger:
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
Vergeet ook niet om de debug_toolbar aan uw middleware toe te voegen.
De Debug Toolbar is meestal geïmplementeerd in een middleware. Schakel het als volgt in uw instellingenmodule in:
(django nieuwere versies)
MIDDLEWARE = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
#
Oude-stijl middleware:(moet _CLASSES keywork in de middleware hebben)
MIDDLEWARE_CLASSES = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
# ...
]
Antwoord 14
Voor mij was dit zo simpel als het typen van 127.0.0.1:8000in de adresbalk, in plaats van localhost:8000wat blijkbaar niet overeenkwam met de INTERNAL_IPS.
p>
Antwoord 15
In mijn geval was het een ander probleem dat hier nog niet is genoemd: ik had GZipMiddleware in mijn lijst met middlewares.
Omdat de automatische configuratie van de debug-werkbalk de middleware van de debug-werkbalk bovenaan plaatst, krijgt deze alleen de gzipped HTML “zien”, waaraan de werkbalk niet kan worden toegevoegd.
Ik heb GZipMiddleware verwijderd in mijn ontwikkelingsinstellingen. Het handmatig instellen van de configuratie van de debug-werkbalk en het plaatsen van de middleware naGZip’s zou ook moeten werken.
Antwoord 16
In mijn geval moest ik alleen de door Python gecompileerde bestanden (*.pyc) verwijderen
Antwoord 17
Ik weet dat deze vraag een beetje oud is, maar vandaag heb ik django-toolbar met docker geïnstalleerd en kwam ik hetzelfde probleem tegen, dit loste het voor mij op
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]
Zoals ik in een opmerking heb gelezen, is het probleem dat docker een dynamisch ip gebruikt, om dit op te lossen kunnen we het ip uit de bovenstaande code halen
Antwoord 18
Dit was niet het geval voor deze specifieke auteur, maar ik worstelde gewoon met de Debug Toolbar die niet werd weergegeven en nadat ik alles had gedaan wat ze zeiden, ontdekte ik dat het een probleem was met de volgorde van MIDDLEWARE. Dus de middleware vroeg in de lijst plaatsen zou kunnen werken. De mijne is de eerste:
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',
)
Antwoord 19
Ik heb hetzelfde probleem, ik heb het opgelost door naar het foutenlogboek van Apache te kijken.
Ik heb de apache laten draaien op mac os x met mod_wsgi
De tamplete-map van de debug_toolbar werd niet geladen
Logvoorbeeld:
==> /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"
Ik voeg deze regel gewoon toe aan mijn VirtualHost-bestand:
Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar
- Natuurlijk moet je je python-pad veranderen
Antwoord 20
Het werkt voor mij.
#urls.py
if settings.DEBUG:
from django.conf.urls.static import static
import debug_toolbar
import mimetypes
mimetypes.add_type("application/javascript", ".js", True)
urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)
urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
urlpatterns = [path('__debug__/', include(debug_toolbar.urls)), ] + urlpatterns
Antwoord 21
u moet ervoor zorgen dat er een afsluitende tag in uw sjablonen zit.
Mijn probleem is dat er geen reguliere html-tags in mijn sjablonen staan, ik geef alleen inhoud weer in platte tekst. Ik heb het opgelost door elk html-bestand over te nemen van base.html, dat een tag heeft.
Antwoord 22
Ik had hetzelfde probleem bij het gebruik van Vagrant. Ik heb dit probleem opgelost door ::ffff:192.168.33.1toe te voegen aan de INTERNAL_IPS, zoals hieronder voorbeeld.
INTERNAL_IPS = (
'::ffff:192.168.33.1',
)
Onthouden dat 192.168.33.10het IP-adres is in mijn privénetwerk in Vagrantfile.
Antwoord 23
Ik had dit probleem en moest de debug-werkbalk van de bron installeren.
Versie 1.4 heeft een probleem waarbij het verborgen is als je PureCSS en blijkbaar andere CSS-frameworks gebruikt.
Ditis de commit die dat oplost.
De documenten leggen uit hoe te installeren vanaf de bron.
Antwoord 24
Voor iedereen die Pycharm 5 gebruikt – sjabloon debug werkt daar niet in sommige versies. Opgelost in 5.0.4, getroffen versies – 5.0.1, 5.0.2
Bekijk probleem
Besteed VEEL tijd om daar achter te komen. Misschien kan iemand helpen
Antwoord 25
In de code waar ik aan werkte, werden meerdere kleine verzoeken gedaan tijdens het verwerken van het hoofdverzoek (het is een zeer specifieke use case). Het waren verzoeken die door dezelfde Django-thread werden afgehandeld. Django debug toolbar (DjDT) verwacht dit gedrag niet en voegt de werkbalken van DjDT toe aan het eerste antwoord en verwijdert vervolgens de status voor de thread. Dus toen het hoofdverzoek werd teruggestuurd naar de browser, werd DjDT niet opgenomen in het antwoord.
Leren geleerd: DjDT slaat zijn status op per thread. Het verwijdert de status van een thread na de eerste reactie.
Antwoord 26
Wat me heeft opgeleverd is een verouderde browser!
Merk op dat het enkele stylesheets laadt van de debug-werkbalk en vermoedde dat het een front-end probleem zou kunnen zijn.
Antwoord 27
Na veel vallen en opstaan werkte dit voor mij in Django=3.1
Na het schrijven van alle internal_ip, middleware, toevoegingen in url, zet u deze code in settings.py hieronder
def show_toolbar(request):
return True
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK": show_toolbar,
'INSERT_BEFORE': '</head>'
}
Veel van hen stelden SHOW_TOOLBAR_CALLBACK voor, maar in mijn geval werkte het pas nadat ik ‘INSERT_BEFORE’ had toegevoegd
Antwoord 28
heb hetzelfde probleem
na het toevoegen
urls.py
mimetypes.add_type("application/javascript", ".js", True)
urlpatterns = [...
en
DEBUG_TOOLBAR_CONFIG = {
'INTERCEPT_REDIRECTS': False,
'SHOW_TOOLBAR_CALLBACK': lambda request: True,
'SHOW_TEMPLATE_CONTEXT': True,
'INSERT_BEFORE': '</head>'
}
JAVASCRIPTS-bestanden toegevoegd, maar alle tags hebben klasse djdt-hiddenen verborgen
<div id="djDebug" class="djdt-hidden" dir="ltr" data-default-show="true">
Ik gebruik GoogleChrome
In FireFoxBUG is vast en Django Toolbar-pictogram verschijnt
Antwoord 29
Als u Windows gebruikt, komt het misschien uit uw register.
Stel HKEY_CLASSES_ROOT.JS \ Content Type in op tekst / javascript in plaats van tekst / vlakte.
Antwoord 30
Voer de volgende opdracht uit:
python manage.py migrate
Voer nu opnieuw de server uit