Fix pressbooks.sh: move proxy/Prince/DocRaptor config out of wp-config.php

WP-CLI's Runner does its own restricted, line-level parsing of
wp-config.php to pull bootstrap constants without a full WordPress load,
and it only tolerates plain define(...) statements — the previous fix's
"if (file_exists(...)) { require ...; }" line (routed in via
WORDPRESS_CONFIG_EXTRA) made every wp-cli command fail with a cryptic
"PHP Parse error ... eval()'d code ... unexpected end of file",
regardless of whether the required file actually existed.

Moved the X-Forwarded-Proto shim and the PB_PRINCE_COMMAND/
DOCRAPTOR_API_KEY defines into a WordPress must-use plugin
(wp-content/mu-plugins/), which loads through WordPress's normal plugin
bootstrap rather than wp-cli's special wp-config.php pre-parser — this
sidesteps both that bug and the earlier Compose .env-interpolation bug
in the same stroke, since nothing here touches wp-config.php or .env at
all anymore. Dropped the now-unnecessary extra-config.php bind mount
from the compose file and every wp-cli invocation to match.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P1Xynq3mBwtH45f8bTDfta
This commit is contained in:
Claude
2026-08-31 02:40:23 +00:00
parent a4d33f6afd
commit 5e281e3d11
+26 -35
View File
@@ -318,7 +318,7 @@ _pressbooks_install_plugins_and_themes() {
# probe fail *silently* and falls through to exec-ing the raw
# subcommand as if it were a binary ("core: not found") instead of
# surfacing the real error.
_pb_wpcli() { docker run --rm --network "$_net" -v "${_dir}/html:/var/www/html" -v "${_dir}/extra-config.php:/usr/local/etc/pressbooks/extra-config.php:ro" --env-file "${_dir}/.env" wordpress:cli wp "$@"; }
_pb_wpcli() { docker run --rm --network "$_net" -v "${_dir}/html:/var/www/html" --env-file "${_dir}/.env" wordpress:cli wp "$@"; }
local _plugin_url _book_url _aldine_url _publisher_url
_plugin_url="$(_pressbooks_latest_zip_url pressbooks)"
@@ -465,25 +465,35 @@ PHPINI
# X-Forwarded-Proto — behind Caddy (which terminates TLS and proxies
# plain HTTP to this container) that reads as "never HTTPS," sending
# wp-admin into a login/redirect loop the moment Caddy is wired up.
# This file is `require`d from wp-config.php via WORDPRESS_CONFIG_EXTRA
# below rather than passing the PHP itself through that env var: Compose
# interpolates $VAR-looking tokens found INSIDE .env file values, not
# just inside docker-compose.yml — confirmed live, a raw $_SERVER
# sitting in .env gets silently blanked to a bare "_SERVER" (with a
# "variable is not set" warning) before the container ever sees it, and
# escaping it as $$_SERVER doesn't collapse back to a single $ for an
# env_file-sourced value the way it does for a plain environment: entry
# — it would reach PHP as a broken "$$_SERVER" variable-variable
# instead. A bind-mounted file sidesteps the whole thing: nothing in it
# ever passes through Compose's .env parser.
cat > extra-config.php << 'PHPEXTRA'
#
# This lives in a must-use plugin (wp-content/mu-plugins/, autoloaded by
# WordPress on every request, no activation needed) rather than in
# wp-config.php via WORDPRESS_CONFIG_EXTRA — two real, confirmed-live
# problems with the wp-config.php route, in order of discovery:
# 1. Compose interpolates $VAR-looking tokens found INSIDE .env file
# values too, not just inside docker-compose.yml — a raw $_SERVER
# sitting in .env got silently blanked to a bare "_SERVER" before
# the container ever saw it.
# 2. Routing it through a bind-mounted file and a wp-config.php
# `require` line (this repo's first fix for #1) traded that bug for
# a worse one: wp-cli's Runner does its own restricted, line-level
# parsing of wp-config.php to pull out bootstrap constants without
# a full WordPress load, and it can't handle anything past a plain
# define(...) statement — an if(){ require ...; } line made *every*
# wp-cli command in this script fail with a cryptic
# "PHP Parse error ... eval()'d code ... unexpected end of file".
# mu-plugins load through WordPress's normal plugin bootstrap, not
# wp-cli's special wp-config.php pre-parser, so this sidesteps both
# issues entirely — nothing here ever touches wp-config.php or .env.
mkdir -p html/wp-content/mu-plugins
cat > html/wp-content/mu-plugins/pressbooks-extra-config.php << 'PHPEXTRA'
<?php
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
PHPEXTRA
[[ "$INSTALL_PRINCE" =~ ^[Yy]$ ]] && echo "define('PB_PRINCE_COMMAND', '/usr/local/bin/prince');" >> extra-config.php
[ -n "$DOCRAPTOR_KEY" ] && echo "define('DOCRAPTOR_API_KEY', '$DOCRAPTOR_KEY');" >> extra-config.php
[[ "$INSTALL_PRINCE" =~ ^[Yy]$ ]] && echo "define('PB_PRINCE_COMMAND', '/usr/local/bin/prince');" >> html/wp-content/mu-plugins/pressbooks-extra-config.php
[ -n "$DOCRAPTOR_KEY" ] && echo "define('DOCRAPTOR_API_KEY', '$DOCRAPTOR_KEY');" >> html/wp-content/mu-plugins/pressbooks-extra-config.php
# Prince license file, if provided, is bind-mounted rather than baked
# into the image — keeps a personal/purchased license out of the image
@@ -582,7 +592,6 @@ services:
volumes:
- ./html:/var/www/html
- ./uploads-ini.d/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini:ro
- ./extra-config.php:/usr/local/etc/pressbooks/extra-config.php:ro
${PRINCE_LICENSE_VOLUME} ports:
- "${WEB_PORT}:80"
networks:
@@ -612,21 +621,6 @@ PBCOMPOSE
[ -n "$WP_DB_PASS" ] || WP_DB_PASS="$(generate_password 24)"
[ -n "$WP_DB_ROOT_PASS" ] || WP_DB_ROOT_PASS="$(generate_password 32)"
# Loads the file written above — see the comment there for why the PHP
# itself doesn't live directly in this env var. This line has no "$" in
# it at all, so it can't run into Compose's .env interpolation.
#
# Guarded with file_exists rather than a bare require: this same
# wp-config.php (baked once, on the persistent html/ volume) is also
# loaded by every ephemeral "docker run wordpress:cli ..." wp-cli
# invocation below, which only mounts html/ itself — a bare require
# here would fatal in any such container unless it also mounts
# extra-config.php at this exact path. Confirmed live: that fatal was
# swallowing wp-cli's own internal "is this a valid subcommand" probe,
# so "core install" ran as a literal, nonexistent "core" binary instead
# of being handed to wp-cli at all ("core: not found").
local _CONFIG_EXTRA="if (file_exists('/usr/local/etc/pressbooks/extra-config.php')) { require '/usr/local/etc/pressbooks/extra-config.php'; }"
backup_if_exists .env
cat > .env << PBENV
TZ=$TZ_VAL
@@ -643,7 +637,6 @@ WORDPRESS_DB_HOST=$DB_CONTAINER
WORDPRESS_DB_NAME=pressbooks
WORDPRESS_DB_USER=pressbooks
WORDPRESS_DB_PASSWORD=$WP_DB_PASS
WORDPRESS_CONFIG_EXTRA="$_CONFIG_EXTRA"
# Only consulted by wp-cli during initial setup below, not read by the
# wordpress:apache image itself.
@@ -674,7 +667,7 @@ PBENV
done
# "wp" spelled out explicitly — see _pb_wpcli's comment above for why.
_wpcli() { docker run --rm --network "$WP_NET" -v "$DIR/html:/var/www/html" -v "$DIR/extra-config.php:/usr/local/etc/pressbooks/extra-config.php:ro" --env-file "$DIR/.env" wordpress:cli wp "$@"; }
_wpcli() { docker run --rm --network "$WP_NET" -v "$DIR/html:/var/www/html" --env-file "$DIR/.env" wordpress:cli wp "$@"; }
log_info "Running wp-cli core install..."
if ! _wpcli core install \
@@ -686,7 +679,6 @@ PBENV
--skip-email; then
log_error "wp-cli core install failed — WordPress may not have been ready yet. Retry manually:"
log_error " docker run --rm --network $WP_NET -v $DIR/html:/var/www/html \\"
log_error " -v $DIR/extra-config.php:/usr/local/etc/pressbooks/extra-config.php:ro \\"
log_error " --env-file $DIR/.env wordpress:cli wp core install ..."
return 1
fi
@@ -791,7 +783,6 @@ refreshes the Pressbooks plugin/themes to their latest release.
## wp-cli
\`\`\`bash
docker run --rm --network $WP_NET -v $DIR/html:/var/www/html \\
-v $DIR/extra-config.php:/usr/local/etc/pressbooks/extra-config.php:ro \\
--env-file $DIR/.env wordpress:cli wp <command>
\`\`\`