Skip to content

Note site-dir dependency in the picker; type scanner-targeted.php's helpers - #180

Merged
jasperf merged 4 commits into
mainfrom
improve/scanner-targeted-help-and-types
Aug 5, 2026
Merged

Note site-dir dependency in the picker; type scanner-targeted.php's helpers#180
jasperf merged 4 commits into
mainfrom
improve/scanner-targeted-help-and-types

Conversation

@jasperf

@jasperf jasperf commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Summary

  • exec.DetailBody (the picker's detail view, shown before argument prompts) never stated that a .php/.yml command needs a real project on disk — that fact only lived in the --help trailer, which DetailBody doesn't share. It now adds Runs locally against $WP_SITE_DIR / $TRELLIS_DIR, keyed off the same file extension executeEntry already dispatches the executor on.
  • Added @param/@return docblocks to scanner-targeted.php's six helper functions, resolving intelephense's P1132 "no type information available" warnings.
  • CHANGELOG.md updated for 5.1.3.

Changes

  • go/internal/exec/help.go / help_test.golocalSiteDependencyNote + DetailBody meta line, with tests for .php, .yml, and plain-script cases.
  • wp-cli/security/scanner-targeted.php — docblocks on color_text, output, build_file_list, scan_file, format_bytes, display_results.
  • CHANGELOG.md[5.1.3] entry.

Testing

  • go build ./...
  • go test ./internal/exec/... ./internal/catalog/... ./internal/manifest/... ./cmd/...
  • php -l wp-cli/security/scanner-targeted.php

jasperf and others added 4 commits August 5, 2026 17:23
exec.DetailBody (the block the picker shows once a command is chosen,
before prompting for arguments) never stated that a .php/.yml command
needs a real project on disk to run against — that fact only showed up
in the --help trailer (FormatWPCLIHelp/FormatHelp), which DetailBody
doesn't share. A command annotated @Runs local, like scanner-targeted,
gave no hint of this until you actually ran it and hit the
"WP_SITE_DIR is not set." prompt.

Add localSiteDependencyNote, keyed off the same file extension
executeEntry (cmd/dispatch.go) already dispatches the executor on, so
it can't drift from which executor actually runs the command.
DetailBody's meta line now reads "Runs locally against $WP_SITE_DIR"
for .php commands and "Runs locally against $TRELLIS_DIR" for .yml
playbooks, alongside the existing Requires/Platform/"Runs on the
server" facts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
color_text, output, build_file_list, scan_file, format_bytes, and
display_results had no type information for their parameters, which
intelephense flags as P1132. Add @param/@return docblocks rather than
native type hints, matching this file's existing doc-comment style —
no other script in wp-cli/ uses native type hints, and a docblock
avoids any risk of a TypeError from an unexpected runtime value.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RunsOn == "local" only distinguishes "you invoke this from your own
machine" from "server" ("you SSH onto the target and run it there
yourself") — it says nothing about whether the command's own work
stays on this machine. .yml playbooks are the sharp case:
ansible-playbook launches from $TRELLIS_DIR, but plenty of them
(database-pull, files-backup, ...) then SSH out from there to do the
actual work against a remote host, so "Runs locally against
$TRELLIS_DIR" was a wrong claim for exactly the playbooks this note
exists to flag.

Rename localSiteDependencyNote to projectDependencyNote and reuse the
"against the project at $VAR" phrasing FormatWPCLIHelp/FormatHelp
already use in their --help trailer, which makes no locality claim
either way: "Runs via WP-CLI against the site at $WP_SITE_DIR" / "Runs
via ansible-playbook against the Trellis project at $TRELLIS_DIR".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@jasperf
jasperf merged commit 7b4debf into main Aug 5, 2026
1 check passed
@jasperf
jasperf deleted the improve/scanner-targeted-help-and-types branch August 5, 2026 10:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant