mainwp-cli 0.4.3

What's changed

Homebrew tap has been migrated from oscarhugopaz/homebrew-mainwp-cli to the canonical tap name oscarhugopaz/tap (repository: oscarhugopaz/homebrew-tap).

Install

brew install oscarhugopaz/tap/mainwp-cli

For existing users

If you previously installed with:

brew tap oscarhugopaz/mainwp-cli
brew install mainwp-cli

untap the old repo and reinstall so Homebrew picks up the new tap on the next brew update:

brew untap oscarhugopaz/mainwp-cli
brew tap oscarhugopaz/tap
brew reinstall mainwp-cli

The formula, binary, and version (0.4.3) are unchanged. Full diff: v0.4.2...v0.4.3

v0.4.2

Fixes skill installation so mainwp skill install --global installs only into ~/.agents/skills/, preserves existing skills, and cannot be widened accidentally by combining it with --all or --agent.

v0.4.1

Patch release after the mainwp-cli rename.

Changes:

• Updates README install/upgrade references to use mainwp-cli.
• Updates the mainwp-cli skill troubleshooting instructions to use brew upgrade mainwp-cli.
• Updates scripts/release.sh to operate on Formula/mainwp-cli.rb, uninstall mainwp-cli during --brew-test, and commit tap updates as mainwp-cli <version>.
• Updates the Homebrew tap README, formula comment, and audit workflow for the mainwp-cli formula name.

Validation:

• 61/61 smoke tests passing.
• ruby -c Formula/mainwp-cli.rb: OK.
• brew audit mainwp-cli: OK.

Install:

brew tap oscarhugopaz/mainwp-cli
brew install mainwp-cli
mainwp --version

v0.4.0

Breaking change release - renames the Homebrew package from
`mainwp` to `mainwp-cli`, and the config directory from
`/.config/mainwp/` to `/.config/mainwp-cli/`. The CLI
binary name (`mainwp`) is unchanged, so `mainwp sites list`,
`mainwp --version`, `mainwp config`, etc. all keep working
exactly as before.

Migration

Existing users need to do:

```bash
brew uninstall mainwp
brew install mainwp-cli

re-create the profile (the old config is not read)

mainwp init
```

If you have multiple profiles, you can copy the old config
into the new location instead of re-creating it from scratch:

```bash
mkdir -p ~/.config/mainwp-cli
cp ~/.config/mainwp/config.json ~/.config/mainwp-cli/config.json
chmod 600 ~/.config/mainwp-cli/config.json
```

Why a clean cut

A fallback path that read the old `/.config/mainwp/` and
wrote the new `/.config/mainwp-cli/` was considered and
explicitly rejected: the per-profile permission setup, the
chmod 600 contract, and any backups all need to follow the same
root. A dual-path setup would have ambiguous behavior the first
time the user runs `mainwp init`.

What is unchanged

• The CLI binary on `$PATH` is still `mainwp`. All commands,
  flags, profiles, and env-var overrides work as in 0.3.6.
• All 61 smoke tests pass.
• The skill bundle (skills/mainwp-cli/SKILL.md) has been
  updated to mention `brew install mainwp-cli`.

```
brew install mainwp-cli
mainwp --version
mainwp 0.4.0
```

v0.3.6

Patch release. Wires up the missing `--global` flag on
`mainwp skill install`.

Before this fix, `mainwp skill install --global` failed with
`Unknown option: --global (run: mainwp skill install --help)`
because the case statement in `cmd_skill_install` only knew
about `--all` and `--agent NAME`. The user reasonably
expected `--global` as a shortcut for the most common install
target (`~/.agents/skills/`, the agent name literally called
`global` in the help text and the picker).

After this change, `--global` appends `global` to the agents
array, which is the same code path `--agent global` would
take. The help text is updated to document the new flag.

`mainwp skill install --global` is now equivalent to
`mainwp skill install --agent global`. `--all` and
`--agent NAME` are unchanged.

61 smoke tests, all passing. Upgrade with
`brew update && brew upgrade mainwp`.

v0.3.5

Patch release. Polishes the list-rendering path: empty columns
are now dropped automatically.

`mainwp clients list` was hardcoding a Status column that the
API does not return for clients, so the table rendered with a
Status header over a column of empty cells. The user had to
know the MainWP clients endpoint does not return a status field
in order to interpret the table.

After this change, `_mainwp_render_list` walks every row
once, collects each column's value, and drops any column whose
values are all empty. The table header and the row content
shrink to match.

`mainwp --plain clients list --no-input` now prints:
ID,Name,Email
5 CREA elianaeiwa@gmail.com
4 Dynamic Dutch info@dynamicdutch.com
1 Jazmín Gonz... shop@jazmingonzalez.pe
3 Luis Cavero lcaverop@yahoo.es

`sites list` still prints Status because every site row has
`status: "connected"`. `users list`, `tags list`, and the
other list endpoints print whatever columns actually have data.

Also: refreshed the `skills/mainwp-cli/SKILL.md` bundle to 0.3.5
with the changes accumulated since 0.3.0 (the bundle had not
been updated with the v0.3.1-0.3.4 fix waves). Agents that load
this skill now have an accurate description of:

• `mainwp skill install` (new subcommand for cross-agent
  skill propagation)
• the `--profile` global flag and profile switching
• `MAINWP_URL` / `MAINWP_API_KEY` env-var precedence
• TTY-driven output mode (gum vs plain) and the `--json`
  vs `--plain` flags
• the four response envelope shapes the API uses
• the common failure modes for `init` and list endpoints

61 smoke tests, all passing.

v0.3.4

Patch release. Fixes four classes of failure surfaced by running
every command against a real MainWP Dashboard.

1. Default gum output was unimplemented (lib/output.sh)
   mainwp_render_table had branches for json and plain, but
   the default 'table' branch (with gum installed) fell straight
   through to return 0 without printing anything. Wire up
   gum table --separator ';' for the styled case, and wrap the
   gum call in a try-or-fallback so any gum failure silently
   degrades to plain text.

2. gum broke on TTY-less shells (lib/output.sh)
   gum table tries to open /dev/tty for its alternate-screen
   buffer and exits non-zero, swallowing the output. The fix:
   only attempt the gum path when [[ -t 1 ]]. The same gate
   applies to mainwp_render_object, which used column -t and
   died with 'line too long' on any payload containing a long
   value (URL, embedded JSON). Replace with a printf-width
   formatter that has no line-length limit.

3. List endpoints with array values printed multi-line junk
   (lib/output.sh). The plain and gum paths now use
   .permissions | join(", ") so
   permissions: ["Read", "Write & Delete"] becomes a single
   comma-separated cell that fits one row.

4. The API has at least four response shapes; the extractor
   only handled one (lib/commands/_common.sh). The new
   _mainwp_extract_list handles:

   • a bare array [a, b]
   • {data: [a, b]} unwrap
   • {data: {k: [users]}} (e.g. /users) recurse
   • {k: obj, k: obj, ...} (e.g. /tags) flatten
     An earlier revision also embedded the jq program inside
     $'...\n\t...', which under certain quoting combinations left
     the \n and \t markers literal and made jq silently return
     empty. Use one-line jq programs on stdin to avoid the trap.

In addition:

• lib/api.sh: mainwp_api_get and mainwp_api_delete no
  longer have an implicit body argument. Their signatures
  are mainwp_api_get path extras... where every extra
  positional is treated as a query-string pair. Same root
  cause as the earlier init per_page=1 bug: the third
  positional was the body, not a query arg, and GET endpoints
  were silently treating the query filter as the request body
  and returning 400.
• lib/commands/users.sh: cmd_users_list was bypassing
  the extractor entirely. Now it goes through
  _mainwp_extract_list, so users show up as a real table
  with a site column.
• lib/commands/sites.sh: _mainwp_extract_sites is now
  a thin shim around _mainwp_extract_list.

Verified end-to-end against the real dashboard (26/27 read
endpoints passing; the one remaining failure, posts list --websites 45, is a server-side HTTP 500 and is not a CLI
issue). 61 smoke tests, all passing.

v0.3.3

Patch release. Fixes three latent bugs that only surface against
a real MainWP Dashboard that returns typical-sized JSON. All three
were uncovered by pointing the CLI at a production dashboard for
the first time.

1. Connectivity check was always failing (lib/commands/init.sh)
   mainwp_api_get /sites/basic per_page=1 passed per_page=1 as
   the request body, not as a query parameter, so curl ended up
   doing GET /sites/basic with body='per_page=1'. MainWP rejected
   it with HTTP 400 and the init wizard reported
   "Connectivity check failed" even with a perfectly valid URL and
   key. Fix: pass an empty body and per_page=1 as an extra arg.
   mainwp_api_get /sites/basic "" "per_page=1"

2. sites count always showed 0 (lib/commands/sites.sh)
   The MainWP /sites/count endpoint returns {"count":N} rather
   than the {total} / {data:{total}} shapes the CLI was
   looking for. The jq path fell through to the 0 fallback. Add
   .count (and .data.count) to the lookup chain.

3. SIGPIPE killed the script on any list endpoint (lib/output.sh)
   mainwp_render_table used a pipe to read the first byte of the
   payload:
   first="$(printf '%s' "$input" | head -c 1)"
   With multi-KB JSON, head exits after one byte and printf gets
   SIGPIPE on the next write. With set -o pipefail that aborted
   the whole script with exit 141 and no output. Switch to
   parameter expansion: ${input:0:1}. No pipe, no signal, no race.

After the fixes the full flow works against a real dashboard:
```
$ mainwp init
✓ Profile 'default' saved.
✓ Connected to https://main.carnaval.studio
==> Dashboard reports 3 site(s) (showing first page only).

$ mainwp sites count
==> Connected sites: 3

$ mainwp --plain sites list
ID,Name,URL,Status
45 cusconatureadventure.com https://cusconatureadventure.com/ connected
44 dynamicdutch.com/ https://dynamicdutch.com/ connected
41 jazmingonzalez.pe https://jazmingonzalez.pe/ connected
```

61 smoke tests, all passing. Upgrade with
`brew update && brew upgrade mainwp`.

v0.3.2

Patch release. Fixes two latent bugs in the command dispatcher.

1. `mainwp api-keys` was crashing with
   `✗ Command 'api-keys' has no entry point.`

   Root cause: bin/mainwp looked up the entry-point function as
   `cmd_api-keys` (with a hyphen), but bash function names cannot
   contain hyphens - the function is defined as `cmd_api_keys`
   in the file. The help lookup had already done the
   ${cmd//-/_} translation; the main dispatch had not.

2. ` --help` was silently broken for 10 of the 16 commands
   (api-keys, clients, costs, monitoring, pages, posts, settings,
   tags, updates, users). The other six worked. The cause:
   `_mainwp_parse_common_flags` normalises `--help` to the
   literal string `help` in REMAINING, but those 10 commands only
   matched the case pattern `-h | --help` - the raw flag, not
   the normalised `help`. Three commands (sites, skill, deps)
   already had the correct `-h | --help | help` pattern; the
   others did not.

Both bugs were uncovered while testing v0.3.1. The smoke suite
now has a regression test that exercises ` --help` for
every command, so this category of breakage is caught at CI time
from now on.

61 smoke tests, all passing. Upgrade with
`brew update && brew upgrade mainwp`.

v0.3.1

Patch release. Fixes a critical bug in mainwp init (and
mainwp config set ...) where the active profile never received
its url, api_key, and api_path.

Root cause was two compounding bugs in lib/config.sh:

1. mainwp_config_set_field built a jq expression that read
   .url from the document root instead of writing to
   .profiles[$p].url. The new value was passed via --arg v
   but never referenced in the expression, so every set call
   wrote the literal string null to the config file.
2. mainwp_config_set_active declared local cfg="$1" and
   required a positional argument, but the init command called
   it with no arguments. Combined with the broken set_field,
   the visible result was set -u: $1: unbound variable from
   inside the function followed by a config file containing
   only {"active": "default"}.

After the fix, mainwp init stores the profile correctly and
mainwp config get round-trips the values.

Also: tests/smoke.sh now sandboxes $HOME to a temp dir for
the duration of the run. A previous run of the test suite had
polluted the real ~/.config/mainwp/config.json with the
broken null payload (same root cause); that file is wiped.
The sandbox makes the suite safe to run on a developer machine
that has a real MainWP Dashboard.

45 smoke tests, all passing. Upgrade with
`brew update && brew upgrade mainwp`.