Files
ranger 9df37a35e8 fix: Restore actually works now — handler was checking wrong $_POST key (v3.4.2)
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.).
2026-05-26 09:10:57 +01:00

727 lines
37 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Changelog
All notable changes to **Logbook** (formerly **A-WP-Notes** through v3.1.0, then **WP Logbook** in v3.2.0v3.3.0) are documented here.
Format: [Keep a Changelog 1.1.0](https://keepachangelog.com/en/1.1.0/) — versioning: [SemVer](https://semver.org/).
---
## [Unreleased]
---
## [3.4.2] — 2026-05-27
### Fixed — Restore actually works now (v3.4.1 was incomplete)
David retested after v3.4.1 and reported the same symptom: *"the restore still not working."*
Root cause (the real one): the per-row Restore form in `inc/wp-notes-display.php` sends a hidden `$_POST['note_id']` (singular) when the button is clicked — but the handler in `wp_notes_page_callback()` was checking for `$_POST['done_ids']` (plural), an array of IDs that used to come from bulk-action checkboxes **removed in v3.1.0**. So the handler's `isset($_POST['done_ids'])` guard was always false, the handler body never ran, and clicking Restore was a no-op all the way back to v3.1.0. The bug was masked before v3.4.0 because the page re-rendered with both Active and Completed sections visible, so the user could see the (unchanged) completed note still sitting there and assume they'd misclicked. v3.4.0's single-pane render made the no-op symptom unmissable.
The v3.4.1 redirect added inside the handler was syntactically correct but never reached — the entire `if` block was dead code.
Fix: rewrite the handler to match the working **single-note** mark-done handler pattern that lives just above it:
- Check `isset($_POST['note_id'])` (singular) instead of `done_ids` (plural array)
- `absint()` the ID for sanitization
- `isset($done_notes[$note_id])` lookup instead of iterating with `in_array()`
- Move the note across with the existing `restored_by` annotation
- Keep the redirect-to-Active-tab from v3.4.1
The handler now mirrors the pattern of the mark-done handler that's been working all along.
### Why this took two attempts to fix
v3.4.1's diagnosis stopped at the missing redirect — which was real but not load-bearing because the handler body was unreachable. Lesson recorded: when a handler appears to "do nothing", verify it's being entered at all (matching `$_POST` keys) before assuming the issue is downstream (missing redirect, failed update, etc.).
### Files changed
- `wp-notes.php` — Restore handler rewritten (lines around 1340). The change replaces the old bulk-checkbox-era handler with a single-note handler matching the live form. Adds a load-bearing comment block recording the v3.4.1/v3.4.2 bug history so future-Claude understands why the structure mirrors mark-done.
- Plugin header `Version: 3.4.1 → 3.4.2`; `WP_NOTES_VERSION` constant updated to match. PATCH bump (bug fix).
### Not changed
- The display code in `inc/wp-notes-display.php` — the form was already correct; the handler was the one out of sync.
- The Active and Completed tabs, storage model, CSS, other handlers — all unchanged.
---
## [3.4.1] — 2026-05-27
### Fixed — Restore button now sends you to the Active tab where the restored note lives
After v3.4.0 introduced the Active/Completed tab strip, clicking **Restore** on a completed note appeared to "do something" but the restored note never showed up. David reported it as *"the complete log does not return to active."*
Root cause: the Restore action handler in `wp_notes_page_callback()` (line ~1340) was the **only** action handler in the file without a `wp_redirect() + exit;` after its `update_option()` calls — every other handler (new note, mark-as-done single, mark-as-done bulk) had one. So Restore was relying on the page falling through and re-rendering, which used to work when both Active and Completed sections rendered on the same page (the user could just glance up to see the restored note in the Active section). v3.4.0's single-pane tab render exposed the latent bug: after Restore, the URL still said `?tab=completed`, so only Completed re-rendered (minus the now-restored note), and the restored note was invisible on Active.
Fix: add the missing redirect to `admin.php?page=wp-notes` (which defaults to the Active tab) after the restore completes. The restored note now appears in its new home immediately.
### Files changed
- `wp-notes.php``wp_notes_page_callback()` Restore handler: added `wp_redirect(admin_url('admin.php?page=wp-notes')); exit;` after the two `update_option()` calls. Five-line change plus a load-bearing comment explaining the bug history so future-Claude doesn't reintroduce it.
- Plugin header `Version: 3.4.0 → 3.4.1`; `WP_NOTES_VERSION` constant updated to match. PATCH bump (bug fix, no API or behavioural changes beyond the fix itself).
### Not changed
- The other three action handlers (new note, mark-as-done) — they already had correct redirects; no need to touch.
- Storage model, tab structure, CSS — all unchanged from v3.4.0.
---
## [3.4.0] — 2026-05-27
### Added — Active / Completed tabs on the My Log page
The main Logbook page used to render two stacked sections — Active notes from `wp_notes` above, Completed notes from `wp_done_notes` below. As the lists grew, this became a "wall of stacked sections" with Completed pushing content off the visible fold and users having to scroll past it to scan their active work.
v3.4.0 replaces the stacked layout with a **single-pane tabbed view** using WordPress's native `subsubsub` filter-tab pattern (the same one Posts / Comments / Plugins admin pages use):
- **Two tabs**: `Active (N)` and `Completed (M)`. Counts in the labels match the actual list lengths.
- **URL-driven state**: `?page=wp-notes&tab=active` (default) and `?page=wp-notes&tab=completed`. Bookmarkable, refresh-stable, back-button works. Invalid tab values fall back to Active server-side.
- **No JavaScript**: each tab is a hyperlink. WP-admin core CSS handles the `.subsubsub` and `.current` styling; we just add a small top/bottom margin block.
- **Single-pane render**: only the selected tab's section is in the DOM, so no flash-of-wrong-content and no wasted markup.
- **"Add a Note" form stays visible on both tabs** — even from Completed you can think of something new to log.
This was flagged in the 2026-05-25 UX audit as the highest-payoff next move (Tier 3 item #7). When the v4 roadmap's timer / `time_logged` field ships, the tab structure can extend naturally to three tabs (TODO / IN PROGRESS / Completed) in the same place; for now, without that field, an IN PROGRESS tab would always be empty, so v3.4.0 ships the 2-tab version that matches the current data model.
### Files changed
- `wp-notes.php``wp_notes_page_callback()`: tab detection from `$_GET['tab']` (sanitized + whitelisted), `subsubsub` markup with link-builder via `add_query_arg`, single-pane conditional render of either the active or completed section. Replaces the previous two-stacked-section block.
- `inc/wp-notes-styles.php` — minor spacing (`margin: 12px 0 18px`) on `.subsubsub` so the tab strip has breathing room.
- Plugin header `Version: 3.3.5 → 3.4.0`; `WP_NOTES_VERSION` constant updated to match. MINOR bump (new feature, no breaking changes).
### Not changed
- Storage model — Active and Completed remain in their separate options (`wp_notes`, `wp_done_notes`).
- The `wp_notes_display_notes($type)` function in `inc/wp-notes-display.php` — already accepts the section type, no signature change needed.
- No new DB writes, schema changes, AJAX endpoints, or dependencies.
---
## [3.3.5] — 2026-05-25
### Changed — Admin-menu icon
The WordPress admin sidebar icon for Logbook is now
**`dashicons-book-alt`** (a closed book) instead of the generic
cog wheel (`dashicons-admin-generic`). The closed-book glyph is the
most literal possible match for the word "logbook" in the Dashicons
set — reinforces the brand identity at the first place users see
the plugin every day.
If you'd prefer a different icon, the line lives in
`wp-notes.php → wp_notes_admin_menu()` as the 7th arg to
`add_menu_page()`. Alternatives worth considering:
`dashicons-edit` (pencil), `dashicons-clipboard` (clipboard),
`dashicons-welcome-write-blog` (pencil over paper),
`dashicons-format-aside` (notes glyph). Full list at
https://developer.wordpress.org/resource/dashicons/
### Version bump
- wp-notes.php header 3.3.4 → 3.3.5
- WP_NOTES_VERSION constant 3.3.4 → 3.3.5
- About page version-history leads with v3.3.5; v3.3.4 demoted.
---
## [3.3.4] — 2026-05-25
**Repo renamed on Gitea: `a-wp-notes-v3` → `a-logbook`.** Also the
local working folder on M3: `/Users/ranger/scripts/Gitea/a-logbook`
(was `a-wp-notes-v3-archive`). The old repo name was a holdover
from the v3-of-A-WP-Notes archival era; with the plugin firmly
identifying as Logbook now, the repo and folder names should match.
### Changed
- **`inc/wp-notes-updater.php`** — `WP_NOTES_GITEA_REPO` constant
updated from `a-wp-notes-v3` to `a-logbook`. The update checker
now hits `https://git.davidtkeane.com/api/v1/repos/ranger/a-logbook/...`
on every check. (The constant remains override-able via
`define()` in `wp-config.php` if the repo ever moves again.)
- **`inc/wp-notes-about.php`** — "View the full CHANGELOG.md →"
link on the version-history card updated to the new repo path.
- **Local working folder on M3** renamed to `a-logbook` to match
the Gitea repo name. `.git/config` survived the move intact;
remote URL updated separately.
### Unchanged (zero-migration commitment continues)
- Plugin slug (`wp-notes`).
- Plugin text domain (`a-wp-notes`).
- All internal function names, constants (`WP_NOTES_*`), DB option
keys, user_meta keys, file names inside the plugin
(`wp-notes.php`, `inc/wp-notes-*.php`).
- Historical CHANGELOG references to `a-wp-notes-v3` (e.g. in the
v3.2.0 entry) stay as historical truth.
---
## [3.3.3] — 2026-05-25
**Verification bump.** Pure version increment to test the end-to-end
"Check now" flow against the now-publicly-hosted Gitea repo. No
functional changes. David's Local install (running v3.3.2) should
now see *"v3.3.3 available — Download .zip"* in the Settings →
Updates panel once "Check now" is clicked, confirming the update
mechanism works against a real version delta. After the test, he
can `git pull` to land on v3.3.3 and watch the same panel flip back
to *"You are up to date (v3.3.3)"*.
---
## [3.3.2] — 2026-05-25
### Fixed — update checker now works with tag-only workflows
The v3.3.0 update checker only queried Gitea's `/releases/latest`
endpoint, which requires a **formal Release object** (created via
the Gitea web UI with optional notes + zip assets). A plain
`git tag v3.3.x && git push --tags` from the terminal doesn't
create that Release object — so the checker kept returning *"No
releases tagged on the Gitea repo yet"* even when tags clearly
existed.
`wp_notes_fetch_latest_release()` now falls back to the
`/tags?limit=1` endpoint when `/releases/latest` returns 404 (or
any non-200). It synthesises a release-like payload from the
newest tag — `tag_name`, an `html_url` pointing at the tag view,
the tag message as the body, and an empty `assets[]` array so the
existing download-URL logic falls through to Gitea's source-archive
URL pattern (`/archive/<tag>.zip`).
**Net effect:** the "Check now" button now finds the latest version
whether David creates formal Gitea Releases OR just pushes tags
with `git push --tags`. No workflow change required.
### Known limitation (not a bug — flagged for awareness)
The Gitea repo `ranger/a-wp-notes-v3` is currently **private**.
Anonymous API requests get a 404 (Gitea's standard behaviour to
avoid leaking the existence of private repos). The updater code is
correct, but it can't actually reach the API on a private repo
without authentication. **Fix:** change the repo visibility to
public on Gitea (Settings → Visibility) — appropriate anyway for a
GPL-licensed plugin headed for the WordPress.org marketplace.
---
## [3.3.1] — 2026-05-25
**Naming: dropped the `WP` prefix. The plugin is now just `Logbook`.**
David's call after a short discussion about WordPress.org marketplace
considerations — WP.org's trademark policy historically discourages
plugins implying official endorsement via a `WP` prefix and has been
known to request a rename during submission review. Dropping it now
makes the name cleaner *and* sidesteps that future hurdle if/when
the plugin lands on the marketplace.
### Changed
- All user-facing brand mentions: `WP Logbook``Logbook` across
plugin header, admin menu, admin bar, dashboard widget, settings
H1, main page H1, About page intro, About page card heading,
feedback email subjects/body, error_log prefix, updater panel
copy, and styles docblock.
- About page version-history card gets a new top entry for v3.3.1
with the green "latest" pill; v3.3.0 demoted to the previous slot.
- CHANGELOG header line updated to track the full naming lineage:
*A-WP-Notes (≤v3.1.0) → WP Logbook (v3.2.0v3.3.0) → Logbook
(v3.3.1+)*.
### Notably NOT changed
- Historical CHANGELOG entries for v3.2.0 (the original "WP
Logbook" rebrand) still say "WP Logbook" — that was the correct
name at the time and rewriting it would be revisionist.
- Same zero-migration commitment as the v3.2.0 rebrand: internal
function names, constants, DB option keys, user_meta keys, file
paths, plugin slug, and text domain all unchanged. Pure
user-facing string change.
---
## [3.3.0] — 2026-05-25
**New feature: self-hosted update checker.** WP Logbook is hosted on
the author's own Gitea instance (`git.davidtkeane.com`), not on
WordPress.org, so WordPress's built-in update flow doesn't see new
releases. This release adds a small **Updates** panel to the
Settings page that polls the Gitea Releases API and tells you when
there's a newer version waiting.
### Added
- **`inc/wp-notes-updater.php`** — full rewrite of the previous
broken stub (which had a hard `require` on a non-existent vendor
path and was never included from the main plugin file anyway).
- **Settings → Updates panel** at the bottom of `Settings → WP
Logbook → Settings`. Shows the current status on load (cached),
with a **Check now** button that force-refreshes against the
Gitea API.
- **`wp_notes_fetch_latest_release()`** — hits
`/api/v1/repos/<owner>/<repo>/releases/latest` on Gitea, parses
the response, normalises into `{version, html_url,
download_url, body, published_at}`. Prefers a `.zip` asset
attached to the release; falls back to Gitea's source-archive
URL (`/archive/<tag>.zip`).
- **`wp_notes_update_status()`** — version-compares against
`WP_NOTES_VERSION` and returns one of `available`,
`up-to-date`, or `unknown` (the last when no release has been
tagged yet — graceful first-time UX).
- **AJAX endpoint `wp_notes_check_updates`** — capability gated
(`manage_options`) + nonce protected. Deletes the cache and
re-fetches.
- **Quick links** in the panel: *View on Gitea* and *View all
releases* — both open the Gitea web UI in a new tab.
### Cached
- Successful release fetches: **12 hours** in a site transient.
- Negative responses (e.g. HTTP 404 = no releases tagged yet):
**1 hour** so a freshly-tagged release shows up quickly.
### Installation flow (manual on purpose)
The panel does NOT auto-install. Manual path (printed in the
panel itself): *download the .zip → deactivate plugin → upload via
Plugins → Add New → Upload → reactivate*. Notes live in
`wp_options` so they survive the upgrade.
### Notes for future-Claude / future-David
- The Gitea repo currently has **zero release tags** — so the very
first run of this checker will show *"No releases tagged on the
Gitea repo yet."* That's by design. Tag the v3.2.0 / v3.3.0 / v4
releases on Gitea as we ship them and the checker will start
reporting versions on its own.
- The Gitea repo coordinates live in three constants at the top of
`inc/wp-notes-updater.php` (`WP_NOTES_GITEA_HOST`, `_OWNER`,
`_REPO`). Override-able via `define()` in `wp-config.php` if the
repo ever moves.
### Also in this release — heading rename carried over from the unreleased block
### Changed — Section headings on My Log page renamed to match the logbook framing
- `Add New Note` → **`New Log Entry`** on the create form postbox.
- `Notes Todo List:` → **`Log entries`** above the active/completed
lists.
- Row-level labels intentionally **unchanged** — buttons like *Add
Note* / *Mark as Done* / empty-state *No active notes found* still
say "note" because that's the unit-of-work term in the existing
data model and UI. The headings are brand-y; the row-level strings
are functional. Two different concerns, different rename scope.
---
## [3.2.0] — 2026-05-25
**Plugin rebrand: `A-WP-Notes` → `WP Logbook`.** Bundles the rename
with the About-page rewrite and the working Leave-Feedback form that
were sitting in the post-3.1.0 unreleased block.
The plugin's identity has shifted over the day's work — from a notes
pad to a work-logbook with time tracking, earnings, and a Wallet
tile on the v4 roadmap. "WP Notes" undersold what it had become and
collided semantically with WordPress's *notes-as-memos* connotation;
"WP Logbook" matches both the freelancer-proof-of-work use case
("logbook for clients") and the student-evidence-of-work use case
("logbook for teachers"), and matches the exact word the plugin's
own About-page intro had been using all day.
### Changed
- **Plugin Name** header: `A-WP-Notes` → `WP Logbook`.
- **Description** header rewritten from "A plugin to add your notes
to the WordPress dashboard with import/export functionality" to
*"A lightweight task &amp; logbook plugin for WordPress. Log your
daily work, mark tasks done, and keep a tidy record inside the
dashboard. Perfect for freelancers showing clients what's been
delivered and students proving work to teachers."*
- **Version bumped** v3.1.0 → v3.2.0 (header + `WP_NOTES_VERSION`
constant).
- **Admin menu top-level** `WP Notes` → `WP Logbook`.
- **Admin sidebar submenu** `My Notes` → `My Log` (matches the
new parent name; reads cleanly as "WP Logbook → My Log").
- **Admin bar count menu** `WP Notes (N)` → `WP Logbook (N)`.
- **Dashboard widget** title `WP Notes` → `WP Logbook`.
- **Settings page H1** `WP Notes Settings` → `WP Logbook Settings`.
- **Main page H1** `WP Notes` → `WP Logbook`.
- **About page** every brand mention updated (intro card, "What WP
Logbook does" heading, "Go to My Log →" CTA on the side-by-side
intro that used to say "Go to WP Notes →").
- **About page version history** now leads with v3.2.0 (this
release) as `latest` and demotes v3.1.0 to the previous entry.
- **CPT `menu_name` label** `WP Notes` → `WP Logbook` (cosmetic
only; CPT is hidden from admin UI since the duplicate-form fix in
v3.1.0).
- **Migration notice text** "WP Notes needs to migrate…" → "WP
Logbook needs to migrate…".
- **Email-feedback subject** `[Site] WP Notes feedback from X` →
`[Site] WP Logbook feedback from X`. Body intro line same change.
- **Legacy feedback.php subjects** (`WP Notes Feedback` /
`WP Notes Help Request`) → `WP Logbook Feedback` /
`WP Logbook Help Request`. These render only if the unused legacy
feedback file is ever required-in; brought along for hygiene.
- **`error_log()` prefix** `[WP Notes]` → `[WP Logbook]`.
### Notably NOT changed (zero-migration commitment)
- **All internal function names** keep `wp_notes_*` prefix.
- **All constants** keep `WP_NOTES_*` names.
- **All DB option keys** (`wp_notes`, `wp_done_notes`,
`wp_notes_settings`, `wp_notes_migration_completed`,
`wp_notes_version`, `wp_notes_dismissed_empty_active|completed`)
stay as-is. **No data migration runs on upgrade.**
- **All `user_meta` keys** stay as-is.
- **Admin page slug** `wp-notes` stays — preserves bookmarks, the
admin-bar `#new-note` anchor, and the legacy
`?page=wp-notes-create` → `?page=wp-notes` redirect added in
v3.1.0.
- **Plugin text domain** `a-wp-notes` stays — would otherwise
invalidate any future translation files.
- **File and directory names** unchanged (`wp-notes.php`,
`inc/wp-notes-*.php`, `assets/wp-notes-banner.jpg`). The Gitea
repo `ranger/a-wp-notes-v3` is unchanged too — David can rename
it on the Gitea side separately if he wants.
The rename is **purely user-facing strings**. Existing installs see
the new name appear after a plugin file refresh, with zero behaviour
change. No re-activation needed.
### Changed — Leave Feedback form (more options, multi-select, wired to email)
The right-column "Leave Feedback" form on the About page has been
expanded from two radio buttons to **seven checkboxes** (users can
pick more than one), a new optional message textarea, and a submit
button that **actually does something** — it AJAX-posts to a new
WP handler that emails the site admin via `wp_mail()`.
**Form options (checkboxes — multi-select):**
- I have ideas to improve this plugin
- I need help with this plugin
- I found a bug
- I'd like to request a new feature
- I'd like to share my use case
- Just saying thanks 🍀
- Other
**Submission flow:**
1. Client-side: at least one checkbox OR a message is required;
otherwise an inline hint shows.
2. AJAX POST `wp_notes_submit_feedback` with topics[] + message +
nonce.
3. Server-side handler (`manage_options` capability + nonce checked)
sanitizes input, allow-lists the topic keys, then builds a plain-
text email and ships it to `get_option('admin_email')` via
`wp_mail()`. Reply-To is set to the submitting user's email so
the admin can reply directly.
4. Email body includes: sender (display name + email + WP login),
site URL, plugin version, the checked topics (pretty-labelled),
and the message.
5. Inline success message replaces the form on success; inline
error message lets the user retry on failure.
The old radio-button + broken `toggleSection('feedback-form-...')`
logic that pointed at non-existent IDs has been replaced entirely.
The `toggleSection()` helper is kept defined but is now genuinely
unused on the About page — flagged for removal in a future Tier-2
pass.
### Changed — About page rewritten (content + layout)
The About page (`Settings → WP Notes → About`) has been rewritten
from "wall of nested toggle boxes with outdated content" to
"readable cards with accurate content". The left column is now
three plain cards: **What WP Notes does**, **Who it's for**, and a
**Version history** that actually matches the current plugin
version.
What changed:
- **Removed two `<button>onclick=toggleSection()</button>` wrappers**
around the About and Version History sections. Users came to the
About page to read content — hiding it behind a toggle was
anti-UX.
- **"Version 2.0.3 (Current)"** entry was lying — the plugin is now
v3.1.0. Replaced the whole version section with a compact
accurate summary (v3.1.0 → v3.0.2 → v2.x → v2.0.0) plus a
prominent **"View the full CHANGELOG.md →"** link to the canonical
history on Gitea so the on-page summary doesn't have to be
exhaustive.
- **Removed redundant duplicate paragraphs** ("WP Notes is a
versatile plugin that caters to a wide range of users" appeared
twice in two lines).
- **Removed invalid HTML** — bare `<li>` outside `<ul>`, `<p>`
wrapping `<li>`.
- **Removed buried banner image + Buy-Me-A-Coffee** that were
inside the (hidden-by-default) Version History toggle, never
seen by anyone. The banner already lives at the top of the page
in the side-by-side intro row; the support link already lives in
the right-column feedback card.
- **Dropped the "Teachers want progress with Email Notifications"
use-case** — email notifications aren't implemented in v3.x so
the claim was misleading.
- **Added three CSS card classes** (`.wp-notes-about-card`,
`.wp-notes-about-card--versions`) for visual rhythm with the
intro row above, plus styling for the version entries (latest
pill, monospace version labels).
The right-column feedback box is unchanged. `toggleSection()` is
also unchanged — still defined (no harm, used by the feedback
form's broken-since-forever submit handler which is its own
Tier 2 problem).
---
## [3.1.0] — 2026-05-25
A single-day UX polish + bug-fix release. Nine commits worth of
work, focused on the main "My Notes" admin page: stripping out
years of layout debt, tightening the menu structure, removing
duplicates, and adding the per-user persistent dismissal of the
empty-state notice. No data migration required; storage model
unchanged (notes still live in `wp_options`).
### Removed — Tools → My Notes shortcut (with backward-compatible redirect)
The "Tools → My Notes" admin menu shortcut has been removed. It
routed to a separate bare-bones form at `?page=wp-notes-create`
rendered by `wp_notes_create_page()` — a stripped-down create form
with no notes list, no styling, and no parity with the main page.
The shortcut was a third route to "create a note" duplicating the
two that already exist and work better:
1. **WP Notes → My Notes** in the admin sidebar (the proper page —
styled form + active/completed lists + edit + restore).
2. **Admin bar → WP Notes → New Note** quick-access (jumps to the
form on the main page via `#new-note` anchor).
**Backward-compat redirect:** anyone hitting the legacy
`?page=wp-notes-create` URL (stale bookmark, old email link, etc.)
is now `wp_safe_redirect()`-ed to `?page=wp-notes` via an
`admin_init` hook. No 404 / no "you do not have sufficient
permissions" page.
**Code removed:**
- `wp_notes_add_tools_menu()` registration (the `add_management_page`
call and its `add_action('admin_menu', ...)` hook).
- `wp_notes_create_page()` function body in full — the bare-bones
form renderer, no longer referenced anywhere.
### Added — Persistent dismissal of the empty-state notice (user_meta)
The "No active/completed notes found" notice was already
dismissible per-page-load, but pressing X only hid it for the
current view — it returned on the next refresh. The dismissal is
now persisted to **user_meta** per-user-per-list-type, so once you
close it, it stays closed until you reset the flag.
**Mechanics:**
- `inc/wp-notes-display.php` checks
`get_user_meta(uid, 'wp_notes_dismissed_empty_<type>')` before
rendering and skips the notice entirely when set.
- `wp_ajax_wp_notes_dismiss_empty` (new handler in `wp-notes.php`)
validates a nonce + `edit_posts` capability, then writes the flag
via `update_user_meta()`. Accepts `type` of `active` or
`completed`; rejects anything else.
- An inline jQuery handler in `wp_notes_add_inline_scripts()` listens
for clicks on `.wp-notes-empty .notice-dismiss` (WP core's auto-
injected X button), reads the data-attributes off the notice, and
fires the AJAX call. WP core still handles the visual hide.
- The notice element carries `data-wp-notes-empty-type` and a fresh
per-render `data-wp-notes-nonce` for the round trip.
**Reset:** the flag is per-user-meta keyed
`wp_notes_dismissed_empty_active` /
`wp_notes_dismissed_empty_completed`. To make the notice reappear
for a user, an admin can clear those keys (or `wp_delete_user`
removes them automatically). A UI button to reset dismissed notices
is not built yet — flagged as a future enhancement if needed.
### Fixed — Duplicate "Create a New WP Note" form at the bottom of My Notes
A second, bare-bones *"Create a New WP Note"* form was being
rendered at the **bottom** of the My Notes page, below the active
and completed lists. The form at the **top** (the proper `Add New
Note` postbox with color/size/font/emoji controls) is the intended
one — the bottom one was a duplicate, redundant from a UX standpoint.
**Root cause:** WordPress registers BOTH the parent menu's callback
AND a submenu's callback against the same page hook when the two
share a `menu_slug`. When `?page=wp-notes` is requested, both fire
in registration order. The submenu was passing `wp_notes_create_page`
as its callback (a separate bare-form renderer used by the
Tools-menu shortcut), so its output was getting appended below the
main page.
**Fix:** the My Notes submenu now passes an **empty string** as the
callback — the standard WP pattern when a submenu just relabels the
parent (same slug, same target page). Only the parent's
`wp_notes_page_callback` renders now. The `wp_notes_create_page`
function is unchanged and still serves the Tools → My Notes
shortcut at `?page=wp-notes-create`.
### Fixed — Empty-state notice ("No notes found") now dismissible
The "No active notes found" / "No completed notes found" inline
notice on the My Notes page rendered with `class="notice notice-info"`
but no `is-dismissible` modifier, so WordPress's core common.js
never attached an X close button to it. Users couldn't clear the
message for the current view. Adding `is-dismissible` is the only
change — WP core handles the X button render + click-to-hide
automatically. Dismissal is per-page-load (the message reappears on
next refresh if the list is still empty); persistence across
reloads would need user_meta tracking and isn't built yet.
**Notice inventory after this fix** — every notice the plugin emits
is now both dismissible AND only fires in its intended state:
| Notice | Class | Fires when |
|---|---|---|
| "No active/completed notes found" | `notice notice-info is-dismissible` | List is empty |
| Migration prompt | `notice notice-info is-dismissible` | `wp_notes_migration_completed` option is unset |
| Settings save / import errors / import success | rendered by core `settings_errors()` (auto-dismissible since WP 4.2) | Only on form submission events |
### Changed — Removed duplicate smiley-face button on the emoji picker
The "Add emoji" formatting option rendered two clickable elements
stacked: the *"Click to add emoji"* text input AND a separate button
beside it with a smiley-face dashicon. Both opened the same dropdown
picker — visually duplicated and slightly confusing. The standalone
button has been removed; clicking the input itself still opens the
picker (the JS already wired both targets to the same handler).
Keyboard navigation (Enter/Space to toggle, Escape to close)
follows focus to the input instead of the now-gone button.
Orphaned `.emoji-picker-button` CSS rule deleted.
### Changed — Menu labels: "Create WP Note" → "My Notes", "About WP Notes" → "About"
- **"Create WP Note" submenu renamed to "My Notes"** (both in the WP
Notes parent menu and the Tools → quick-access shortcut). The page
is the central dashboard — create form + active list + completed
list + edit + restore — so "Create" was misleadingly narrow.
"My Notes" matches the WP-native `Posts → All Posts` pattern.
- **"About WP Notes" submenu renamed to just "About".** The WP Notes
brand is already carried by the parent menu, so the submenu can be
plain-spoken.
- **About page H1 trimmed** to match the Tier-1 style on the main
page: `<h1>About</h1>` + version chip instead of the old
*"Welcome to WP Notes About Page v3.0.2"* mouthful. Same
`wp-heading-inline` + `page-title-action` + `wp-header-end` recipe.
- Removed a redundant nested `<div id="header">` with `display: none`
on the About page — it was dead markup leftover from an older
layout.
### Changed — Banner moved to About page (side-by-side intro)
- **Banner image removed from the Create-Note page.** It was the
first thing under the page title and took up significant vertical
space before the user even saw the textarea. The Create-Note page
is for *doing*, not for *reading-about*.
- **Banner added to the top of the About page** in a new
side-by-side row: banner image on the left (capped at 320px wide,
not full-bleed), and a short intro paragraph + "Go to WP Notes →"
CTA on the right. Stacks vertically on narrow screens via
`flex-wrap`. Lives inside its own `.wp-notes-about-intro` block so
it doesn't interact with the rest of the About page's nested
toggles.
- **`.wp-notes-header-banner` / `.wp-notes-banner-img` CSS removed**
from `wp-notes-styles.php` — no longer used.
### Changed — Tier 1 UX cleanup
Single pass through `wp_notes_page_callback()` to remove the layout
debt that had built up over previous releases. Functionality is
unchanged; the page is shorter, has one H1, and stops contradicting
itself.
- **Single H1** on the page — was five (`Welcome to WP Notes`,
`Welcome to WP Notes v3.0.2`, `About WP Notes`, `What WP Notes
Offers`, `What's New in WP Notes v3.0.2`). Now: just
`WP Notes` with the version chip alongside. Accessibility + SEO.
- **"Welcome / About" content** collapsed from THREE on-page
surfaces (a dismissible top notice + a nested toggle + a manual
"Show Welcome Message" button) down to a single one-line
description that links to the dedicated About page where the long
copy already lives.
- **Duplicate "Toggle Welcome Section" buttons removed.** Both
outer and inner toggle buttons had the **same label** but
different targets — genuinely confusing. Both gone.
- **"What's New v3.0.0" embedded changelog block removed.** It was
hard-coded to v3.0.0 while the plugin reports v3.0.2 — the embed
was lying. The real history lives in `CHANGELOG.md` now.
- **"Buy me a coffee" button moved from page header to page footer**
— promo content should not be the first thing under the page
title. Now sits at the bottom of the notes lists, centred, where
footer items belong.
- **Invalid HTML cleaned up** — `<li>` tags outside `<ul>`, `<p>`
tags wrapping `<div>` / `<ul>`. Was in the deleted welcome blob,
so resolved by removal.
- **Dead bulk-action UI removed** — both the per-row checkboxes and
the "Select all" header column in `wp_notes_display_notes()` and
`wp_notes_list_table()` were rendered but nothing acted on the
selection. Removed both, with an inline comment marking the spot
for when real bulk-actions get wired up. Edit-form colspan
adjusted (`6` → `4`) to match the new column count.
- **Inline `<style>` and `<script>` blocks for the dismissed
about-box** (~80 lines of localStorage-based dismiss tracking and
show/hide logic) **deleted** along with the about-box itself —
WordPress's own `notice notice-info is-dismissible` and the
user-meta dismissal API are the correct path if a banner needs to
return.
- **`toggleSection()` JS helper removed** — no toggles remain on
the page after the welcome-blob deletion.
### Fixed (PHP 8.2 deprecation)
- `${size}px` → `{$size}px` in the dashboard list-table render.
`${var}` string interpolation is deprecated in PHP 8.2 and will
hard-error in PHP 9.
### Notes
- The dedicated **About** page (`Settings → WP Notes → About WP
Notes`) is unchanged and still renders `wp_notes_about_page()` from
`inc/wp-notes-about.php`. All the long welcome/about copy lives
there — exactly where it belongs.
- Banner image still renders, in its own bordered container at the
top of the page. Moved out of the deleted nested toggle so it
actually shows.
- Storage model is unchanged — notes still live in `wp_options`
under `wp_notes` / `wp_done_notes`. The UX cleanup is purely
presentational.
### Fixed
- **"Add New Note" sidebar submenu opening the WordPress post editor.**
The plugin registered a `wp_note` custom post type with
`show_ui => true` and `show_in_menu => 'wp-notes'`, which caused
WordPress to auto-inject "All Notes" and "Add New" submenus under
the WP Notes admin menu. The "Add New" submenu routed to
`post-new.php?post_type=wp_note` — the standard WordPress post
editor — but the live plugin stores notes in `wp_options`
(`get_option('wp_notes')`), not as CPT posts. Saving in the post
editor wrote to the wrong storage and the new note never appeared
in the WP Notes list. Discovered 2026-05-25.
Fixed by setting `show_ui` and `show_in_menu` to `false` on the
`wp_note` CPT, and `show_ui` / `show_admin_column` /
`show_in_rest` to `false` on the `wp_note_category` taxonomy. The
CPT and taxonomy remain registered so `wp_notes_migrate_to_cpt()`
can still use `wp_insert_post()` if/when the migration is run.
The form on the actual WP Notes page (the one that POSTs to the
same admin page) continues to work unchanged.
### Notes
- The plugin currently uses **two storage models**: the active one is
`wp_options` (key `wp_notes`, with completed notes in
`wp_done_notes`). The CPT + meta storage is the *target* of an
unfinished migration; the helper `wp_notes_migrate_to_cpt()` is
defined but unused by the live UI. Until that migration is
completed, hiding the CPT from the admin UI prevents users from
accidentally writing to the wrong store.
---
## [3.0.2] — 2025-05-10 (last released version, baseline)
The v3 "without all the crap" release. Trimmed from the v1.1.5
feature-creep era which had bolted on:
- AI chat (multiple variants)
- AI personalities
- Journal mode
- Speedtest
- Tamagotchi (yes, really)
- Backup
- And more
v3 strips back to the essentials:
- Notes list (in `wp_options`)
- Create note form (color, size, font, emoji)
- Admin bar quick-access menu
- Settings page
- Import / Export
- About page
- Update checker
This baseline entry exists for historical context; future releases
should keep adding entries above and remove this note once a real
changelog history accrues.