The fixture distinguishes a missing relative name from a broken first match. home.html is absent, notebook/home.html selects the primary source, and reversed root order selects the fallback. The local explorer computes those authored cases without claiming that Django searched a real filesystem.
Work through the example
Change the requested name to notebook/home.html and Inspect lookup to see Primary notebook. Select Reverse roots to make Fallback notebook the first match. Select Broken primary, which restores primary-first order with an unknown tag: the expected native outcome becomes TemplateSyntaxError, not silent fallback. Requesting home.html remains a missing-source case.
Run isolated native cases rather than changing several settings at once. Use a fresh Engine to reverse root order, and keep unknown-tag syntax separate from missing files. A found broken source needs a content repair. Record the actual selected origin or exception class and message; capture tried or chain only if the exception really supplies them, and sanitize full paths in public explanations.
Separate a name mismatch from a content problem
Django's template configuration searches DIRS in order. Its loading API distinguishes TemplateDoesNotExist, when no source is found, from TemplateSyntaxError, when a found source is invalid. Optional missing-template metadata includes tried and chain; capture those only when actually supplied. Django 5.2 template usage.
This article selects Django 5.2 as the reference version. Your installed version is a separate fact to record, not something established by reading that documentation.
Use this fixture, with both template roots resolved against the project directory you record:
demo/
templates-primary/
notebook/
home.html contents: Primary notebook
templates-fallback/
notebook/
home.html contents: Fallback notebook
Neither root contains a top-level home.html. Both contain notebook/home.html, with different markers so that a successful lookup identifies which source won.
Specify a direct native Engine using dirs in primary-then-fallback order, app_dirs=False, and the explicit loader django.template.loaders.filesystem.Loader. Do not rely on an implicit cached loader or installed-app search for this probe. In a project's backend configuration, the corresponding roots are listed in DIRS; the standalone Engine argument is lowercase dirs.
The filesystem loader uses configured roots and returns the first matching source. A loaded template's origin identifies its source; filesystem origins include the full path. Django loader and origin reference.
Predict the lookup, then record what actually happens
| Isolated case | Requested name | Expected result |
|---|---|---|
| Original root order | home.html |
TemplateDoesNotExist |
| Original root order | notebook/home.html |
Primary source; marker Primary notebook |
| Fresh Engine, reversed roots | notebook/home.html |
Fallback source; marker Fallback notebook |
| Fresh fixture with both matching sources absent | notebook/home.html |
TemplateDoesNotExist |
| First matching source has an unknown tag | notebook/home.html |
TemplateSyntaxError |
For the first case, the requested relative name would correspond to a top-level file in each root. The loader does not recursively guess that you meant the notebook subdirectory. Requesting notebook/home.html supplies that missing part of the name.
For the successful primary lookup, record the actual selected origin alongside the marker. The marker alone is a useful clue; the origin is the evidence of which file was selected. Keep the full path in the private diagnostic record. A public explanation can use sanitized fixture-relative labels.
Reverse the roots in a fresh Engine for the third case. That isolates the order change instead of assuming an existing engine's state or cache has been reset. The fallback marker is expected because that source is now searched first.
Record the Django result beside each expectation, including any difference.
A broken first match is not a missing template
In a separate fixture copy, replace the primary source with the original invalid tag {% demo_unknown_tag %}. Keep the fallback file valid, and use a fresh Engine whose template libraries do not register that tag.
Recreate this example
Build one self-contained responsive HTML example titled “Django home.html: inspect the relative lookup name” for readers completing the stated task. Return the complete HTML with embedded CSS and JavaScript. Use no remote fonts, libraries, images, requests, account connections, or saved-state claims.
Use sanitized roots demo/templates-primary and demo/templates-fallback. Each has notebook/home.html, markers Primary notebook/Fallback notebook; neither has top-level home.html. Requested name input defaults home.html. Inspect lookup computes authored expectation. Reverse roots switches first match to fallback. Broken primary restores primary-first with unknown demo_unknown_tag and expected TemplateSyntaxError. Unknown names expected TemplateDoesNotExist; blank input error. Show root order, selected relative origin or absence, and exact expectation label. Include direct Engine recipe with dirs, app_dirs=False and explicit filesystem.Loader; no real filesystem/Django claim.
Use a template lookup explorer with ordered root list and sanitized source outcome design with a compact header. Keep the actual sample data, controls, and useful default result visible early on a 360px-wide screen. Use readable text at least 16px, generous paragraph spacing, strong contrast, semantic labels, visible keyboard focus, and wrapping source blocks. Stack records on narrow screens rather than forcing a wide table.
Wire each action to an explicit type=button click handler using element selectors; the host permits scripts but blocks form submission. Update the visible result when the described action occurs. Show specific error feedback for invalid or missing input and clear stale feedback after dependent inputs change. Use plain text when displaying user values.
This fixture explorer computes expected lookup cases; it does not execute Django or inspect actual project paths. Keep the source fixture and worked teacher or developer example distinct from actual user records. Include the domain-specific explanation and next check beside the result. Provide no fake download, send, deployment, approval, or persistence button. Everything operates locally for the current page session.
Review the prepared copy in NOS
Use the expected case to choose the next native diagnostic: name, root order or selected-source syntax. A sanitized HTML comparison in NOS can hold those explanations for review, and eligible static notes can be edited visually. Keep actual Engine results and full paths in the private development record.