Django-de

Django Dokumentation

Django-Einstellungen

Diese Dokumentation gilt für Djangos Entwicklerversion, die zum Teil erhebliche Unterschiede zur letzten veröffentlichen Version aufweist.

Eine Django-Einstellungsdatei enthält die Konfiguration deiner Django-Installation. Dieses Dokument erklärt, welche Einstellungen verfügbar sind und was sie bewirken.

Die Grundlagen

Eine Einstellungsdatei ist auch nur ein Python-Modul mit Variablen auf Modul-Ebene.

Hier siehst du eine Reihe von Beispieleinstellungen:

DEBUG = False
DEFAULT_FROM_EMAIL = 'webmaster@example.com'
TEMPLATE_DIRS = ('/home/templates/mike', '/home/templates/john')

Da eine Einstellungsdatei ein Python-Modul ist, gelten die folgenden Regeln:

  • Es erlaubt keine Python-Syntax Fehler.

  • Man kann mittels der normalen Python-Syntax dynamisch Einstellungen zuweisen.

    Beispiel:

    MY_SETTING = [str(i) for i in range(30)]

  • Man kann Inhalte von anderen Einstellungs-Dateien importieren.

Zuweisen der Einstellungen

Wenn du Django benutzen willst, musst vorher angeben welche Einstellungen verwendet werden sollen. Dies erreichst du mit der Umgebungsvariable DJANGO_SETTINGS_MODULE.

Der Inhalt von DJANGO_SETTINGS_MODULE sollte in der Python-Path Syntax geschrieben sein, z.B. mysite.settings. Beachte, dass das Einstellungsmodul im Python import search path zu finden sein muss.

Das django-admin-py Utility

Bei der Nutzung von django-admin.py kannst du entweder die Umgebungsvariable einmalig setzen oder das Einstellungsmodul bei jedem Lauf gesondert zuweisen.

Beispiel (Unix Bash Shell):

export DJANGO_SETTINGS_MODULE=mysite.settings
django-admin.py runserver

Beispiel (Windows Shell):

set DJANGO_SETTINGS_MODULE=mysite.settings
django-admin.py runserver

Nutze das --settings Kommandozeilen-Argument um die Einstellungsdatei manuell zuzuweisen:

django-admin.py runserver --settings=mysite.settings

Auf dem Server (mod_python)

In einer Live-Serverumgebung musst du Apache/mod_python mitteilen, welche Einstellungsdatei genutzt werden soll. Dies geschieht mittels SetEnv:

<Location "/mysite/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE mysite.settings
</Location>

Mehr Informationen dazu findest du in der Django mod_python Dokumentation

Standardeinstellungen

Eine Django-Einstellungsdatei muss nicht zwangsläufig jede Einstellungsvariable beinhalten. Jede Einstellungsvariable hat einen vernünftigen Standardwert, diese Werte findest du in der Datei django/conf/global_settings.py.

Hier ist der Ablauf den Django nutzt, um Einstellungen zu verarbeiten:

  • Lade Einstellungen von global_settings.py.
  • Lade Einstellungen von der zugewiesenen Einstellungsdatei und überschreibe dabei die globalen Einstellungen.

Beachte, dass eine Einstellungsdatei niemals die global_settings importieren sollte, da dies nur redundant ist.

Finde heraus, welche Einstellungen du geändert hast

Es gibt einen einfachen Weg um herauszufinden, welche Einstellungen von den Standardwerten abweichen. Das Kommando python manage.py diffsettings zeigt die Abweichungen zwischen den aktuellen Einstellungen und Djangos Standardeinstellungen.

Mehr Informationen findest du in der diffsettings Dokumentation.

Einstellungen im Python-Code nutzen

In deinen Django-Anwendungen kannst du die Einstellungen aus dem django.conf.settings Objekt importieren. Beispiel:

from django.conf import settings

if settings.DEBUG:
    # Do something

Beachte, dass django.conf.settings kein Modul sondern ein Objekt ist. Damit ist es nicht möglich, individuelle Einstellungen zu importieren.

from django.conf.settings import DEBUG  # Das funktioniert nicht.

Beachte auch, dass dein Code weder die Einstellungen aus den global_settings, noch aus deiner eigenen Einstellungsdatei direkt importieren sollte. django.conf.settings nutzt das Prinzip der Standard- und Seiten-spezifischen Einstellungen und stellt ein gesondertes Interface zur Verfügung. Außerdem wird damit der Zugriff auf die Einstellungen vom Ort der eigentlichen Einstellungsdatei getrennt.

Einstellungen zur Laufzeit ändern

Du solltest die Einstellungen in deiner Anwendung nicht zur Laufzeit ändern. Beispielsweise, mache dies nicht in einem View:

from django.conf import settings

settings.DEBUG = True   # Tu das nicht!

Der einzige Ort an dem du Einstellungen zuweisen solltest, ist die Einstellungsdatei.

Sicherheit

Da die Einstellungsdatei sensible Informationen, wie z.B. das Datenbank-Passwort, enthält, solltest du den Zugriff auf diese Datei auf ein Minimum reduzieren. Ändere z.B. die Dateirechte so, dass nur dir und dem Webserver Leserechte gewährt werden. Dies ist besonders in Shared-Hosting Umgebungen wichtig!

Verfügbare Einstellungen

Hier ist die komplette Liste aller verfügbaren Einstellungsmöglichkeiten, in alphabetischer Reichenfolge und mit ihren Standardwerten.

ABSOLUTE_URL_OVERRIDES

Standard: {} (Leeres Dictionary)

Ein Dictionary-Mapping im Format "app_label.model_name" : URL-Funktion das ein Model-Objekt aufruft und seine URL zurück gibt. Dies ist ein Weg, um get_absolute_url() in einer “per Installation” Basis zu übergehen. Beispiel:

ABSOLUTE_URL_OVERRIDES = {
    'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
    'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
}

Beachte, dass der Model-Name in dieser Einstellung immer kleingeschrieben werden sollte, unabhängig davon in welcher Form der echte Model-Name ist.

ADMIN_FOR

Standard: () (Leeres Tupel)

Wird für die Einstellungsmodule der Administrationsoberfläche genutzt. Dies sollte ein Tupel aus Einstellungsmodulen (im Format 'foo.bar.baz') sein, welche in der Administrationsoberfläche dargestellt werden sollen.

Die Administrationsoberfläche nutzt dies in ihrer automatisch-geprüften Dokumentation von Datenmodelle, Views und Template-Tags.

ADMIN_MEDIA_PREFIX

Standard: '/media/'

Der URL-Präfix für die Admin-Mediendateien — CSS, JavaScript und Bilder. Achte auf den abschließenden Schrägstrich.

ADMINS

Standard: () (Leeres Tupel)

Ein Tupel die die Personen auflistet, welche Code-Error-Meldungen erhalten. Wenn DEBUG=False gesetzt ist und ein View eine Exception (Ausnahme) auslöst, wird Django eine E-Mail mit der kompletten Exception an diese Leute senden. Jedes Element dieses Tupels sollte wiederum ein Tupel aus (Voller Name, E-Mail-Adresse) enthalten. Beispiel:

(
    ('John', 'john@example.com'),
    ('Mary', 'mary@example.com')
)

Beachte, dass Django eine E-Mail an alle diese Personen schickt wenn ein Fehler auftritt. Mehr Informationen findest du in der Sektion Fehlerberichte per E-Mail

ALLOWED_INCLUDE_ROOTS

Standard: () (Leeres Tupel)

Ein Tupel mit Strings, das die erlaubten Präfixe für den {% ssi %} Template-Tag enthält. Dies ist eine Sicherheitsmaßnahme mit dem für Template-Autoren festgelegt werden kann, auf welche Dateien sie zugreifen dürfen — und nicht dürfen.

Wenn z.B. ALLOWED_INCLUDE_ROOTS auf ('/home/html', '/var/www') gesetzt ist, dann würde {% ssi /home/html/foo.txt %} funktionieren, {% ssi /etc/passwd %} aber nicht.

APPEND_SLASH

Standard: True

Schrägstriche werden automatisch an die URL angefügt. Diese Option ist nur aktiv, wenn CommonMiddleware installiert ist (Siehe dazu auf Middleware Dokumentation). Siehe auch PREPEND_WWW.

AUTHENTICATION_BACKENDS

Standard: ('django.contrib.auth.backends.ModelBackend',)

Ein Tupel mit Authentication Backend Classes (als Strings) die genutzt werden, wenn ein Benutzer authentifiziert werden soll. Nähere Details findest du in der Dokumentation zu Authentifizierungs-Backends.

AUTH_PROFILE_MODULE

Standard: Nicht definiert

Das seitenspezifische Benutzerprofil-Datenmodell, nährere Informationen in der Dokumentation über Benutzerprofil-Datenmodelle.

CACHE_BACKEND

Standard: 'simple://'

Das zu nutzende Cache-Backend. Siehe auch Cache Dokumentation.

CACHE_MIDDLEWARE_KEY_PREFIX

Standard: '' (Leerer String)

Der Cache-Key-Präfix den die Cache-Middleware nutzen soll. Siehe auch Cache Dokumentation.

CACHE_MIDDLEWARE_SECONDS

Standard: 600

Die Dauer in Sekunden, die eine Seite im Cache zwischengespeichert werden soll, wenn die Cache-Middleware oder der cache_page() Decorator genutzt wird.

DATABASE_ENGINE

Standard: '' (Leerer String)

Das Datenbank-Backend, das genutzt werden soll. Die mitgelieferten Backends sind 'postgresql_psycopg2', 'postgresql', 'mysql', 'mysql_old', 'sqlite3', 'oracle', und 'ado_mssql'.

In Djangos Entwicklerversion kannst du auch ein Datenbank-Backend nutzen, das nicht mitgeliefert wird. Ändere dazu die Option DATABASE_ENGINE in einen validen (fully-qualified) Pfad (z.B. mypackage.backends.whatever).

Wenn du ein komplett neues Datenbank-Backend schreiben willst, schau dir die anderen Datenbank-Backends als Beispiel an.

DATABASE_HOST

Standard: '' (Leerer String)

Gibt an, welcher Hostname genutzt werden soll, um die Verbindung zur Datenbank aufzubauen. Ein leerer String bedeutet localhost. Gilt nicht für SQLite.

Wenn der Wert mit einem Schrägstrich ('/') beginnt und du MySQL nutzt , dann wird MySQL über einen Unix-Socket mit dem angegebenen Socket verbunden. Beispiel:

DATABASE_HOST = ‘/var/run/mysql’

Wenn du MySQL nutzt und dieser Wert nicht mit einem Schrägstrich beginnt, wird angenommen, dass der Wert der Hostname ist.

Wenn du PostgreSQL nutzt, bedeutet ein leerer String, dass ein Unix Domain Socket für die Verbindung genutzt werden soll und keine Netzwerkverbindung zu localhost. Wenn du explizit eine lokale TCP/IP-Verbindung zu PostgreSQL aufbauen willst, gib hier localhost an.

DATABASE_NAME

Standard: '' (Leerer String)

Der Name der Datenbank. Bei SQLite der komplette Pfad zur Datenbankdatei.

DATABASE_OPTIONS

Standard: {} (Leeres Dictionary)

Zusätzliche Parameter, die bei der Verbindung zur Datenbank genutzt werden. Schaue in die Backend-Beschreibung für die verfügbaren Schlüsselwörter.

DATABASE_PASSWORD

Standard: '' (Leerer String)

Das Passwort, das bei der Verbindung zur Datenbank benutzt wird. Gilt nicht für SQLite.

DATABASE_PORT

Standard: '' (Leerer String)

Der Port, der bei der Verbindung zur Datenbank benutzt wird. Ein leerer String bedeutet den Standardport. Gilt nicht für SQLite.

DATABASE_USER

Standard: '' (Leerer String)

Der Benutzername, der bei der Verbindung zur Datenbank benutzt wird. Gilt nicht für SQLite.

DATE_FORMAT

Standard: 'N j, Y' (z.B. Feb. 4, 2003)

Das Standardformat, das für die Datumsfelder in Djangos Änderungsprotokoll — und möglicherweise anderen Teilen des Systems — genutzt wird. Siehe mögliche Formatierung des Datums.

Siehe auch DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT und MONTH_DAY_FORMAT.

DATETIME_FORMAT

Standard: 'N j, Y, P' (z.B. Feb. 4, 2003, 4 p.m.)

Das Standardformat, das für die Datumsfelder in Djangos Änderungsprotokoll — und möglicherweise anderen Teilen des Systems — genutzt wird. Siehe mögliche Formatierung des Datums.

Siehe auch DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT und MONTH_DAY_FORMAT.

DEBUG

Standard: False

Ein boolscher Wert, der den Debug-Modus an- oder ausschaltet.

Wenn du eigene Einstellungen definierst, findet sich in django/views/debug.py ein regulärer Ausdruck HIDDEN_SETTINGS welcher einige sensible Informationen ('SECRET', 'PASSWORD' oder 'PROFANITIES') im DEBUG-View versteckt. Dies erlaubt es, auch nicht vertrauenswürdigen Benutzern einen Backtrace zu zeigen, ohne solch sensible (oder für potenzielle Angreifer nützliche) Einstellungen offen legen zu müssen.

Beachte aber, dass es in der Debug-Ausgabe immernoch Werte gibt, die nicht für die Öffentlichkeit bestimmt sind. Pfade, Konfigurationsoptionen und andere Werte verhelfen Hackern zu zusätzlichen Informationen über deinen Server. Du solltest niemals deine Seite mit DEBUG = True öffentlich in Betrieb nehmen!

DEFAULT_CHARSET

Standard: 'utf-8'

Die standardmäßige Zeichenkodierung für alle HttpResponse Objekte, wenn der MIME-Typ nicht manuell eingestellt ist. Es wird mit DEFAULT_CONTENT_TYPE genutzt, um den Content-Type Header zu erstellen.

DEFAULT_CONTENT_TYPE

Standard: 'text/html'

Der standardmäßige Content-Typ für alle HttpResponse Objekte, wenn der MIME-Typ nicht manuell eingestellt ist. Es wird mit DEFAULT_CHARSET genutzt, um den Content-Type Header zu erstellen.

DEFAULT_FROM_EMAIL

Standard: 'webmaster@localhost'

Die Standard-E-Mail-Adresse für die automatische Kommunikation mit Site-Managern.

DEFAULT_TABLESPACE

Neu in Djangos Entwicklerversion

Standard: '' (Leerer String)

Der Standard-Tablespace von Datenmodellen, die keinen eigenen eingestellt haben. Nur nutzen, wenn es das Backend unterstützt.

DEFAULT_INDEX_TABLESPACE

Neu in Djangos Entwicklerversion

Standard: '' (Leerer String)

Der Standard-Tablespace von Feld-Indices, die keinen eigenen eingestellt haben. Nur nutzen, wenn es das Backend unterstützt.

DISALLOWED_USER_AGENTS

Standard: () (Leeres Tupel)

Eine Liste kompilierter regulärer Audrücke mit User-Agents-Strings, denen der Zugriff auf die gesamte Seite untersagt ist. Die Option ist z.B. gegen böse Robots/Crawler nützlich und wird nur genutzt, wenn CommonMiddleware installiert ist (siehe Middleware Dokumentation).

EMAIL_HOST

Standard: 'localhost'

Der Hostname, der zum Versenden von E-Mails genutzt wird.

Siehe auch EMAIL_PORT.

EMAIL_HOST_PASSWORD

Standard: '' (Leerer String)

Das Passwort, das für die Verbindung zum SMTP-Server (definiert in EMAIL_HOST) genutzt wird. Diese Einstellung ist nur in Verbindung mit EMAIL_HOST_USER sinnvoll. Wenn eine dieser beiden Einstellungen nicht gesetzt ist, wird Django keine Authentifizierung bei der Verbindung zum SMTP-Server durchführen.

Siehe auch EMAIL_HOST_USER.

EMAIL_HOST_USER

Standard: '' (Leerer String)

Der Benutzername für die Verbindung zum SMTP-Server, der in EMAIL_HOST definiert ist. Wenn das Feld leer ist, wird Django keine Authentifizierung durchführen.

Siehe auch EMAIL_HOST_PASSWORD.

EMAIL_PORT

Standard: 25

Der Port für die Verbindung zum SMTP-Server, der in EMAIL_HOST definiert ist.

EMAIL_SUBJECT_PREFIX

Standard: '[Django] '

Der Präfix, der in E-Mails dem Betreff vorangestellt ist, welche über django.core.mail.mail_admins oder django.core.mail.mail_managers versendet werden. Achte auf das Leerzeichen am Ende des Strings.

EMAIL_USE_TLS

Neu in Djangos Entwicklerversion

Standard: False

Wenn auf True gesetzt, wird eine verschlüsselte TLS-Verbindung mit dem SMTP-Server genutz.

FILE_CHARSET

Neu in Djangos Entwicklerversion

Standard: 'utf-8'

Die Zeichenkodierung, die genutzt wird, um Dateien von der Festplatte zu dekodieren. Das betrifft auch Template-Dateien und die SQL-Dateien bei Inbetriebnahme (initial SQL).

FIXTURE_DIRS

Standard: () (Leeres Tupel)

Eine Liste aller Verzeichnisse, in denen sich Fixture-Files finden, in Suchreihenfolge. Beachte, dass diese Pfade immer Unix-gemäße (Vorwärts-)Schrägstriche beinhalten sollen, auch unter Windows. Siehe auch Django-Anwendungen testen.

IGNORABLE_404_ENDS

Standard: ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi', 'favicon.ico', '.php')

Siehe IGNORABLE_404_STARTS und Fehlerberichte per E-Mail.

IGNORABLE_404_STARTS

Standard: ('/cgi-bin/', '/_vti_bin', '/_vti_inf')

Ein Tupel mit URL-Anfängen, die der 404-Mailer ignorieren soll. Siehe auch SEND_BROKEN_LINK_EMAILS, IGNORABLE_404_ENDS und die Sektion Fehlerberichte per E-Mail.

INSTALLED_APPS

Standard: () (Leeres Tupel)

Ein Tupel mit Strings, das alle aktivierten Anwendungen in dieser Django-Installation enthält. Jeder String sollte ein vollständiger Python-Pfad zu einem Python-Paket mit einer Django-Anwendung sein — das üblicherweise mit django-admin.py startapp erstellt wurde.

INTERNAL_IPS

Standard: () (Leeres Tupel)

Ein Tupel mit IP-Adressen (Strings) die:

  • Debug Informationen sehen dürfen, wenn DEBUG auf True gestellt ist
  • X-Header erhalten, wenn XViewMiddleware installiert ist (siehe Middleware Dokumentation)

JING_PATH

Standard: '/usr/bin/jing'

Der Pfad zur ausführbaren “Jing”-Datei. Jing ist ein RELAX-NG-Validator, den Django nutzt, um jedes XMLField in deinen Datenmodellen zu validieren.

Siehe http://www.thaiopensource.com/relaxng/jing.html .

LANGUAGE_CODE

Standard: 'en-us'

Ein String, der den Sprachcode für diese Installtion definiert. Er sollte immer im Standard Language Format definiert sein, z.B. ist U.S. English "en-us". Siehe dazu die Dokumentation zur Internationalisierung.

LANGUAGES

Standard: Ein Tupel mit allen verfügbaren Sprachen.

Da die Liste der unterstützten Sprachen ständig wächst, wäre eine Kopie hier schnell veraltet. Die aktuelle Liste aller übersetzten Sprachen findest du in django/conf/global_settings.py (oder schau in die Online-Quellen).

Die Liste besteht aus einem Tupel, das wiederum ein oder mehrere Tupel im Format (Sprachcode, Sprachname) enthält — zum Beispiel, ('ja', 'Japanese'). Dadurch werden die verfügbaren Sprachen in der Sprachauswahl angezeigt. Weitere Details findest du in der Dokumentation zur Internationalisierung.

Normalerweise sollte der Standardwert genügen. Setze diese Option nur ein, wenn du die Sprachauswahl auf eine Teilmenge der von Django mitgelieferten Sprachen begrenzen möchtest.

Wenn du eigene Einstellungen in LANGUAGES vornimmst, ist es in Ordnung, die Sprachnamen als Translation-Strings zu definieren (wie im Beispiel oben) — aber nutze eine “Dummy” gettext() Funktion und nicht die in django.utils.translation. Du solltest niemals django.utils.translation in deiner Einstellungsdatei importieren, da dieses Modul selbst auf die Einstellungen angewiesen ist und das würde einen rekursiven Import nach sich ziehen.

Die Lösung ist, eine “dummy” gettext() Funktion zu nutzen. Hier ist ein Beispiel:

gettext = lambda s: s

LANGUAGES = (
    ('de', gettext('German')),
    ('en', gettext('English')),
)

Mit diesem “Ausweg” wird make-messages.py diese Strings immer noch finden und als übersetzbare Strings markieren. Da die Übersetzung aber nicht zur Laufzeit stattfindet, musst du dich an diese Strings erinnern und in eine echte gettext() Funktion in all dem Code einsetzen, der LANGUAGES nutzt.

LOCALE_PATHS

Standard: () (Leeres Tupel)

Ein Tupel mit Verzeichnissen, in der Django nach Übersetzungsdateien sucht. Lies dazu die Dokumentation Internationalisierung, die die Variable und das Standard-Verhalten erklärt.

LOGIN_REDIRECT_URL

Neu in Djangos Entwicklerversion

Standard: '/accounts/profile/'

Die URL, zu der die Benutzer nach dem Login weitergeleitet werden, wenn dem contrib.auth.login View kein next Parameter zugewiesen wurde.

Dies wird zum Beispiel vom @login_required Decorator genutzt.

LOGIN_URL

Neu in Djangos Entwicklerversion

Standard: '/accounts/login/'

Die URL, zu der die Benutzer für den Login weitergeleitet werden, besonders bei der Nutzung des @login_required Decorator.

LOGOUT_URL

Neu in Djangos Entwicklerversion

Standard: '/accounts/logout/'

Das Pendant zu LOGIN_URL.

MANAGERS

Standard: () (Leeres Tupel)

Ein Tupel im selben Format wie ADMINS, das definiert, wer Benachrichtigung über kaputte Links erhalten soll, wenn SEND_BROKEN_LINK_EMAILS=True ist.

MEDIA_ROOT

Standard: '' (Leerer String)

Ein absoluter Pfad zum Verzeichnis, das die Mediendaten für diese Installation enthält. Beispiel:: "/home/media/media.lawrence.com/" Siehe auch MEDIA_URL.

MEDIA_URL

Standard: '' (Leerer String)

Die URL, die die Mediendaten aus MEDIA_ROOT enthält. Beispiel:: "http://media.lawrence.com"

Bachte, dass die URL mit einem Schrägstrich enden sollte, sofern sie weitere Pfadangaben enthält.

Gut: "http://www.example.com/static/" Schlecht: "http://www.example.com/static"

MIDDLEWARE_CLASSES

Standard:

("django.contrib.sessions.middleware.SessionMiddleware",
 "django.contrib.auth.middleware.AuthenticationMiddleware",
 "django.middleware.common.CommonMiddleware",
 "django.middleware.doc.XViewMiddleware")

Ein Tupel, das die Middleware-Klassen enthält, die genutzt werden sollen. Weitere Informationen findest du in Middleware Dokumentation.

MONTH_DAY_FORMAT

Standard: 'F j'

Das Standardformat das für die Datumsfelder in Djangos Änderungsprotokoll — und möglicherweise anderen Teilen des Systems — genutzt wird, wenn nur der Monat und der Tag angezeigt werden soll. Siehe mögliche Formatierung des Datums.

Wenn z.B. Djangos Änderungsprotokoll mittels des Datums gefiltert wird, wird im Seitenkopf der Tag und der Monat angezeigt. Verschiedene Sprachen haben verschiedene Formate dieser Ordnung. Im amerikanischen Englisch sagt man z.B. “January 1” wohingegen in Spanien “1 Enero” bevorzugt wird.

Siehe mögliche Formatierung des Datums. Siehe auch DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT und YEAR_MONTH_FORMAT.

PREPEND_WWW

Standard: False

Gibt an, ob “www.” an die URL vorangestellt werden soll, falls nicht vorhanden. Diese Funktion ist nur aktiv, wenn CommonMiddleware installiert ist (Siehe Middleware Dokumentation`_). Siehe auch APPEND_SLASH.

PROFANITIES_LIST

Ein Tupel mit vulgären Ausdrücken (Strings), die einen Validation-Error auslösen, wenn der hasNoProfanities Validator aufgerufen wird.

Wir listen die Standardeinträge hier nicht auf, denn das wäre zu vulgär. Eine vollständige Liste siehst du in der Datei django/conf/global_settings.py.

ROOT_URLCONF

Standard: Nicht definiert

Ein String mit dem kompletten Python-Pfad zu deiner Basis-URL-Konfiguration (URLConf). Beispiel: "mydjangoapps.urls" Lies dazu auch: Wie Django einen Request abarbeitet.

SECRET_KEY

Standard: '' (Leerer String)

Ein geheimer Schlüssel für diese Django-Installation. Er wird in Hash-Algorithmen als Anfangswert (Seed) genutzt. Setze diese Wert auf einen zufälligen String — je länger desto besser. django-admin.py startproject erstellt diesen Wert automatisch.

SERIALIZATION_MODULES

Standard: Nicht definiert.

Ein Dictionary mit Modulen, die Serializer-Definitionen (als String) enthalten. Der Schlüsselindex ist die Identifikation für den Serializer-Typ. Um bspw. den YAML-Serializer zu definieren, nutze:

SERIALIZATION_MODULES = { ‘yaml’ : ‘path.to.yaml_serializer’ }

SERVER_EMAIL

Standard: 'root@localhost'

Die E-Mail-Adresse, die als Absenderadresse von Fehlermeldungen benutzt wird, wie die an ADMINS und MANAGERS.

SESSION_ENGINE

Neu in Djangos Entwicklerversion

Standard: django.contrib.sessions.backends.db

Gibt an, wo die Session-Daten gespeichert werden. Gültige Werte sind:

  • 'django.contrib.sessions.backends.db'
  • 'django.contrib.sessions.backends.file'
  • 'django.contrib.sessions.backends.cache'

Siehe auch Session Dokumentation.

SESSION_EXPIRE_AT_BROWSER_CLOSE

Standard: False

Gibt an, ob der Cookie verfallen soll, wenn der Benutzer den Webbrowser schließt. Siehe auch Session Dokumentation.

SESSION_FILE_PATH

Neu in Djangos Entwicklerversion

Standard: /tmp/

Wenn du ein dateibasiertes Session-Backend nutzt, setzt diese Option das Verzeichnis, in dem Django die Session-Daten speichern wird. Mehr Informationen findest du in der Session Dokumentation.

SESSION_SAVE_EVERY_REQUEST

Standard: False

Gibt an, ob die Session-Daten bei jedem Request gespeichert werden sollen. Siehe auch Session Dokumentation.

SITE_ID

Standard: Nicht definiert

Die ID der aktuellen Site (als Integer) in der django_site Datenbank-Tabelle. Die ID wird genutzt, damit sich Anwendungsdaten in spezifische Seiten einhaken können. Damit kann eine einzige Datenbank den Inhalt verschiedener Seiten verwalten.

Mehr Informationen dazu findest du in der Dokumentation des Site Frameworks.

TEMPLATE_CONTEXT_PROCESSORS

Standard:

("django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media")

Ein Tupel mit aufrufbaren Funktionen, die dazu genutzt werden, den Kontext im RequestContext zu definieren. Diese Prozessoren nehmen ein Request-Objekt als Argument und geben ein Dictionary zurück, das dem Kontext hinzugefügt wird.

TEMPLATE_DEBUG

Standard: False

Ein boolscher Wert, der den Debug-Modus an- oder ausschaltet. Wenn diese Option auf True gesetzt ist, wird eine schicke Fehlerseite mit einem detailierten Fehlerbericht für jeden TemplateSyntaxError angezeigt. Dieser Bericht enthält den relevanten Teil des Templates, in dem die dazugehörige Zeile hervorgehoben ist.

Beachte, dass Django diesen Fehlerbericht nur anzeigt, wenn DEBUG auf True gesetzt ist.

Siehe auch DEBUG.

TEMPLATE_DIRS

Standard: () (Leeres Tupel)

Eine Liste aller Verzeichnisse, die Template-Dateien enthalten, in der Reihenfolge, wie sie vom Django erkannt werden sollen. Beachte, dass diese Pfade immer Unix-gemäße (Vorwärts-)Schrägstriche beinhalten sollten, auch unter Windows.

Siehe auch Template Dokumentation.

TEMPLATE_LOADERS

Standard: ('django.template.loaders.filesystem.load_template_source',)

Ein Tupel mit aufrufbaren Funktionen (als Strings) die Templates aus verschiedenen Quellen importieren können. Mehr Informationen dazu findest du in Template Dokumentation.

TEMPLATE_STRING_IF_INVALID

Standard: '' (Leerer String)

Die Ausgabe (als String), den das Template-System bei invaliden (z.B. falsch geschriebenen) Variablen nutzen soll. Siehe auch Wie werden ungültige Variablen gehandhabt.

TEST_DATABASE_CHARSET

Neu in Djangos Entwicklerversion

Standard: None

Die Zeichenkodierung, die die Datenbank zum Erstellen der Test-Datenbank nutzt. Der Wert dieses Strings wird direkt an die Datenbank übergeben, damit ist das Format Backend-spezifisch.

Unterstützt für die PostgreSQL (postgresql, postgresql_psycopg2) und MySQL (mysql, mysql_old) Backends.

TEST_DATABASE_COLLATION

Neu in Djangos Entwicklerversion

Standard: None

Die Sortierreihenfolge (collation order), die die Datenbank zum erstellen der Test-Datenbank nutzt. Die Sortierreihenfolge wird direkt an die Datenbank übergeben, damit ist das Format Backend-spezifisch.

Derzeit werden nur die mysql und mysql_old Backends unterstützt. (Mehr Details findest du im Abschnitt 10.3.2 des MySQL Handbuchs).

TEST_DATABASE_NAME

Standard: None

Der Name der Datenbank, wenn die Test-Suite gestartet wird. Wenn der Wert None ist, wird die Datenbank den Namen 'test_' + settings.DATABASE_NAME nutzen. Siehe Django-Anwendungen testen.

TEST_RUNNER

Standard: 'django.test.simple.run_tests'

Der Name der Methode, die die Test-Suite startet. Siehe Django-Anwendungen testen.

TIME_FORMAT

Standard: 'P' (e.g. 4 p.m.)

Das Standardformat, das für die Datumsfelder in Djangos Änderungsprotokoll — und möglicherweise anderen Teilen des Systems — genutzt wird, wenn nur der Monat und der Tag angezeigt werden soll. Siehe mögliche Formatierung des Datums.

Siehe auch DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT und MONTH_DAY_FORMAT.

TIME_ZONE

Standard: 'America/Chicago'

Der String repräsentiert die Zeitzone für diese Installation. Siehe mögliche Werte. Beachte, dass du in dieser Liste mehrere Felder in einer Zeile findest, nimm aber nur die Auswahl für deine Zeitzeone. Wenn zum Beispiel in einer Zeile steht: 'Europe/London GB GB-Eire'`, dann nutze ``'Europe/London' als deine TIME_ZONE Einstellung.

Denke auch daran, dass dies die Zeitzone ist, mit der Django alle Datums-/Zeitangaben konvertiert und nicht unbedingt mit der des Servers. Wenn auf dem Server mehrere Django-Instanzen laufen, dann kann jede ihre eigene Zeitzone haben.

Im Normalfall setzt Django die Variable os.environ['TZ'] auf die Zeitzone, die du in TIME_ZONE angegeben hast. Damit arbeiten alle deine Views und Datenmodelle automatisch mit der korrekten Zeitzone. Wenn du aber die manuelle Konfiguration (siehe unten) nutzt, wird Django die Umgebungsvariable TZ nicht ändern und es liegt dann an dir, alle Prozesse in der richtigen (Zeit-)Umgebung laufen zu lassen.

Note

Django kann die Zeitzonen nicht verlässlich unter Windows verwalten. Wenn du Django unter Windows einsetzen möchtest, sollte diese Variable zu der Zeitzone des Systems passen.

URL_VALIDATOR_USER_AGENT

Standard: Django/<version> (http://www.djangoproject.com/)

Der String, der Teil des User-Agent ist, wenn die Existenz von URLs geprüft wird. (Siehe dazu die verify_exists Option bei URLField).

USE_ETAGS

Standard: False

Ein boolscher Wert der angibt, ob der “Etag” Header genutzt werden soll. Dies spart Bandbreite, verringert aber auch die Performance. Diese Funktion wird nur genutzt, wenn CommonMiddleware installiert ist (Siehe Middleware Dokumentation).

USE_I18N

Standard: True

Ein boolscher Wert der angibt, ob Djangos Internationalisierungssystem (engl. internationalization, verkürzt: i18n) genutzt werden soll. Durch Ausschalten kann sehr einfach die Performance verbessert werden. Wenn der Wert auf False steht, wird Django einige Optimierungen vornehmen und den i18n-Mechanismus nicht laden.

YEAR_MONTH_FORMAT

Standard: 'F Y'

Das Standardformat, das für die Datumsfelder in Djangos Änderungsprotokoll — und möglicherweise anderen Teilen des Systems — genutzt wird, wenn nur der Monat und das Jahr angezeigt werden soll.

Wenn z.B. Djangos Änderungsprotokoll mittels des Datums gefiltert wird, wird im Seitenkopf der Monat und das Jahr angezeigt. Verschiedene Sprachen haben verschiedene Formate dieser Ordnung. Im amerikanischen Englisch sagt man z.B. “January 2006” wohingegen in anderen Sprachen “2006/January” bevorzugt wird.

Siehe mögliche Formatierung des Datums. Siehe auch DATE_FORMAT, DATETIME_FORMAT, TIME_FORMAT und MONTH_DAY_FORMAT.

Erstelle deine eigenen Einstellungen

Nichts hält dich davon ab, eigene Einstellungen in deine Django-Applikationen aufzunehmen. Beachte nur diese Richtlinien:

  • Einstellungsnamen sind immer in Großbuchstaben zu schreiben.
  • Für Einstellungen die Sequenzen sind, benutze Tupel statt Listen, das ist gut für die Performance.
  • Erfinde keine bestehenden Einstellungen neu.

Einstellungen ohne das DJANGO_SETTINGS_MODULE nutzen

In einigen Fällen möchtest du vielleicht die Umgebugsvariable DJANGO_SETTINGS_MODULE umgehen, z.B. wenn du das Templatesystem nutzt und keine Umgebungsvariable zum Einstellungsmodul setzen möchtest.

In diesem Fall kannst du Djangos Einstellungen manuell setzen. Dies geschieht über den Aufruf von django.conf.settings.configure().

Beispiel:

from django.conf import settings

settings.configure(DEBUG=True, TEMPLATE_DEBUG=True,
    TEMPLATE_DIRS=('/home/web-apps/myapp', '/home/web-apps/base'))

Übergib an configure() so viele Schlüsselwörter wie du möchtest, jedes Schlüsselwort repräsentiert eine Einstellung und ihren Wert. Argumente sollten immer in Großbuchstaben geschrieben werden und den selben Namen besitzen, wie die oben beschriebene Einstellung. Wenn eine einzelne Einstellung nicht mittels configure() übergeben wird — aber zu einem späteren Zeitpunkt gebraucht wird — wird Django den Standardwert nehmen.

Dieses Verhalten ist wichtig — und auch empfohlen — wenn du ein Stück eines Frameworks in einer größeren Anwendung nutzen willst.

Wenn Einstellungen konsequent mit settings.configure() konfiguriert werden, wird Django keine Änderungen an den Prozess-Umgebungsvariablen machen. (Siehe dazu auch die Erklärung von TIME_ZONE, wo dies normalerweise geschieht.) Es wird angenommen, dass du in diesem Fall die volle Kontrolle über die Umgebungsvariablen hast.

Eigene Default-Einstellungen

Wenn du mit eigenen Standard-Einstellungen arbeitest, die nicht in django.conf.global_settings definiert sind, kannst du diese dem Aufruf von configure() als Argument default_settings (oder als erste Argument-Position) zuweisen.

In diesem Beispiel werden die Standard-Einstellungen von myapp_defaults gesetzt, danach der Wert DEBUG auf True, unabhängig davon, was in myapp_defaults gesetzt ist:

from django.conf import settings
from myapp import myapp_defaults

settings.configure(default_settings=myapp_defaults, DEBUG=True)

Das folgende Beispiel (myapp_defaults wird als erstes Argument gesetzt) ist identisch.

settings.configure(myapp_defaults, DEBUG = True)

Normalerweise brauchst du Standardeinstellungen nicht in dieser Weise zu überschreiben. Die Django-Standards sind ausreichend sinnvoll, um sie sicher zu nutzen. Denke aber daran: Wenn du neue Standard-Einstellungen dem Standard-Modul übergibst, werden die Django-Standardeinstellungen komplett überschrieben. Damit musst du einen Standardwert für jede mögliche Einstellung setzen, der in deinem Code genutzt wird. Schaue in die Datei django.conf.settings.global_settings für eine vollständige Liste.

Entweder configure() oder das DJANGO_SETTINGS_MODULE wird benötigt

Wenn du die Umgebungsvariable DJANGO_SETTINGS_MODULE nicht setzt, musst du configure() aufrufen, bevor Code ausgeführt wird, der Einstellungen benötigt.

Wenn du DJANGO_SETTINGS_MODULE nicht setzt und auch nicht configure() aufrufst, wird Django einen ImportError auslösen, sobald eine Einstellung das erste mal aufgerufen wird.

Wenn du DJANGO_SETTINGS_MODULE gesetzt hast, auf die Einstellungen zugreifst und dann configure() aufrufst, wird Django einen RuntimeError auslösen und zeigen, das die Einstellungen bereits konfiguriert wurden.

Genauso fehlerhaft ist es, configure() mehr als ein mal aufzurufen oder configure() aufzurufen, wenn bereits auf eine Einstellung zugegriffen wurde.

Es reduziert sich damit auf folgendes: Benutze genau eins von configure() oder DJANGO_SETTINGS_MODULE, aber nicht beide zusammen, und auch nicht keins von beiden.

Fehlerberichte per E-Mail

Server Fehler

Wenn DEBUG auf False gesetzt ist, wird Django allen Benutzern die in ADMIN gelistet sind eine E-Mail senden, wenn dein Code eine unbehandelte Exception (Ausnahme) und einen Internal Server Error (HTTP Status Code 500) auslöst. Damit erhalten Administratoren über alle Fehler sofort eine Nachricht.

Entferne alle Einträge aus ADMINS um dieses Verhalten zu umgehen.

404 Fehler

Django wird eine Hinweis-E-Mail an alle Benutzer die in MANAGERS gelistet sind wenn:

  • DEBUG auf False gesetzt ist
  • SEND_BROKEN_LINK_EMAILS auf True gesetzt ist
  • in MIDDLEWARE_CLASSES die CommonMiddleware gelistet ist
  • dein Code einen 404-Fehler auslöst
  • der Request einen Referer mitsendet

Es wird keine E-Mail gesendet, wenn der Request keinen Referer mitsendet.

Du kannst Django mit Hilfe der Optionen IGNORABLE_404_ENDS und IGNORABLE_404_STARTS so einstellen, dass nicht in allen Fällen eine 404-Hinweis-E-Mail gesendet wird. Beide Werte sollten eine Tuple mit String sein. Beispiel:

IGNORABLE_404_ENDS = ('.php', '.cgi')
IGNORABLE_404_STARTS = ('/phpmyadmin/',)

Bei diesem Beispiel werden URLs, die mit .php oder .cgi enden, keinen Fehlerbericht auslösen. Genauso URLs die mit /phpmyadmin/ beginnen.

Um diesese Verhalten auszuschalten, entferne alle Einträge aus der Einstellung MANAGERS.

Informationen

Schnellzugriff