Personal Catalogue: PHP & MySQL — Chapter 4, Exercise 3
====================================================

TASK
Add the release_year sanity check from this chapter to
add_item.php's own validation, then confirm submitting a year of
29026 is correctly rejected with an error message, while 2027 (next
year) is correctly accepted.

SOLUTION

Inside the POST branch of add_item.php, after the existing title/type
checks and before the `if (empty($errors))` block that runs the
INSERT, add:

    if ($releaseYear !== '') {
        $year = (int) $releaseYear;
        $currentYear = (int) date('Y');

        if ($year < 1400 || $year > $currentYear + 1) {
            $errors[] = "Release year looks wrong: {$releaseYear}.";
        }
    }

Testing with 29026 (assuming today's real year is 2026): submitting
the form with Title "Test Book", type "book", and Release year 29026
should redisplay the form with the error "Release year looks wrong:
29026." shown at the top, and the item should NOT appear in the
database — confirm with:

    SELECT * FROM items WHERE title = 'Test Book';

Expected: 0 rows.

Testing with 2027 (next year, a valid pre-order-style release year):
submitting the same form with Release year 2027 should succeed with no
error, redirecting to add_item.php?added=1 with "Item added." shown.
Confirm with:

    SELECT title, release_year FROM items WHERE title = 'Test Book';

Expected output:

    +------------+---------------+
    | title      | release_year  |
    +------------+---------------+
    | Test Book  |          2027 |
    +------------+---------------+

WHY THIS WORKS AS AN ANSWER
----------------------------
It tests both sides of the boundary the chapter's own check is meant
to draw — a clearly-wrong typo (29026) that must be rejected, and a
clearly-legitimate near-future year (2027, covered by the deliberate
"+ 1" in the check) that must still be accepted — rather than only
confirming the invalid case fails.