Projects & Settings

runserver is a convenience server built on Python's wsgiref that Django never security-audited or performance-tested. Production serves the same WSGI or ASGI application object from wsgi.py or asgi.py through a dedicated application server.

DEBUG=True shows detailed tracebacks with settings and local variables, records every SQL query per connection, and trusts localhost when ALLOWED_HOSTS is empty. With DEBUG=False you must set ALLOWED_HOSTS, or every request returns 400 Bad Request.

Django's model is the data layer, its view is the Python callable that decides which data a URL returns, and its template decides how that data looks. The framework itself, routing requests through the URLconf, plays MVC's controller.

AppConfig.ready() runs after every installed app's models are loaded, so it suits startup wiring such as importing signal receivers. Avoid database queries there: ready() runs on every management command and can run more than once in tests.

Write a function taking app_configs plus keyword arguments that returns a list of django.core.checks messages, such as Error(..., id="shipping.E001"), when the setting is missing; decorate it with @register and import its module from AppConfig.ready() so it registers.

check --deploy adds checks registered with deploy=True, mostly security.* warnings such as W004, W018 and W020. They are warnings, so the default exit status stays 0; run it with production settings and --fail-level WARNING to fail CI.

Create shop/management/commands/expire_coupons.py defining Command(BaseCommand): declare options in add_arguments(parser), do the work in handle() using the parsed options, write through self.stdout with self.style, and raise CommandError on failure.

Django loads the settings module named by the DJANGO_SETTINGS_MODULE environment variable, or a command's --settings option. Per-environment setups use a shared base module with small dev, staging and prod modules, or one module reading environment variables, with secrets always from the environment.

WSGIHandler builds an HttpRequest and passes it down the MIDDLEWARE chain; innermost, the resolver matches the path against ROOT_URLCONF and the view returns an HttpResponse, which travels back up the middleware in reverse order.

An API deprecated in release A.x keeps working with a RemovedInDjangoXYWarning and is removed in B.0, or B.1 if deprecated in the X.2 LTS, so shims last two feature releases. Surface them with python -Wa manage.py test.

Move Python into the range both support (3.10-3.12), take the latest 4.2 patch, fix every Django deprecation warning under python -Wa, upgrade dependencies, then step 5.0, 5.1, 5.2 on their latest patches, running the full suite at each step.

Django's system check framework (django.core.checks) is a registry of static validations over models, settings, URLs and templates. Besides manage.py check, it runs before most management commands, including runserver and migrate, but never inside the deployed request path.

Both run the same command machinery. manage.py is generated per project and sets DJANGO_SETTINGS_MODULE to that project's settings; django-admin is installed with Django and needs settings supplied, so it suits startproject and switching settings.

models.py holds models, views.py view callables, urls.py URL patterns, admin.py admin registrations, apps.py the AppConfig, tests.py tests. Django finds models, apps, admin and test*.py modules by name; views and urls run only when referenced.

Django ships a feature release (A.B) roughly every eight months and patch releases (A.B.C) as needed. Since 2.0, each X.2 release, such as 4.2 and 5.2, is long-term support: security and data-loss fixes for typically three years.

When several installed apps provide the same template, static file, management command or translation, the app listed first in INSTALLED_APPS takes precedence. To override django.contrib.admin's template from your own app, your app must come before the admin in the list.

Messages carry a level (Debug to Critical); Error and Critical stop management commands, lower levels are printed. Ids follow applabel.X001, where X marks the level. SILENCED_SYSTEM_CHECKS lists ids whose messages are hidden and excluded from the pass/fail decision.

call_command("expire_coupons", dry_run=True, stdout=buf) runs a command in-process. Keyword options bypass argparse and map to dest names, system checks are skipped by default, and CommandError propagates as an exception instead of exiting.

django.conf.settings is a LazySettings proxy: importing it loads nothing, and the first attribute access imports the module named by DJANGO_SETTINGS_MODULE. settings.configure() supplies settings in code instead, for standalone use of Django components; call it once, before any setting is read.

Django 6.0 and 6.1 support only Python 3.12, 3.13 and 3.14; 5.2 is the last series supporting 3.10 and 3.11. Upgrade the interpreter to 3.12 or newer while still on 5.2, which supports it, then upgrade Django.

AppRegistryNotReady means code needed the app registry before django.setup() finished: models imported from an app's init.py or apps.py, a script that skipped django.setup(), or non-lazy gettext at import time. Defer the import or call setup first.

An untagged check runs before nearly every command, so its query fails wherever no database or table exists, and migrate runs checks before migrating. Keep data invariants out of checks; tag real database checks with Tags.database and use only the aliases passed in.

Catching every exception lets handle() return normally, so the process exits 0 and cron sees success. Raise CommandError or let exceptions propagate for a non-zero status, and make the work idempotent so a re-run finishes what a partial run left.

A module-level TAX_RATE = settings.PAYROLL_TAX_RATE or a default argument freezes the value when the module is imported: test overrides cannot reach it, and importing the module before settings exist fails. Read settings inside functions at call time instead.

Settings, the app registry, the handler with its middleware instances and the cached URL resolver are built once per process. Request state stored on middleware instances, or values computed at import time, therefore leaks between requests or goes stale.

Draw Django app boundaries around cohesive domain areas whose models change together, keep cross-app dependencies one-directional, and decide early because labels and migrations make moving models costly. Make an app reusable only when a second project needs it.

A trade-off: LTS-to-LTS means upgrading about every two years with three releases of change per jump; tracking feature releases means small steps every eight months and short support windows. A common middle path deploys the LTS and tests newer releases in CI.

shell opens a Python interpreter with Django configured, so you use the ORM; dbshell launches the database's own SQL client with DATABASES credentials. Since 5.2 shell auto-imports every installed app's models, and since 6.0 also settings, connection and timezone.

AppConfig.name is the app's full dotted Python path; AppConfig.label is its short identifier, defaulting to the last path component. The label is baked into default table names, migrations, content types and permissions, so changing it later breaks databases.