Week 078 — Item Page Partials

The solution to the panel visibility problem was to stop trying to fix it and instead redesign the approach.

Week of May 18, 2026

Progress

The panel visibility bugs from last week led to a design decision: instead of one large item.php with conditional show/hide logic for every state, the item page is restructured around PHP partials — one per state. Each partial renders the relevant fields and UI for that state only.

This solves the visibility problem cleanly: the safe partial doesn't include lost or found fields, so there's nothing to hide. State transitions reload or swap the appropriate partial rather than toggling field visibility with JavaScript.

A secondary benefit: this design naturally handles the case where an item is reported found without ever having been marked lost — a use case that was awkward in the old design.

The segment button partial (the state selector buttons) was mostly complete by Saturday. The remaining work: implement the state detail panel partials and figure out how to handle unsaved field data when a user changes their state selection and then changes it back.

The Question That Appeared

When a user selects a new state and then reverts their selection, what should happen to any data they entered? Option 1: clear the fields when reverting. Option 2: only collect the relevant data based on current state at save time, ignoring fields from states the user didn't end up selecting. Both are defensible; the choice wasn't finalized yet.

Next Week

State detail panel partials. Migrate JS logic to the partial files.