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

TASK
Add enough real items tagged "Python" to force pagination onto a
second page, then reproduce the real bug this chapter describes by
clicking "next page" before applying the fix — confirm the filter is
genuinely lost — then apply the fix and confirm it's preserved.

SOLUTION

1. Since paginate_by = 25, add at least 26 real Item rows all tagged
   "Python" (through the admin, Chapter 3, or the add form, Chapter 5 -
   whichever is faster for adding this many test items).

2. Visit /?tag=python. Confirm the list shows only Python-tagged items,
   and that a "Next" pagination link is now visible since more than 25
   results exist.

3. REPRODUCING THE BUG (before the fix): if the "Next" link is still
   rendered using Django's own default pagination markup (just
   ?page=2, with no tag parameter appended), clicking it navigates to
   /?page=2. Note what actually displays: the second page of the
   FULL, UNFILTERED item list (including CDs, DVDs, and any other
   items added in earlier chapters), not page 2 of the Python-only
   results - the active_tag filter has been silently dropped, exactly
   as the chapter describes. The "Filtered by: #Python" banner also
   disappears, since active_tag comes from the same now-missing query
   parameter.

4. APPLYING THE FIX: replace the "Next" link with the version that
   explicitly carries the tag forward:

    {% if page_obj.has_next %}
      <a href="?page={{ page_obj.next_page_number }}{% if active_tag %}&tag={{ active_tag }}{% endif %}">Next</a>
    {% endif %}

   (and the equivalent for "Previous", using page_obj.previous_page_number)

5. CONFIRMING THE FIX: reload /?tag=python and click the corrected
   "Next" link. The URL should now read /?page=2&tag=python, and the
   page should display page 2 of the Python-filtered results only,
   with the "Filtered by: #Python" banner still visible.

WHY THIS WORKS AS AN ANSWER
----------------------------
It reproduces the exact real bug described in the chapter with a
concrete before/after comparison against real data large enough to
require pagination, rather than only reading the fix without actually
observing the failure it corrects.