django-debug-toolbar wird nicht angezeigt

132

Ich habe mir andere Fragen angesehen und kann es nicht herausfinden ...

Ich habe Folgendes getan, um die django-debug-toolbar zu installieren:

  1. pip install django-debug-toolbar
  2. zu Middleware-Klassen hinzugefügt:
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 hinzugefügt:

INTERNAL_IPS = ('174.121.34.187',)

4 debug_toolbar zu installierten Apps hinzugefügt

Ich erhalte keine Fehler oder ähnliches und die Symbolleiste wird auf keiner Seite angezeigt, nicht einmal auf dem Administrator.

Ich habe sogar das Verzeichnis der debug_toolbar-Vorlagen zu meinem hinzugefügt TEMPLATE_DIRS

python  django  django-debug-toolbar 
— AlexBrand
quelle
9
Wenn Sie Vagrant verwenden, stellen Sie sicher, dass Ihre INTERNAL_IPSkorrekt ist. Eine Möglichkeit, dies zu überprüfen, besteht darin, eine Ansicht zu drucken request.META['REMOTE_ADDR']und diese dann zu Ihrer Ansicht hinzuzufügen INTERNAL_IPS.
— Wird
1
Das könnte jemandem helfen. Ich habe versucht, '*'die internen IPs hinzuzufügen , aber das funktioniert nicht. Sie müssen bestimmte IPs eingeben.
— Luv33preet
In meiner settings.py ist es jetzt nur MIDDLEWARE, nicht MIDDLEWARE_CLASSES
— Bertie

Antworten:

174

Dumme Frage, aber du hast sie nicht erwähnt, also ... Was ist geplant DEBUG? Es wird nicht geladen, es sei denn True.

Wenn es immer noch nicht funktioniert, fügen Sie auch '127.0.0.1' hinzu INTERNAL_IPS.

AKTUALISIEREN

Dies ist ein letzter verzweifelter-Effort bewegen, sollten Sie nicht haben dies zu tun, aber es wird deutlich zeigen , wenn es nur einige Konfigurationsprobleme oder ob es einig größeres Problem.

Fügen Sie settings.py Folgendes hinzu:

def show_toolbar(request):
    return True
SHOW_TOOLBAR_CALLBACK = show_toolbar

Dadurch werden alle Überprüfungen per Debug-Symbolleiste effektiv entfernt, um festzustellen, ob sie selbst geladen werden sollen oder nicht. es wird immer nur geladen. Lassen Sie dies nur zu Testzwecken, wenn Sie es vergessen und damit starten, sehen alle Ihre Besucher auch Ihre Debug-Symbolleiste.

Eine explizite Konfiguration finden Sie auch in den offiziellen Installationsdokumenten hier .

EDIT (17.06.2015):

Anscheinend hat sich die Syntax für die Nuklearoption geändert. Es ist jetzt in einem eigenen Wörterbuch:

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

Ihre Tests verwenden dieses Wörterbuch.

— Chris Pratt
quelle
3
Ja, hier ist also ein größeres Problem im Gange. Wenn Sie etwas anderes verwenden, runserverstellen Sie sicher, dass Sie es neu starten. Verdammt, starten Sie runserverauch neu. Stellen Sie sicher, dass Ihre Änderungen an settings.py tatsächlich gespeichert / festgeschrieben wurden. Möglicherweise möchten Sie versuchen, * .pyc-Dateien zu entfernen. In * nix können Sie dies einfach mit find . -name "*.pyc" -exec rm {} \;dem Projektstamm tun . Führen Sie python manage.py shellabschließend from django.conf import settingsden Wert von aus , führen Sie ihn aus und überprüfen Sie ihn settings.INSTALLED_APPs.
— Chris Pratt
3
Ich bin mir nicht sicher, was Sie mit der letzten Frage meinen, aber wenn Sie sich darauf beziehen INTERNAL_IPS, sind diese für den Client und nicht für den Server (Django). Mit anderen Worten, Sie geben Ihre IP-Adresse ein, damit Sie die Debug-Symbolleiste sehen können, unabhängig davon, auf welcher IP die Site ausgeführt wird.
— Chris Pratt
10
INTERNAL_IPS hat mich auch .. Danke für die Info
— Lee
12
oder sogarSHOW_TOOLBAR_CALLBACK = lambda x: True
— John Mee
6
@schillingt ja, entschuldigung ich hätte das überprüfen sollen. Ich glaube, ich musste rennen collectstatic, um alles erscheinen zu lassen.
— Rob Grant
80

Die Debug-Symbolleiste möchte, dass die IP-Adresse in request.META ['REMOTE_ADDR'] in der Einstellung INTERNAL_IPS festgelegt wird. Geben Sie eine Druckanweisung in einer Ihrer Ansichten wie folgt ein:

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

Und dann laden Sie diese Seite. Stellen Sie sicher, dass sich IP in Ihrer INTERNAL_IPS-Einstellung in settings.py befindet.

Normalerweise würde ich denken, dass Sie die Adresse leicht anhand der IP-Adresse Ihres Computers ermitteln können, aber in meinem Fall verwende ich den Server in einer virtuellen Box mit Portweiterleitung ... und wer weiß, was passiert ist. Obwohl es in ifconfig auf der VB oder meinem eigenen Betriebssystem nirgendwo zu sehen war, war die IP, die im Schlüssel REMOTE_ADDR angezeigt wurde, der Trick, die Symbolleiste zu aktivieren.

— timothyashaw
quelle
2
Ich bin über den Nginx-Proxy-Pass auf meine Seite gelangt, daher war remote_addr mein Proxy und nicht meine echte IP. Ich musste meine Proxy-IP-Adresse hinzufügen INTERNAL_IPSund es begann zu funktionieren.
— Kurt
1
Auf meinem Gastcomputer in VirtualBox wird mein Hostcomputer als 10.0.0.2 angezeigt, wenn er jemandem helfen kann. :)
— mrmuggles
Sehr nützlich, um IP zu überprüfen, wenn Sie eine Virtualisierung wie VAGRANT
— andilabs
3
Im Docker war mein REMOTE_ADDR nicht das, was ich angenommen hätte.
— Aaron McMillin
28

Für die aktuelle stabile Version 0.11.0 müssen die folgenden Bedingungen erfüllt sein, damit die Symbolleiste angezeigt wird:

Einstellungsdatei:

  1. DEBUG = True
  2. INTERNAL_IPSum die IP-Adresse Ihres Browsers im Gegensatz zur Serveradresse anzugeben. Wenn Sie lokal surfen, sollte dies sein INTERNAL_IPS = ('127.0.0.1',). Wenn Sie remote surfen, geben Sie einfach Ihre öffentliche Adresse an .
  3. Die zu installierende debug_toolbar-App, d. H. INSTALLED_APPS = (..., 'debug_toolbar',)
  4. Die hinzuzufügende Middleware-Klasse der Debug-Symbolleiste, z MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). Es sollte so früh wie möglich in die Liste aufgenommen werden.

Vorlagendateien:

  1. Muss vom Typ sein text/html
  2. Muss ein schließendes </html>Tag haben

Statische Dateien:

Wenn Sie statischen Inhalt bereitstellen, stellen Sie sicher, dass Sie CSS, JS und HTML wie folgt erfassen: 

./manage.py collectstatic

Hinweis zu kommenden Versionen der Django-Debug-Symbolleiste

Neuere Entwicklungsversionen haben Standardeinstellungen für die Einstellungspunkte 2, 3 und 4 hinzugefügt, was das Leben jedoch etwas einfacher macht, da bei jeder Entwicklungsversion Fehler auftreten. Ich fand heraus, dass die neueste Version von git zu einem ImproperlyConfiguredFehler beim Ausführen von nginx / uwsgi führte.

So oder so, wenn Sie die neueste Version von github run installieren möchten:

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

Sie können auch ein bestimmtes Commit klonen, indem Sie Folgendes tun: 

pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git@ba5af8f6fe7836eef0a0c85dd1e6d7418bc87f75#egg=django_debug_toolbar
— donturner
quelle
2
eigentlich sein <body> </ body> -Tag, das nicht notwendig ist </ html>
— Zgr3doo
20

Ich habe alles versucht, von der Einstellung DEBUG = Trueüber die Einstellung INTERNAL_IPSder IP-Adresse meines Clients bis hin zur manuellen Konfiguration der Django Debug-Symbolleiste (beachten Sie, dass neuere Versionen alle Konfigurationen automatisch vornehmen, z. B. das Hinzufügen der Middleware und der URLs). Auf einem Remote-Entwicklungsserver funktionierte nichts (obwohl es lokal funktionierte). Das einzige, was funktioniert hat, war die Konfiguration der Symbolleiste wie folgt:

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

Dies ersetzt die Standardmethode, die entscheidet, ob die Symbolleiste angezeigt werden soll, und gibt immer true zurück.

— Anoyz
quelle
16

Docker

Wenn Sie mit einem Django-Server in einem Docker- Container mit Docker entwickeln, funktionieren die Anweisungen zum Aktivieren der Symbolleiste nicht. Der Grund hängt mit der Tatsache zusammen, dass die tatsächliche Adresse, die Sie hinzufügen INTERNAL_IPSmüssten, etwas Dynamisches sein wird, wie z. B. 172.24.0.1. Anstatt zu versuchen, den Wert von dynamisch festzulegen INTERNAL_IPS, besteht die einfache Lösung darin, die Funktion zu ersetzen, die die Symbolleiste aktiviert settings.py, z. B.:

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


Dies sollte auch für andere dynamische Routing-Situationen wie Vagrant funktionieren.

Hier sind einige Details für Neugierige. Der Code in django_debug_tool, der bestimmt, ob die Symbolleiste angezeigt werden soll, untersucht den Wert REMOTE_ADDRwie folgt :

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

Wenn Sie den Wert von REMOTE_ADDRaufgrund Ihres dynamischen Docker-Routings nicht kennen, funktioniert die Symbolleiste nicht. Mit dem Docker-Netzwerkbefehl können Sie beispielsweise die dynamischen IP-Werte anzeigendocker network inspect my_docker_network_name

— Mark Chackerian
quelle
15

Ich habe die Symbolleiste einfach perfekt funktionieren. Mit diesen Konfigurationen:

  1. DEBUG = True
  2. INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
  3. DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
  4. Die Middleware ist das erste 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',
)

Ich hoffe, es hilft

— César
quelle
2
Sie sollten wahrscheinlich Ihre IP-Adresse aus Ihrer Antwort heraus redigieren. Da die meisten Menschen heutzutage Breitband betreiben und die meisten Breitbandverbindungen die IP-Adresse selten oder nie ändern. Sie wollen wahrscheinlich nicht, dass das in den Interwebs herumhängt.
— Chris Pratt
192.168. *. * Ist eine interne lokale IP-Adresse, die dem Computer vom Router zugewiesen wird. Die externe IP-Adresse ist unterschiedlich.
— Robeezy
@rpod genau deshalb hat es jemand bearbeitet.
— Yuji 'Tomita' Tomita
Wenn Sie die One True Config-Datei verwenden und nur die Debug-Symbolleiste in dev möchten, anstatt sie zu den Middleware-Klassen in base.pyhinzuzufügen, möchten Sie diese möglicherweise zu Ihrer local.py: hinzufügen MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES.
— Rob Grant
12

Fügen Sie 10.0.2.2Ihrem INTERNAL_IPS unter Windows hinzu, es wird intern mit Vagrant verwendet

INTERNAL_IPS = ('10 .0.2.2 ',)

Das sollte funktionieren.

— Bas Koopmans
quelle
1
Bestätigt, dass dies mein Problem mit Vagrant unter OSX behoben hat.
— Josh
Dies ist die korrekteste und wahrscheinlichste Lösung und die einfachste :) Bestätigte Arbeit mit Vagrant unter Windows 7
— mislavcimpersak
6

Ich hatte das gleiche Problem und löste es schließlich nach einigem googeln.

In INTERNAL_IPS benötigen Sie die IP-Adresse des Clients .

— Farhan Hafeez
quelle
4

Eine andere Sache, die dazu führen kann, dass die Symbolleiste ausgeblendet bleibt, ist, wenn die erforderlichen statischen Dateien nicht gefunden werden können. Die Vorlagen debug_toolbar verwenden das Vorlagen-Tag {{STATIC_URL}}. Stellen Sie daher sicher, dass sich in Ihren statischen Dateien ein Ordner mit dem Namen debug toolbar befindet.

Der Befehl collectstatic management sollte dies bei den meisten Installationen berücksichtigen.

— AgDude
quelle
3

Ich habe die Konfiguration von pydannys Ausstecher-Django ausprobiert und es hat bei mir funktioniert:

# 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

Ich habe es nur durch Hinzufügen 'debug_toolbar.apps.DebugToolbarConfig'von Django 1.7 geändert, anstatt 'debug_toolbar'wie in den offiziellen Dokumenten der Django-Debug-Symbolleiste erwähnt .

— Metakermit
quelle
2

Eine Ergänzung zu früheren Antworten:

Wenn die Symbolleiste nicht angezeigt wird, aber in HTML geladen wird (überprüfen Sie das HTML Ihrer Website in einem Browser, scrollen Sie nach unten).

Das Problem kann sein, dass statische Dateien der Debug-Symbolleiste nicht gefunden werden (dies können Sie dann auch in den Zugriffsprotokollen Ihrer Site sehen, z. B. 404-Fehler für /static/debug_toolbar/js/toolbar.js).

Es kann dann folgendermaßen behoben werden (Beispiele für Nginx und Apache):

nginx config:

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

Apache-Konfiguration:

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

Oder:

manage.py collectstatic

Weitere Informationen zu collectstatic finden Sie hier: https://docs.djangoproject.com/de/dev/ref/contrib/staticfiles/#collectstatic

Oder verschieben Sie den Ordner debug_toolbar der statischen Dateien debug_toolbar manuell in Ihren festgelegten Ordner für statische Dateien

— Bob
quelle
2

In meinem Fall war es ein weiteres Problem, das hier noch nicht erwähnt wurde: Ich hatte GZipMiddleware in meiner Liste der Middlewares.

Da bei der automatischen Konfiguration der Debug-Symbolleiste die Middleware der Debug-Symbolleiste ganz oben steht, wird nur das komprimierte HTML angezeigt, zu dem die Symbolleiste nicht hinzugefügt werden kann.

Ich habe GZipMiddleware in meinen Entwicklungseinstellungen entfernt. Das manuelle Einrichten der Konfiguration der Debug-Symbolleiste und das Platzieren der Middleware nach GZip sollte ebenfalls funktionieren.

— RemcoGerlich
quelle
Selbst wenn Sie GZip auf Ansichtsebene mit aktivieren, gzip_pagewird die Symbolleiste ausgeblendet . docs.djangoproject.com/de/2.0/topics/http/decorators/…
— Brachamul
2

In meinem Fall musste ich nur die Python-kompilierten Dateien entfernen ( *.pyc)

— dnaranjo
quelle
Vielen Dank für diesen Kommentar, er hat mir heute Morgen einen Nervenzusammenbruch erspart. Wenn alles andere richtig aussieht - und dieses Projekt zuvor für mich gut funktioniert hat - versuchen Sie dies und prüfen Sie, ob es das Problem behebt. Das DDT HTML / JS war auf der Seite, alles sah gut aus, aber es wurde immer noch nicht angezeigt. Ich habe die Pyc-Dateien gelöscht und es wurde wieder angezeigt
— Shane
2

Django 1.8.5:

Ich musste der Datei url.py des Projekts Folgendes hinzufügen, um die Anzeige der Debug-Symbolleiste zu erhalten. Danach wird die Debug-Symbolleiste angezeigt.

 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: und höher:

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

Vergessen Sie auch nicht, die debug_toolbar in Ihre Middleware aufzunehmen. Die Debug-Symbolleiste ist meist in einer Middleware implementiert. Aktivieren Sie es in Ihrem Einstellungsmodul wie folgt: (Django neuere Versionen)

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

Middleware im alten Stil: (_CLASSES-Schlüssel müssen in der Middleware vorhanden sein)

MIDDLEWARE_CLASSES = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
# ...
]
— Stryker
quelle
1

Dies war bei diesem bestimmten Autor nicht der Fall, aber ich hatte nur Probleme damit, dass die Debug-Symbolleiste nicht angezeigt wurde, und nachdem ich alles getan hatte, worauf sie hingewiesen hatten, stellte ich fest, dass es sich um ein Problem mit der MIDDLEWARE-Bestellung handelte. Es könnte also funktionieren, die Middleware früh in die Liste aufzunehmen. Meins ist zuerst:

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
quelle
0

Sie müssen sicherstellen, dass Ihre Vorlagen ein schließendes Tag enthalten.

Mein Problem ist, dass meine Vorlagen keine regulären HTML-Tags enthalten. Ich zeige den Inhalt nur im Klartext an. Ich habe es gelöst, indem ich jede HTML-Datei von base.html geerbt habe, die ein Tag hat.

— user1552891
quelle
0

Für mich war dies so einfach wie das Eingeben 127.0.0.1:8000in die Adressleiste, anstatt dass localhost:8000dies anscheinend nicht mit INTERNAL_IPS übereinstimmte.

— TimStaley
quelle
0

Ich habe das gleiche Problem, ich habe es gelöst, indem ich mir das Fehlerprotokoll des Apache angesehen habe. Ich habe den Apache auf Mac OS X mit mod_wsgi ausgeführt. Der Tamplete-Ordner der debug_toolbar wurde nicht geladen

Protokollbeispiel:

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

Ich füge diese Zeile einfach meiner VirtualHost-Datei hinzu:

Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar
  • Natürlich müssen Sie Ihren Python-Pfad ändern
— Andre Manzano
quelle
0

Ich hatte das gleiche Problem mit Vagrant. Ich habe dieses Problem gelöst, indem ich ::ffff:192.168.33.1wie im folgenden Beispiel zu INTERNAL_IPS hinzugefügt habe .

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

Denken Sie daran, dass dies 192.168.33.10die IP in meinem privaten Netzwerk in Vagrantfile ist.

— Adriano Silva
quelle
0

Ich hatte dieses Problem und musste die Debug-Symbolleiste von der Quelle installieren.

Version 1.4 hat ein Problem, bei dem es ausgeblendet ist, wenn Sie PureCSS und anscheinend andere CSS-Frameworks verwenden.

Dies ist das Commit, das das behebt.

In den Dokumenten wird die Installation von der Quelle aus erläutert.

— Petko M.
quelle
0

Für alle, die Pycharm 5 verwenden - das Debuggen von Vorlagen funktioniert dort in einigen Versionen nicht. In 5.0.4 behoben, betroffene Versionen - 5.0.1, 5.0.2 Problem beim Auschecken

Verbringen Sie viel Zeit, um das herauszufinden. Vielleicht hilft jemand

— Wolendranh
quelle
0

In dem Code, an dem ich gearbeitet habe, wurden während der Bearbeitung der Hauptanforderung mehrere kleine Anforderungen gestellt (dies ist ein sehr spezifischer Anwendungsfall). Es waren Anfragen, die von demselben Django-Thread bearbeitet wurden. Die Django-Debug-Symbolleiste (DjDT) erwartet dieses Verhalten nicht und enthält die Symbolleisten von DjDT für die erste Antwort. Anschließend wird der Status für den Thread entfernt. Als die Hauptanforderung an den Browser zurückgesendet wurde, war DjDT nicht in der Antwort enthalten.

Lektionen gelernt: DjDT speichert seinen Status pro Thread. Nach der ersten Antwort wird der Status für einen Thread entfernt.

— jozo
quelle
0

Was mich dazu gebracht hat, ist ein veralteter Browser!

Es wurde festgestellt, dass einige Stylesheets aus der Debug-Symbolleiste geladen werden, und es wurde vermutet, dass es sich möglicherweise um ein Front-End-Problem handelt.

— ogurets
quelle
-1

Eine dumme Sache hat mich dazu gebracht, dass Sie, wenn Sie Apache wsgi verwenden, daran denken, die .wsgi-Datei zu berühren, um die Neukompilierung Ihres Codes zu erzwingen. Verschwenden Sie nur 20 Minuten meiner Zeit, um den dummen Fehler zu beheben :(

— Igameland
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.