fix: register the Edit Snippet menu item only while editing

[TallblokeUK]

Draft — the approach is worth a look before this goes further, particularly the choice to keep the ID on a link rather than in the registered slug.

Reported

https://wordpress.org/support/topic/edit-snippet/ — two problems in one thread, with one cause.

1. The item is registered globally. The reporter uses Admin Menu Editor Pro to keep other admins out of the Snippets area, and "Edit Snippet" keeps reappearing in their menu after updates.

2. Selecting it starts a new snippet. As acknowledged in the thread: the item is meant to mark the page you're on, but following it lands on Add New.

Cause

Edit_Menu registered the item unconditionally on admin_menu and removed it afterwards on current_screen, which fires later. Nothing ever rendered it — but it genuinely sat in $submenu in between.

A probe reading the menu at the end of admin_menu, which is what a menu editor does, found it on every admin screen:

admin_menu(9999) on /wp-admin/index.php               : Edit Snippet => edit-snippet
admin_menu(9999) on /wp-admin/admin.php?page=snippets : Edit Snippet => edit-snippet

So the reporter's tooling isn't misbehaving: it captures a genuinely-registered page and persists it. Their access-control complaint is real.

And while editing snippet 5, the item's link was admin.php?page=edit-snippet with no ID:

editing id=5 — title: "Repro 001 — customise the login page behaviour"
after following "Edit Snippet": url=/wp-admin/admin.php?page=add-snippet
title now: ""    ← a new snippet

Unsaved changes go with it.

Change

The page is registered outside the menu, so it stays reachable by URL but never enters $submenu under the Snippets parent. While a snippet is being edited, a plain link to that snippet is added alongside. maybe_hide_menu_item() is deleted — registration decides, instead of registering and retracting.

Why the ID is on a link rather than in the slug — this is the part worth reviewing. A submenu slug doubles as the identifier WordPress checks permissions against. My first attempt rewrote the registered slug to carry the ID; the edit screen then returned "Sorry, you are not allowed to access this page", because page=edit-snippet no longer matched anything registered. That is the "WordPress limitation" from the thread, and adding a separate link is the way around it.

After

	before	after
Menu during admin_menu, Dashboard	parent=snippets	parent=(none)
Rendered menu, not editing	absent	absent
Rendered menu, editing id=5	page=edit-snippet	page=edit-snippet&id=5
Following it while editing id=5	blank new snippet	same snippet

Verified on WordPress 7.0.4 / PHP 8.2.33 / Code Snippets 3.10.0.

Edit_Menu_Test is rewritten for the new design: the page stays reachable, the item is absent when not editing, and carries the ID when it is. All three fail without the change. PHPUnit 156, Playwright 89, lint:js and phpcs clean.

Open questions

• Highlighting: the item is a link rather than a registered page, so WordPress's "current page" styling may not attach to it. It didn't look wrong in testing, but someone who knows the menu internals should confirm.
• Network admin registers through the same path; I haven't exercised multisite.
• No changelog entry, consistent with fix: load admin bar script dependencies on the front end #461–fix: apply the Snippets List Order setting again #465.

Fixes #472