Add PHP / WordPress / Composer / PHPUnit / ddev coverage to rewrite registry

[Fyrins]

The v3 thin hook in 0.35 is great, and pushing all the rewrite logic into rtk rewrite was the right move. One gap I keep hitting: the registry is currently very thin on the PHP/WordPress side of things.

Context

$ rtk --version
rtk 0.35.0

Hook installed via rtk init -g (v3, delegates to rtk rewrite).
Stack: PHP / WordPress / Bedrock / ddev, daily.

The gap

I went through the commands I actually run on a typical WordPress day. They all return exit code 1 (no rewrite), even though they dump exactly the kind of verbose, structured output the rest of rtk is built around.

Reproduction

$ rtk rewrite "wp plugin list"                ; echo $?   # 1
$ rtk rewrite "wp post list"                  ; echo $?   # 1
$ rtk rewrite "wp option get siteurl"         ; echo $?   # 1
$ rtk rewrite "wp plugin activate akismet"    ; echo $?   # 1
$ rtk rewrite "vendor/bin/phpunit"            ; echo $?   # 1
$ rtk rewrite "phpunit tests/Foo.php"         ; echo $?   # 1
$ rtk rewrite "phpcs --standard=WordPress src"; echo $?   # 1
$ rtk rewrite "phpcbf src"                    ; echo $?   # 1
$ rtk rewrite "php -l file.php"               ; echo $?   # 1
$ rtk rewrite "composer test"                 ; echo $?   # 1
$ rtk rewrite "composer dump-autoload"        ; echo $?   # 1
$ rtk rewrite "ddev composer install"         ; echo $?   # 1
$ rtk rewrite "ddev wp plugin list"           ; echo $?   # 1
$ rtk rewrite "npm test"                      ; echo $?   # 1   # see "Bonus" below

For comparison, the neighbours that already work:

$ rtk rewrite "git status"           # 0  -> rtk git status
$ rtk rewrite "composer install"     # 0  -> rtk composer install
$ rtk rewrite "npm run build"        # 0  -> rtk npm run build

Suggested mapping

These fit cleanly into the existing summary / err / test categories. I can send a PR against src/discover/registry.rs if you confirm conventions.

wp (WP-CLI)

Listing and read commands -> rtk summary. Output is usually a giant table or JSON blob, but only the headline state matters in an LLM context.

• wp plugin list, wp theme list, wp post list, wp user list, wp option list, wp term list, wp comment list, wp media list, wp site list
• wp option get, wp config get
• wp cron event list, wp cron schedule list
• wp db tables, wp db query, wp db search
• wp search-replace, wp export, wp eval, wp eval-file

Side-effect commands -> rtk err. The interesting output is errors and warnings, the rest is noise.

• wp plugin {activate,deactivate,install,update,delete,uninstall}
• wp theme {activate,install,update,delete}
• wp cache {flush,delete}, wp transient delete
• wp rewrite {flush,hard}
• wp core {update,update-db,verify-checksums}
• wp db {optimize,repair,check,clean}
• wp media {regenerate,import}
• wp option {update,delete}

Composer

• composer test, composer test:*, composer run test* -> rtk test
• composer dump-autoload, composer require, composer remove, composer update, composer run-script, composer run * -> rtk err
  (composer install is already covered. The same logic should extend to its siblings.)

PHPUnit / PHPCS / PHPCBF

• phpunit, vendor/bin/phpunit, ./vendor/bin/phpunit -> rtk test
• phpcs, vendor/bin/phpcs, phpcbf, vendor/bin/phpcbf -> rtk err

Plain PHP CLI

• php -l <file> (lint) -> rtk err
• php -r '<expr>' (one-liner) -> rtk err (mostly fatal/notice noise)

DDEV (and friends: lando, wp-env, ...)

DDEV wraps any command as ddev <wrapped>. The cleanest fix is to strip the ddev prefix and recurse so every existing rule auto-applies. The same trick would cover lando, wp-env, and any other dev-container CLI.

Examples that should "just work" if recursion is supported:

ddev composer install   -> rtk composer install
ddev wp plugin list     -> rtk summary wp plugin list
ddev phpunit            -> rtk test phpunit
ddev npm run build      -> rtk npm run build

Bonus: npm test

$ rtk rewrite "npm test"      -> exit 1 (no rewrite)
$ rtk rewrite "npm run build" -> rtk npm run build

npm test is by far the most common npm invocation in the wild. Worth catching as rtk test, or at minimum mirroring the npm run build behaviour for parity.

Why it matters

WP-CLI alone has 100+ subcommands, almost all of them dumping tables or noisy logs to stdout. Right now a PHP/WordPress user leaves a big chunk of potential token savings on the floor compared to someone working in JS, Rust, or Go.

I'm currently working around this with a hand-maintained block in front of rtk rewrite in my Claude Code hook. The v3 hook itself says it best: "all rewrite logic lives in rtk rewrite, which is the single source of truth". So I'd rather upstream this.

Happy to send a PR. Just point me at src/discover/registry.rs and let me know your preferred granularity.

[pszymkowiak]

wshm · Automated triage by AI

🔍 Automated Triage

✨ Category	feature
🟡 Priority	medium
🎯 Confidence	93%

Summary

Well-scoped enhancement request to add PHP/WordPress/WP-CLI/Composer/PHPUnit/ddev rewrite rules to registry; author offers to PR against src/discover/registry.rs

📁 Relevant files

• src/discover/registry.rs

---

Triaged automatically by wshm · This is an automated analysis, not a human review.

[Beninho]

Hello,
I already create a first PR for PHPUnit.
#874

Maybe it can be the beginning of PHP feature.

[HirokiTsurunaga]

I'd like to add support for php artisan test (Laravel's test runner, which wraps PHPUnit).

Since PR #874 already implements PHPUnit support, I think Laravel Artisan test could follow a similar pattern. The main difference would be the command prefix:

• php artisan test
• php artisan test --filter TestName
• php artisan test --parallel

The output format is nearly identical to PHPUnit since it's just a wrapper.

Would this fit into the scope of this issue, or should I create a separate one? Happy to contribute a PR once the approach is confirmed.