Skip to content

fix: correct wpcli invocation (--profile cli + safe arg passing in kiqr wp) - #24

Merged
kjellberg merged 1 commit into
kiqr:mainfrom
kjellbergzoey:fix/wpcli-invocation
Jun 7, 2026
Merged

fix: correct wpcli invocation (--profile cli + safe arg passing in kiqr wp)#24
kjellberg merged 1 commit into
kiqr:mainfrom
kjellbergzoey:fix/wpcli-invocation

Conversation

@kjellbergzoey

Copy link
Copy Markdown
Contributor

Two related fixes to how WP-CLI is invoked.

(a) Enable the cli profile for the wpcli service

buildWpCliArgs (src/lib/wpcli.ts) returned:

['compose', '-f', composePath, 'run', '--rm', '-T', 'wpcli', ...wpArgs]

but the wpcli compose service declares profiles: ['cli'] (see src/providers/BitnamiRuntimeProvider.ts). On Docker Compose v2, a profiled service targeted by run may not start unless its profile is enabled. We now insert --profile cli before the run subcommand (where it takes effect):

['compose', '-f', composePath, '--profile', 'cli', 'run', '--rm', '-T', 'wpcli', ...wpArgs]

This also fixes kiqr db dump / db restore, which route through buildWpCliArgs via spawnWpCli. The flag is safe to add regardless of Compose version.

(b) Safe argument passing in kiqr wp

src/commands/wp.tsx built a shell command string and ran it with execSync:

execSync(`docker compose -f "${composePath}" run --rm wpcli ${rawArgs.join(' ')}`)

Joining args into a shell string mangles values containing spaces, quotes, or special characters (e.g. kiqr wp post create --post_title="Hello World"). It now uses a new array-based, shell-free helper runWpCliInherit (added to wpcli.ts), which spawns docker with an args array and inherits stdio so output still streams to the terminal. The raw process args are forwarded verbatim, and the no-args --help path is preserved. The readProjectConfig() call is wrapped in try/catch so an invalid config surfaces a clear message instead of crashing.

Tests

tests/lib/wpcli.test.ts updated to expect --profile cli, assert the flag precedes run, and confirm args are passed verbatim as separate array elements.

Smoke test note

The --profile cli behavior is Docker-Compose-version-dependent. No Docker daemon was available in this environment, so this should get a quick real kiqr db dump smoke test on a Docker machine to confirm. The flag is safe to add regardless.

Gates

  • npm run typecheck
  • npm test ✅ (194 passed)
  • npm run build
  • npm run lint

🤖 Generated with Claude Code

…qr wp)

(a) buildWpCliArgs now inserts `--profile cli` before the `run` subcommand.
The wpcli compose service declares `profiles: ['cli']`
(BitnamiRuntimeProvider), and on Docker Compose v2 a profiled service
targeted by `run` may not start unless its profile is enabled. The flag is
positioned before `run` so it takes effect, and is safe regardless of the
Compose version. This also covers `kiqr db dump`/`db restore`, which go
through buildWpCliArgs via spawnWpCli.

(b) `kiqr wp` previously built a shell string and passed it to execSync,
which mangled arguments containing spaces/quotes/special characters (e.g.
`--post_title="Hello World"`). It now uses a new array-based,
shell-free helper (runWpCliInherit) that spawns docker with an args array
and inherits stdio so output still streams to the terminal. The raw
process args are forwarded verbatim, and the no-args `--help` path is
preserved. The readProjectConfig() call is wrapped in try/catch so an
invalid config surfaces a clear message instead of crashing.

Tests for buildWpCliArgs are updated to expect `--profile cli`, assert the
flag precedes `run`, and confirm args are passed verbatim.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@kjellberg
kjellberg merged commit 4405e38 into kiqr:main Jun 7, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants