Skip to content

Fix #60: remove "Move to plugins" from the per-item More-options menu#71

Open
lucasmendes-design wants to merge 1 commit into
trunkfrom
lucasmdo/customize-menu-remove-move-to-plugins
Open

Fix #60: remove "Move to plugins" from the per-item More-options menu#71
lucasmendes-design wants to merge 1 commit into
trunkfrom
lucasmdo/customize-menu-remove-move-to-plugins

Conversation

@lucasmendes-design
Copy link
Copy Markdown
Collaborator

Fixes #60. Linear: DES-656. Off trunk directly — no stack dependencies. Independent of #70 (which fixed a related pointerdown-dismiss bug in the same menu).

Summary

May 2026 usability testing surfaced that two entries in the per-row More-options menu read as duplicates:

  • Move to plugins — sends the row back into the My Plugins group.
  • Reset to default — also sends a plugin row back into the My Plugins group (its baseline position).

Testers reported clicking one expecting the behaviour of the other, and couldn't articulate the difference. The closest framing from the synthesis ticket:

"I don't know the difference between 'Move to plugins' and 'Reset to default'. They appear to do the same thing."

This PR removes "Move to plugins" entirely and keeps Reset to default as the canonical "send this back where it came from" action. Move to top level (the inverse direction) is unambiguous — it stays.

What changed

src/customizer/move-menu.js only:

  • Removed the for ( const gid of groupIds ) loop that generated the "Move to " choices. With only one group today (plugins), that was always exactly one entry: "Move to plugins".
  • Removed the now-unused groupIds local.
  • Updated the top-of-file comment to describe the new menu shape and reference issue Clarify "Move to plugins" vs "Reset to default" actions in customize mode #60 for the rationale.

The menu's final choice set:

Item is at top level Item is inside the Plugins group
Move up Move up
Move down Move down
Move to top level
Reset to default Reset to default

What was NOT changed

  • crossMove's in_group branch is left in place. It's unreachable today but the function still handles top_level cleanly, and inflating the diff to remove a few unused lines wasn't worth it. Tiny follow-up cleanup if a reviewer wants it.
  • "Move to top level" is preserved — it's the inverse direction and doesn't share Reset's behaviour.
  • Cross-group moves are still possible via drag, and DES-647 tracks broadening drag to more items.

Manual verification

Local Studio site (PHP 8.4 / WP 6.9.4, SQLite) in customize mode, blueprint plugin set.

  • Plugin row inside My Plugins (e.g., Products): menu shows Move up · Move down · Move to top level · Reset to default. No "Move to plugins". ✓
  • Plugin row at top level (after dragging it out of the group): menu shows Move up · Move down · Reset to default. No "Move to plugins", no "Move to top level". ✓
  • Move up / Move down still move by one row.
  • Move to top level still relocates a grouped item to the top.
  • Reset to default still sends the row back to its baseline group + position.

Tests

JS-only behaviour change. The existing tests don't pin the exact set of choices in the menu (grouping.test.js and expand-collapse.test.js cover different code paths). No test updates needed; CI gates the rest of the suite.

🤖 Generated with Claude Code

May 2026 usability testing surfaced that testers couldn't differentiate
"Move to plugins" from "Reset to default" — both actions returned a
top-level item back into its baseline group, so they read as duplicates
and produced unpredictable results when the item was inside the group
already.

Remove the dynamic "Move to <group>" loop from move-menu.js's choices.
Keep "Move to top level" (the inverse direction is a distinct,
unambiguous action). Cross-group moves remain available via drag — and
DES-647 tracks broadening drag to all sidebar items anyway.

Also drops the now-unused `groupIds` local. Left the `in_group` branch
in `crossMove` in place: it's unreachable now, but removing it would
inflate the diff and the function still handles `top_level` cleanly.
Worth a tiny follow-up cleanup if a reviewer wants it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@chriskmnds chriskmnds added the pending: Calypso-parity Not yet implemented on the Calypso side. label May 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pending: Calypso-parity Not yet implemented on the Calypso side.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Clarify "Move to plugins" vs "Reset to default" actions in customize mode

2 participants