Я посмотрел на другие вопросы и не могу понять ...
Я сделал следующее для установки django-debug-toolbar:
- pip install django-debug-toolbar
- добавлено в классы промежуточного программного обеспечения:
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:
ВНУТРЕННИЙ_IPS = ('174.121.34.187',)
4 Добавлен debug_toolbar в установленные приложения
Я не получаю никаких ошибок или чего-то еще, и панель инструментов не отображается ни на одной странице, даже у администратора.
Я даже добавил каталог шаблонов debug_toolbar в свой TEMPLATE_DIRS
python
django
django-debug-toolbar
AlexBrand
источник
источник
INTERNAL_IPS
правильный. Один из способов проверить это в представлении, распечатать егоrequest.META['REMOTE_ADDR']
, а затем добавить в свойINTERNAL_IPS
.'*'
внутренние IP-адреса, но это не сработало. Вы должны ввести конкретные IP-адреса.Ответы:
Глупый вопрос, но вы не упомянули об этом, так что ... Что
DEBUG
установлено? Он не будет загружаться, если это не такTrue
.Если он по-прежнему не работает, попробуйте также добавить «127.0.0.1»
INTERNAL_IPS
.ОБНОВИТЬ
Это последний шаг, который вам не нужен, вам не нужно этого делать, но он ясно покажет, есть ли какая-то проблема с конфигурацией или есть какая-то большая проблема.
Добавьте в settings.py следующее:
Это эффективно удалит все проверки с помощью панели инструментов отладки, чтобы определить, должна ли она или не должна загружаться сама; он всегда будет просто загружаться. Оставьте это только для целей тестирования, если вы забудете и запустите его, все ваши посетители также увидят вашу панель отладки.
Для явной настройки также см. Официальную документацию по установке здесь .
EDIT (6/17/2015):
Видимо, синтаксис для ядерной опции изменился. Теперь это в своем собственном словаре:
Их тесты используют этот словарь.
источник
runserver
забудьте перезапустить его. Черт возьми, перезагрузиrunserver
тоже. Убедитесь, что ваши изменения в settings.py действительно сохранены / зафиксированы. Вы можете попробовать удалить файлы * .pyc. В * nix вы можете сделать это простоfind . -name "*.pyc" -exec rm {} \;
из корня проекта. Наконец, запуститеpython manage.py shell
и выполнитеfrom django.conf import settings
и проверьте значениеsettings.INSTALLED_APPs
.INTERNAL_IPS
, они предназначены для клиента, а не для сервера (Django). Другими словами, вы кладете в ваш IP - адрес , чтобы вы можете увидеть отладки панели инструментов, независимо от того , что IP - сайт может быть запущен на.SHOW_TOOLBAR_CALLBACK = lambda x: True
collectstatic
чтобы все появилось.Панель инструментов отладки хочет, чтобы IP-адрес в request.META ['REMOTE_ADDR'] был установлен в настройке INTERNAL_IPS. Добавьте выражение для печати в одно из ваших представлений, например:
И затем загрузите эту страницу. Убедитесь, что IP указан в настройке INTERNAL_IPS в settings.py.
Обычно я думал, что вы сможете легко определить адрес, посмотрев на IP-адрес вашего компьютера, но в моем случае я запускаю сервер в виртуальном ящике с переадресацией портов ... и кто знает, что произошло. Несмотря на то, что я не видел его нигде в ifconfig на VB или в моей собственной ОС, IP-адрес, отображаемый в ключе REMOTE_ADDR, был тем, что помогло активировать панель инструментов.
источник
INTERNAL_IPS
и он начал работать.Если все остальное в порядке, возможно, в вашем шаблоне отсутствует явный закрывающий
<body>
тег -источник
DEBUG_TOOLBAR_CONFIG = {'INSERT_BEFORE':'</head>'}
сработалоТекущая стабильная версия 0.11.0 требует, чтобы для отображения панели инструментов выполнялись следующие условия:
Файл настроек:
DEBUG = True
INTERNAL_IPS
чтобы указать IP-адрес вашего браузера, а не адрес сервера. Если просматривать локально, это должно бытьINTERNAL_IPS = ('127.0.0.1',)
. Если вы просматриваете удаленно, просто укажите свой публичный адрес .INSTALLED_APPS = (..., 'debug_toolbar',)
MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...)
. Его следует разместить в списке как можно раньше.Файлы шаблонов:
text/html
</html>
тегСтатические файлы:
Если вы обслуживаете статический контент, убедитесь, что вы собираете css, js и html, выполнив:
Замечание о следующих версиях django-debug-toolbar
Более новые версии для разработчиков добавили значения по умолчанию для пунктов настроек 2, 3 и 4, что делает жизнь немного проще, однако, как и в любой версии для разработки, в ней есть ошибки. Я обнаружил, что последняя версия из git привела к
ImproperlyConfigured
ошибке при запуске через nginx / uwsgi.В любом случае, если вы хотите установить последнюю версию с github, запустите:
Вы также можете клонировать определенный коммит, выполнив:
источник
Я перепробовал все, от настроек
DEBUG = True
до настроекINTERNAL_IPS
IP-адреса моего клиента, и даже вручную настраивал Django Debug Toolbar (обратите внимание, что в последних версиях все конфигурации выполняются автоматически, например, добавление промежуточного программного обеспечения и URL-адресов). На удаленном сервере разработки ничего не работало (хотя оно работало локально). ЕДИНСТВЕННАЯ вещь, которая работала, настраивала панель инструментов следующим образом:Это заменяет метод по умолчанию, который определяет, должна ли отображаться панель инструментов, и всегда возвращает true.
источник
докер
Если вы разрабатываете сервер Django в Docker- контейнере с Docker , инструкции по включению панели инструментов не работают. Причина связана с тем, что фактический адрес, к которому вам нужно будет добавить,
INTERNAL_IPS
будет динамичным, например, 172.24.0.1. Вместо того, чтобы пытаться динамически установить значениеINTERNAL_IPS
, простое решение состоит в том, чтобы заменить функцию, которая включает панель инструментов, в вашемsettings.py
, например:Это также должно работать для других ситуаций динамической маршрутизации, например vagrant.
Вот еще несколько подробностей для любопытных. Код в django_debug_tool, который определяет, показывать ли панель инструментов, проверяет значение
REMOTE_ADDR
следующим образом:так что если вы на самом деле не знаете значение из-
REMOTE_ADDR
за вашей динамической маршрутизации докера, панель инструментов не будет работать. Вы можете использовать команду docker network для просмотра динамических значений IP, напримерdocker network inspect my_docker_network_name
источник
У меня панель инструментов работает просто идеально. С этой конфигурацией:
DEBUG = True
INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
MIDDLEWARE_CLASSES
:Я надеюсь, что это помогает
источник
base.py
вас , возможно , захотите , чтобы добавить это к вашемуlocal.py
:MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES
.Добавьте
10.0.2.2
в свой INTERNAL_IPS в Windows, он используется с бродягой внутриINTERNAL_IPS = ('10 .0.2.2 ',)
Это должно работать.
источник
У меня была та же проблема и, наконец, я решил ее после некоторого поиска в Google.
В INTERNAL_IPS вам нужен IP-адрес клиента .
источник
Еще одна вещь, из-за которой панель инструментов может оставаться скрытой, - это невозможность найти необходимые статические файлы. Шаблоны debug_toolbar используют тег шаблона {{STATIC_URL}}, поэтому убедитесь, что в ваших статических файлах есть папка, называемая панелью инструментов отладки.
Команда управления collectstatic должна позаботиться об этом на большинстве установок.
источник
Дополнение к предыдущим ответам:
если панель инструментов не отображается, но загружается в HTML (проверьте HTML своего сайта в браузере, прокрутите вниз)
проблема может заключаться в том, что статические файлы панели инструментов отладки не найдены (вы также можете увидеть это в журналах доступа вашего сайта, например, ошибки 404 для /static/debug_toolbar/js/toolbar.js)
Тогда это можно исправить следующим образом (примеры для nginx и apache):
Конфигурация nginx:
Конфигурация apache:
Или:
подробнее о collectstatic здесь: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic
Или вручную переместите папку debug_toolbar статических файлов debug_toolbar в установленную папку статических файлов
источник
Я попробовал конфигурацию из pydanny cookiecutter-django, и у меня это сработало:
Я просто изменил его, добавив
'debug_toolbar.apps.DebugToolbarConfig'
вместо того,'debug_toolbar'
как указано в официальных документах django-debug-toolbar , поскольку я использую Django 1.7.источник
В моем случае это была еще одна проблема, о которой здесь еще не упоминалось: в моем списке промежуточного программного обеспечения было GZipMiddleware.
Поскольку автоматическая конфигурация панели инструментов отладки помещает промежуточное программное обеспечение панели отладки вверху, она только «видит» сжатый HTML-код, к которому не может добавить панель инструментов.
Я удалил GZipMiddleware в моих настройках разработки. Настройка конфигурации панели инструментов отладки вручную и размещение промежуточного программного обеспечения после GZip также должно работать.
источник
gzip_page
делает панель инструментов исчезающей. docs.djangoproject.com/en/2.0/topics/http/decorators/…В моем случае мне просто нужно было удалить скомпилированные файлы python (
*.pyc
)источник
django 1.8.5:
Мне пришлось добавить следующее в файл проекта url.py, чтобы отобразить панель инструментов отладки. После этого отображается панель инструментов отладки.
django 1.10: и выше:
Также не забудьте включить debug_toolbar в ваше промежуточное ПО. Панель инструментов отладки в основном реализована в промежуточном программном обеспечении. Включите его в вашем модуле настроек следующим образом: (django более новые версии)
Промежуточное ПО старого стиля: (в промежуточном программном обеспечении необходимо иметь ключ _CLASSES)
источник
Это не относится к данному конкретному автору, но я просто боролся за то, чтобы панель инструментов отладки не отображалась, и после выполнения всего, на что они указывали, я обнаружил, что это проблема с порядком MIDDLEWARE. Так что размещение промежуточного ПО в начале списка может сработать. Мой первый:
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', )
источник
вы должны убедиться, что в ваших шаблонах есть закрывающий тег.
Моя проблема в том, что в моих шаблонах нет обычных HTML-тегов, я просто отображаю текст в виде простого текста. Я решил это, унаследовав каждый HTML-файл от base.html, который имеет тег.
источник
Для меня это было так же просто, как ввести
127.0.0.1:8000
в адресную строку, а не то,localhost:8000
что явно не соответствовало INTERNAL_IPS.источник
Я получил ту же проблему, я решил ее, посмотрев журнал ошибок Apache. У меня запущен apache на mac os x с mod_wsgi. Папка tamplete debug_toolbar не загружалась
Образец журнала:
Я просто добавляю эту строку в свой файл VirtualHost:
источник
У меня была такая же проблема с использованием Vagrant. Я решил эту проблему, добавив
::ffff:192.168.33.1
к INTERNAL_IPS, как показано ниже.Помните, что
192.168.33.10
это IP в моей частной сети в Vagrantfile.источник
У меня была эта проблема, и мне пришлось установить панель инструментов отладки из исходного кода.
В версии 1.4 есть проблема, которая скрыта, если вы используете PureCSS и, очевидно, другие CSS-фреймворки.
Это коммит, который исправляет это.
Документы объясняют, как установить из исходного кода.
источник
Для всех, кто использует Pycharm 5, в некоторых версиях отладка шаблона не работает. Исправлено в 5.0.4, затронутые версии - 5.0.1, 5.0.2 Извлечь проблему
Потратьте много времени, чтобы выяснить это. Может кому поможет
источник
В коде, над которым я работал, во время обработки основного запроса было сделано несколько небольших запросов (это очень специфический вариант использования). Это были запросы, обработанные тем же потоком Джанго. Панель инструментов отладки Django (DjDT) не ожидает такого поведения и включает панели инструментов DjDT в первый ответ, а затем удаляет свое состояние для потока. Поэтому, когда основной запрос был отправлен обратно в браузер, DjDT не был включен в ответ.
Извлеченные уроки: DjDT сохраняет свое состояние для каждого потока. Он удаляет состояние потока после первого ответа.
источник
Что меня достало, так это устаревший браузер!
Заметил, что он загружает некоторые таблицы стилей с панели отладки и предположил, что это может быть проблема внешнего интерфейса.
источник
Я знаю, что этот вопрос немного устарел, но сегодня я установил django-toolbar с докером и столкнулся с той же проблемой, это решило ее для меня
Как я читал в комментарии, проблема в том, что Docker использует динамический IP, чтобы решить это, мы можем получить IP из приведенного выше кода
источник
Одна глупая вещь меня поймала ... если вы используете apache wsgi, не забудьте прикоснуться к файлу .wsgi, чтобы принудительно перекомпилировать код. просто потратить 20 минут моего времени на отладку глупой ошибки :(
источник