Machine-readable output is corrupted: HTTP warning goes to stdout, so --format json is invalid JSON

Start with the two warning calls in wpa/config.py at lines 97 and 258, then reproduce against an http:// private/LAN site using the commands in the issue. Move the diagnostic output away from stdout and add a regression test for machine-readable output. Done means --format json remains parseable and --field, --ids, --count, and CSV/TSV output contain only data on stdout.

Summary

On any site configured over http:// with a private/LAN address, the warning

Warning: Using HTTP on a private/LAN address. Credentials are not encrypted in transit.

is printed to stdout, not stderr. It is therefore prepended to the payload of every
machine-readable output mode, and --format json emits invalid JSON.

Reproduction

Against a LAN site (here CT118, http://192.168.52.18), redirecting stderr away entirely:

$ wpa theme list --site ct118 --format json 2>/dev/null | python3 -c "import sys,json; json.load(sys.stdin)"
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

$ wpa theme list --site ct118 --format json 2>/dev/null | head -2
Warning: Using HTTP on a private/LAN address. Credentials are not encrypted in transit.
[

--field is corrupted the same way — the value is no longer the only thing on stdout:

$ wpa theme list --site ct118 --status active --field stylesheet 2>/dev/null
Warning: Using HTTP on a private/LAN address. Credentials are not encrypted in transit.
twentytwentyfive

2>/dev/null is in each command deliberately: it proves the text is on stdout rather than stderr.

Cause

Two bare print() calls with no file=sys.stderr:

• wpa/config.py:97
• wpa/config.py:258

Impact

--format json, --field, --ids, --count and --format csv/tsv exist to be consumed by
other programs. On LAN/HTTP sites — an environment wpa explicitly supports, and the usual shape
of a staging box — none of them can be consumed without filtering the first line, and any caller
that pipes straight into a JSON parser fails.

The warning itself is correct and worth keeping. It is diagnostic output, so it belongs on stderr,
where it stays visible to an operator and out of the data.

Suggested fix

Add file=sys.stderr to both calls. A regression test asserting that
--format json stdout parses as JSON against an http:// private-address site would keep it
from coming back — the bug is invisible over HTTPS, which is why it survived to v0.11.0.

Found by

The v0.11.0 release-gate smoke test (examples/bootstrap-site.sh) run against CT118
(wp-stage-18, WordPress on Twenty Twenty-Five) on 2026-08-12.

— SAM