ranger
9df37a35e8
v3.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.).