-
fix: Restore actually works now — handler was checking wrong $_POST key (v3.4.2)
ranger released this
2026-05-26 08:10:57 +00:00 | 0 commits to main since this releasev3.4.1 added a redirect to the Restore handler thinking that was
the missing piece. It wasn't — the entire if-block was dead code.The per-row Restore form in inc/wp-notes-display.php sends a
hidden $_POST['note_id'] (singular) when clicked. The handler in
wp_notes_page_callback() was checking for $_POST['done_ids']
(plural), an array of IDs from bulk-action checkboxes that were
removed back in v3.1.0. The mismatch meant the handler's
isset($_POST['done_ids']) guard was always false → handler body
never ran → clicking Restore was a no-op all the way back to
v3.1.0.Pre-v3.4.0 this was masked because the page re-rendered with
both Active and Completed sections visible, so users might assume
they'd misclicked. v3.4.0's single-pane tab render made the
no-op symptom unmissable; v3.4.1's redirect was a phantom fix
because it lived inside the unreachable block.Fix: rewrite the handler to match the working single-note
mark-done handler pattern that lives directly above it —
isset(note_id), absint, isset($done_notes[$note_id]) lookup,
move with restored_by annotation, redirect to Active tab. Adds
a load-bearing comment recording the bug history so future-
Claude doesn't reintroduce the dead-code structure.Lesson recorded in the changelog: when a handler appears to
"do nothing", verify the $_POST keys match BEFORE assuming the
issue is downstream (missing redirect, failed update, etc.).Downloads