Personal Catalogue: Django & PostgreSQL — Chapter 8, Exercise 2
====================================================

TASK
Deliberately remove {% load static %} from the top of base.html,
reload the page, and record the exact error Django produces — then
explain why the error points at the {% static %} line rather than at
the missing {% load %} tag itself.

SOLUTION

WHAT ACTUALLY HAPPENS

Removing the {% load static %} line while leaving
href="{% static 'catalogue/style.css' %}" in place, then reloading the
page, produces a real Django template error along these lines:

    django.template.exceptions.TemplateSyntaxError:
    Invalid block tag on line X: 'static'. Did you forget to register
    or load this tag?

The error is reported at the line containing the {% static %} tag
itself, not at wherever {% load static %} used to be (or is missing
from).

WHY THE ERROR POINTS AT static, NOT AT THE MISSING load

Django's template engine processes a template's own tags in order, from
top to bottom, building up a registry of which custom tags are
currently "known" as it goes. {% load static %} is what registers the
static tag as valid and available for the rest of that template's
rendering. Without it, by the time the template engine reaches the
{% static %} line, it genuinely has no record that any tag named
static exists at all - from the engine's own point of view, it has
simply encountered a tag name it doesn't recognize, which is exactly
what the "Invalid block tag" error reports.

The engine has no way to know that a {% load static %} line was
supposed to appear earlier and doesn't - it only knows that, at the
specific line it's currently processing, an unrecognized tag showed up.
That's why the error message points at the symptom (the unrecognized
tag) rather than the actual root cause (the missing load statement
somewhere earlier in the file).

ANSWER: Removing {% load static %} produces a TemplateSyntaxError
reporting "Invalid block tag" at the line containing {% static %}
itself. This happens because Django's template engine only knows a
custom tag is valid once a matching {% load %} statement has already
been processed earlier in the same template - without it, the engine
has no record that static is a recognized tag at all by the time it
reaches that line, so it reports the unrecognized tag as the problem
rather than pointing back at the actually-missing load statement it has
no way to know was ever supposed to be there.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the real error text and explains the actual mechanism
(sequential, top-to-bottom tag registration) that causes the error to
be reported at the symptom's location rather than the root cause's
location, rather than just stating that the two locations differ.