Three small robustness gaps in import-page-draft, found while importing page drafts on Sep 15, 2026 (asset cache 5.23.1, same code on main @ 41b7d96).
Context: the run failed because of a caller-side mistake. Our own docs gave the usage as <draft> <page-id> [local|production|both] and dropped site-name, so local was read as the site name. The script's documented signature is correct. The points below would have made that mistake fail loudly and cleanly, and cover a related leak.
wp-ops import-page-draft on-call-wordpress-developer-service-page.html 4625 local
...
bash: line 1: cd: /srv/www/local/current: No such file or directory
1. No warning when site-name looks like an environment
wp-cli/content-creation/import-page-draft.sh:54-55
SITE_NAME="${3:-example.com}"
ENVIRONMENT="${4:-local}"If arg 3 is local, production or both, it is almost certainly an environment passed in the wrong position. The script then builds SERVER_PATH=/srv/www/local/current and only fails later, inside trellis vm shell.
Suggestion: exit early with an error like: site-name "local" looks like an environment — usage: <draft> <page-id> [site-name] [environment] [template]. Optionally also check that $SITE_DIR/the VM actually has /srv/www/$SITE_NAME before copying anything.
2. A failed run leaves temp files behind
:39 has set -e and there is no trap. The cleanup rm -f "$SITE_DIR/$TMP_NAME" at :107 only runs on success. After the failure above, four tmp-import-<id>-<ts>.html files were left in the Bedrock site root, next to web/. The same applies to /tmp/$TMP_NAME locally, and presumably to the scp'd copy under $SERVER_PATH (:115) when a production run fails after upload.
Suggestion: trap 'rm -f "$STRIPPED_FILE" "$SITE_DIR/$TMP_NAME"' EXIT, plus a best-effort remote rm for production runs.
3. Header stripping only handles {{-- --}} lines
:82
grep -v '^{{--' "$DRAFT_FILE" > "$STRIPPED_FILE"Some drafts also carry blog-post-style HTML comment headers:
<!-- SUGGESTED POST SLUG: /services/fse-block-theme-development/ -->
<!-- SUGGESTED META (max 155 chars): ... -->
<!-- SEO FRAMEWORK FIELDS (set manually in editor — not part of block content below) -->
<!-- NOTE: ... -->
These aren't block delimiters, so they get stored in post_content. They're invisible on the page, but they leak internal SEO notes into the page source and show as a stray classic/freeform block in the editor. This happened on a production page on Sep 15 (6 lines, fixed by hand).
Suggestion: strip non-block header comments too, e.g. grep -vE '^(\{\{--|<!-- (SUGGESTED|SEO FRAMEWORK|NOTE)\b)'. Stripping only leading header lines before the first <!-- wp: would be even safer. Related: multi-line {{-- ... --}} blocks only lose their first line; a block-aware strip would cover that as well.
Three small robustness gaps in
import-page-draft, found while importing page drafts on Sep 15, 2026 (asset cache 5.23.1, same code onmain@ 41b7d96).Context: the run failed because of a caller-side mistake. Our own docs gave the usage as
<draft> <page-id> [local|production|both]and droppedsite-name, solocalwas read as the site name. The script's documented signature is correct. The points below would have made that mistake fail loudly and cleanly, and cover a related leak.1. No warning when
site-namelooks like an environmentwp-cli/content-creation/import-page-draft.sh:54-55If arg 3 is
local,productionorboth, it is almost certainly an environment passed in the wrong position. The script then buildsSERVER_PATH=/srv/www/local/currentand only fails later, insidetrellis vm shell.Suggestion: exit early with an error like:
site-name "local" looks like an environment — usage: <draft> <page-id> [site-name] [environment] [template]. Optionally also check that$SITE_DIR/the VM actually has/srv/www/$SITE_NAMEbefore copying anything.2. A failed run leaves temp files behind
:39hasset -eand there is notrap. The cleanuprm -f "$SITE_DIR/$TMP_NAME"at:107only runs on success. After the failure above, fourtmp-import-<id>-<ts>.htmlfiles were left in the Bedrock site root, next toweb/. The same applies to/tmp/$TMP_NAMElocally, and presumably to the scp'd copy under$SERVER_PATH(:115) when a production run fails after upload.Suggestion:
trap 'rm -f "$STRIPPED_FILE" "$SITE_DIR/$TMP_NAME"' EXIT, plus a best-effort remotermfor production runs.3. Header stripping only handles
{{-- --}}lines:82Some drafts also carry blog-post-style HTML comment headers:
These aren't block delimiters, so they get stored in
post_content. They're invisible on the page, but they leak internal SEO notes into the page source and show as a stray classic/freeform block in the editor. This happened on a production page on Sep 15 (6 lines, fixed by hand).Suggestion: strip non-block header comments too, e.g.
grep -vE '^(\{\{--|<!-- (SUGGESTED|SEO FRAMEWORK|NOTE)\b)'. Stripping only leading header lines before the first<!-- wp:would be even safer. Related: multi-line{{-- ... --}}blocks only lose their first line; a block-aware strip would cover that as well.