- DB: added is_deleted, deleted_at columns to platforms table
- Soft delete: archive button moves games to archived section instead of hard delete
- Archived section: master admin can restore (reactivates) or permanently delete
- Slug reuse: creating a game with an archived slug reactivates the old record
- New game form: master admin always sees add form + agent info; other admins hidden
- Edit: non-master admins have form card revealed on edit
- Delete/Add buttons: only visible to master admin
- api/platforms.php: public and admin_list queries exclude archived games
- api/admin.php: platforms_archived, platforms_restore, platforms_purge actions added
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Root cause: saves went through admin.php which still used old console_url column
and had broken response using undefined $sent variable (always returned error).
- api/admin.php: platforms_create/update/delete fully rewritten with all agent
fields, master-admin gating, and correct json_encode responses
- api/admin.php: update now sets updated_at=NOW() on save
- admin/index.php: game cards show last-edited date (✏️ from updated_at)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- pending_signups stat and list queries now filter username != __reset__
so active password-reset rows no longer inflate the signup counter or
appear in the admin pending-signups list
- send_password_reset now calls sendPasswordResetEmail() from mailer.php
instead of building a plain-text cybermailSend() call inline; the
wrapper sends a branded dark-theme HTML email matching the verification
email style
Previously the endpoint always returned success:true regardless of
whether the email was actually delivered. Now captures the bool return
value and returns success:false with an error message if CyberMail
fails, so the admin knows to retry rather than assuming delivery.
The INSERT had two compounding bugs:
1. ".?" in the VALUES clause — a PHP dot inside a double-quoted string
is a literal character, not concatenation. MySQL saw it as a syntax
error and the INSERT always failed silently (no try/catch).
2. The token column had the literal string __reset__ hardcoded instead
of a ? placeholder, so even if the INSERT had run, the real random
token would never have been stored — the reset link always invalid.
Fix: VALUES ("__reset__","",?,?,?,?) with execute(alias,email,token,exp)
giving 4 placeholders for 4 params, all columns correctly bound.
myron