Exercise 2: Why the Catch-All Must Be Listed Last — Possible Solution ==================================================================== WHY ORDER MATTERS ------------------------------ Per this chapter, Django matches urlpatterns in declaration order and stops at the very first match it finds - it never checks any later patterns once an earlier one matches, even if a later pattern would have been a "better" or more specific match. WHAT WOULD BREAK IF THE CATCH-ALL CAME FIRST ------------------------------ Per this chapter's own concrete example, if path('/', ...) were listed before path('admin/', ...), a request for /admin/ would never reach the real admin route at all. The path converter would greedily match the string "admin" as a perfectly valid value for full_path, since path matches essentially anything including a single segment with no slashes in it - Django would then call page_detail looking for a Page row with full_path="admin", which was never meant to exist, rather than ever reaching the actual Django admin interface. The admin site would become completely unreachable, replaced by a 404 (no matching Page) instead of the admin login screen. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly explains that Django stops at the first matching pattern regardless of what comes later, and gives a concrete, specific example (the admin route becoming unreachable, intercepted by the catch-all instead) of what would actually break if the ordering were wrong.