Add command palette registration APIs and sync functionality#5
Merged
Conversation
- Introduced `wp_desktop_register_command_script()` to register command-palette script handles, allowing live command registration without page reloads. - Added `wp_register_desktop_command()` for server-side command metadata registration, enabling future pre-registration shims. - Implemented server-side command sync in `src/commands/server-sync.ts`, handling script injection and command unregistration on plugin deactivation. - Updated JavaScript reference documentation to include new command registration methods and their usage. - Enhanced PHP documentation for command registration functions. - Created unit tests for command registration and sync functionalities to ensure reliability. - Updated the main plugin file to include the new commands module.
AllTerrainDeveloper
added a commit
that referenced
this pull request
May 3, 2026
Two CI breakages on the routines PR: 1. **`test_if_branch_routes_correctly` failed** with "Undefined array key 'branch'" at log index 0. The executor was pushing the `if`-step entry to the steps_log AFTER walking its children, so the first entry in the log was a child step (no `branch` key), not the if itself. Fix: push the `if` entry FIRST with a `ms: 0` placeholder, capture its index, then patch the total `ms` (children included) by indexing back into the log after the recursive walk finishes. Result: log reads chronologically — "if went to then, then set_var ran" instead of "set_var ran somewhere, then we found out it was the then branch of an if". 2. **CI output polluted** with stray `[wpdm-routine #5] INFO: hi Daniel` lines from the `log` step's tests. The handler was calling `error_log` unconditionally; under PHPUnit the write goes to stderr and litters the run's output log. Fix: same pattern the `wait` step already uses to skip `sleep` — short-circuit the actual error_log call when `WP_TESTS_DOMAIN` (or `WP_RUN_CORE_TESTS`) is defined. The step still returns its payload so the routine's per-step log captures the message; we just don't double-write to the PHP log where no human will read it during a CI run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Newly-installed or activated plugins that register slash-commands via
wp.desktop.registerCommand()didn't appear in the palette until a full page reload — the plugin's JS was never enqueued into the currently-running shell page, so nothing calledregisterCommanduntil F5.Fix it the same way widgets and wallpapers solve the equivalent problem: server-declare the plugin's command script in PHP, extend the
wp-desktop-plugins-changedpayload with the resolved URL, and have a newsrc/commands/server-sync.tsmodule dynamically inject the script on activation. Live-unregister the plugin's commands on deactivation.New public API
One line of PHP. The plugin keeps its command definitions in JavaScript where the run function already lives. On mid-session install / activate, the shell injects the script and the new commands appear in the palette with no reload. On deactivate, commands whose owner matches the departing script handle are unregistered live.
Minimal working plugin (/echo)
Drop these two files into wp-content/plugins/my-echo/ and activate.
my-echo.php
echo.js
Open the palette, type /echo hello → replies with hello.
Changes
PHP
TypeScript
Docs
Repo-level CLAUDE.md — captures the plugins-changed live-refresh architecture so future changes don't re-derive it.
Tests
Plugin migration
Zero work required for existing plugins — they keep their current F5 behavior. Plugins that want live-refresh add the one-line PHP call shown above and (optionally) set owner on their registerCommand calls to get live-unregister on deactivate.
Test plan