twooey
df34fe8e54
- ProductSync: bsc_work.wc_product_id could go stale if a product was ever
deleted out-of-band (wp-admin, a cleanup script). wc_get_product() then
correctly detects "no product" and creates a new one, but the repoint was
gated behind `if (!$existing_id)` — which was already true, so the stale
ID never got corrected. Every future sync repeated this, one duplicate
product per run. Fixed by making the repoint unconditional (cheap,
idempotent UPDATE either way). Reproduced the exact scenario against dev
(deleted a product out-of-band, ran sync-products twice) and confirmed:
one repoint, zero duplicates, product count and per-work product count
both correct across repeated runs.
- Commands.php (sync-hardcover-tags): wp_set_object_terms() with an empty
array clears the taxonomy rather than leaving it alone — verified
directly. Hardcover legitimately returns no moods/content-warnings for
plenty of books, so a --force re-sync could silently wipe existing tags,
including anything hand-tagged. Fixed by skipping the call per-category
when that category's array is empty. Verified via a direct eval test:
pre-existing genre tag survives a sync where genre comes back empty,
mood still gets set normally.
- docker-compose.yml: two stray root-owned secrets/db_password and
secrets/db_root_password directories were already sitting on disk —
Docker auto-creating a bind-mount source as a directory from an earlier
manual `docker compose` call that ran without ENVIRONMENT exported
(reproducing the exact bug already fixed once this session). Removed
the stray dirs and changed every `${ENVIRONMENT}` in a volume mount to
`${ENVIRONMENT:?ENVIRONMENT must be set}` so Compose now hard-fails
instead of silently defaulting to empty. Verified: unset ENVIRONMENT now
fails config validation with a clear error; set, it still works.
- HARDCOVER_API_TOKEN moved to the same _FILE secrets pattern already used
for DB_PASSWORD/DB_ROOT_PASSWORD (docker-compose.yml, deploy.sh,
HardcoverAdapter.php) — it was a live, consumed secret still going
through Compose's ${VAR} interpolation, exposed to the same
mangling bug already fixed for the DB passwords, plus visible via
`docker inspect`. deploy.sh now writes secrets/<env>/hardcover_api_token
(optionally empty). Verified via deploy.sh dev + wp eval: empty file ->
is_configured() false, a real token value -> true.
- backup.sh: mariadb-dump had no --single-transaction, so a dump against a
live site would either table-lock for its duration or produce a
non-atomic/inconsistent dump. Added; verified a real dump still runs
clean and produces a valid, restorable-looking .sql.gz.
57 lines
2.5 KiB
Bash
Executable File
57 lines
2.5 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Off-host database + uploads backup (design doc §01, launch gate: "A full
|
|
# backup has been restored successfully into staging" — see restore.sh).
|
|
set -euo pipefail
|
|
|
|
ENVIRONMENT="${1:?Usage: backup.sh <staging|production>}"
|
|
export ENVIRONMENT
|
|
REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
|
|
cd "$REPO_ROOT"
|
|
|
|
ENV_FILE=".env.${ENVIRONMENT}"
|
|
# shellcheck source=lib/env.sh
|
|
source "$REPO_ROOT/deploy/lib/env.sh"
|
|
|
|
TIMESTAMP="$(date +%Y%m%d-%H%M%S)"
|
|
BACKUP_DIR="$(env_get "$ENV_FILE" BACKUP_DIR)"
|
|
BACKUP_REMOTE="$(env_get "$ENV_FILE" BACKUP_REMOTE)"
|
|
BACKUP_RETENTION_DAYS="$(env_get "$ENV_FILE" BACKUP_RETENTION_DAYS)"
|
|
BACKUP_DIR="${BACKUP_DIR:-./backups}/${ENVIRONMENT}"
|
|
mkdir -p "$BACKUP_DIR"
|
|
|
|
# See deploy.sh for why: Compose warns on any $-shaped value in --env-file
|
|
# even when unused, so DB_PASSWORD/DB_ROOT_PASSWORD are filtered out of the
|
|
# copy Compose actually sees.
|
|
COMPOSE_ENV_FILE="$(mktemp)"
|
|
trap 'rm -f "$COMPOSE_ENV_FILE"' EXIT
|
|
grep -Ev '^(DB_PASSWORD|DB_ROOT_PASSWORD)=' "$ENV_FILE" > "$COMPOSE_ENV_FILE"
|
|
|
|
COMPOSE="docker compose -p bookstore-${ENVIRONMENT} -f docker-compose.yml -f docker-compose.${ENVIRONMENT}.yml --env-file ${COMPOSE_ENV_FILE}"
|
|
|
|
echo "==> dumping database"
|
|
# --single-transaction: without it, a dump against a live site either
|
|
# table-locks for its duration (blocking writes) or, if MARIADB_USER lacks
|
|
# LOCK TABLES privilege, produces a non-atomic dump — rows written after the
|
|
# dump starts but before it reaches their table can be captured
|
|
# inconsistently with rows it already passed. InnoDB (this project's engine
|
|
# throughout) supports a consistent snapshot via a single transaction instead.
|
|
$COMPOSE exec -T db sh -c "exec mariadb-dump --single-transaction -u\"\$MARIADB_USER\" -p\"\$(cat /run/secrets/db_password)\" \"\$MARIADB_DATABASE\"" \
|
|
| gzip > "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz"
|
|
|
|
echo "==> archiving uploads"
|
|
$COMPOSE run --rm -T -u www-data wordpress tar -czf - -C /var/www/html/wp-content uploads \
|
|
> "$BACKUP_DIR/uploads-${TIMESTAMP}.tar.gz"
|
|
|
|
if [[ -n "${BACKUP_REMOTE:-}" ]]; then
|
|
echo "==> syncing to off-host storage ($BACKUP_REMOTE)"
|
|
rclone copy "$BACKUP_DIR/db-${TIMESTAMP}.sql.gz" "$BACKUP_REMOTE/${ENVIRONMENT}/"
|
|
rclone copy "$BACKUP_DIR/uploads-${TIMESTAMP}.tar.gz" "$BACKUP_REMOTE/${ENVIRONMENT}/"
|
|
else
|
|
echo "==> BACKUP_REMOTE not set — backup stayed local only; configure rclone before launch"
|
|
fi
|
|
|
|
echo "==> pruning local backups older than ${BACKUP_RETENTION_DAYS:-14} days"
|
|
find "$BACKUP_DIR" -type f -mtime "+${BACKUP_RETENTION_DAYS:-14}" -delete
|
|
|
|
echo "==> backup complete: $BACKUP_DIR"
|