Why does the order of INSTALLED_APPS matter in Django when two apps provide a template, static file or management command with the same name?

## The rule Django's settings reference is explicit: "When several applications provide different versions of the same resource (template, static file, management command, translation), the application listed first in `INSTALLED_APPS` has precedence." In other words, the search walks the apps **top to bottom and stops at the first match**. ## Where the rule shows up | Resource | Who searches the apps | Consequence of order | |---|---|---| | templates | the app-directories template loader | the first app with `templates/<name>` supplies it | | static files | the app-directories static finder used by `collectstatic` | the first app with `static/<path>` is copied | | management commands | `get_commands()` | the first app defining `<name>.py` in `management/commands/` wins | | translations | the translation machinery | catalogs from earlier apps take precedence | | `ready()` and loading | the app registry | apps load and run `ready()` in list order | ## The classic example: overriding the admin On a clinic-booking site you want the admin header to say "Clinic Admin". You add a `branding` app with `branding/templates/admin/base_site.html`. The template reference spells out the trap: your app "must come *before* `django.contrib.admin`" or "`django.contrib.admin`'s will be loaded first and yours will be ignored". ```python INSTALLED_APPS = [ "branding", # listed first: its admin/base_site.html wins "django.contrib.admin", "django.contrib.auth", "django.contrib.contenttypes", "django.contrib.sessions", "django.contrib.messages", "django.contrib.staticfiles", "scheduling", "patients", ] ``` ## The qualifier: project directories come first App order only decides between **apps**. With the default configuration: - the filesystem template loader (reading `TEMPLATES['DIRS']`) is tried **before** the app-directories loader, so a template in a project-level `templates/` directory beats every app; - `STATICFILES_FINDERS` lists the filesystem finder (reading `STATICFILES_DIRS`) **before** the app-directories finder. That is why many teams put site-wide overrides in a project `templates/` directory instead of relying on app order. ## Why this bites in practice 1. **Silent shadowing.** Two apps each ship `templates/base.html`; one wins and the other's pages look wrong with no error. Namespacing templates as `templates/<app_label>/...` avoids accidental collisions. 2. **Third-party overrides.** A package that restyles the admin must be listed above `django.contrib.admin`, and its install docs usually say so. 3. **Command clashes.** Two apps defining `import_data` means only the earlier one's command is reachable by that name. 4. **Static collisions.** `collectstatic` keeps the first file found for a path; `findstatic <path>` lists every candidate location to show which one won. ## A debugging walk-through Suppose the clinic's admin still shows the stock "Django administration" header after you add the override: 1. Confirm the file path is exactly `branding/templates/admin/base_site.html` and that `APP_DIRS` is enabled, so app template directories are searched at all. 2. Check `INSTALLED_APPS`: `"branding"` must appear above `"django.contrib.admin"`. 3. Check `TEMPLATES['DIRS']`: a project-level `admin/base_site.html` there would beat both apps. 4. Restart the development server if the cached template loader kept an old lookup. For static files the equivalent check is `findstatic`, which prints every candidate location in search order. For commands, `python manage.py help` lists commands grouped by the app that provides them, which shows which app's version is live. ## What an interviewer is listening for A middle candidate states "first listed wins" and gives the admin-template example. A stronger one adds that project `DIRS` and `STATICFILES_DIRS` beat all apps by default, recommends namespacing to avoid accidental shadowing, and knows `findstatic` for debugging which file won.