wp-init: fail fast on wrong DB password, strict theme activation

- The 'Waiting for database' loop spun forever when the .env password did
  not match the db_data volume; it now aborts with exit 1 and explains how
  to recover (put the old password back; README 'Passwords' for a real
  change), plus a 5-minute timeout for a dead database.
- Theme presence is checked on disk instead of via wp-cli (which needs the
  database), activation is always attempted and fatal on failure, so the
  script can no longer delete the active theme and report success.
- README gains a 'Passwords' section documenting the correct password-change
  procedure (ALTER USER in the running DB, then .env).

README.md

@@ -152,6 +152,26 @@ Tudo o que é do usuário fica em **volumes**, não no container:
 
 `docker compose down` (sem `-v`) preserva tudo; só `down -v` recria do zero. Para pular atualizações numa reinicialização, use `WP_SKIP_UPDATES=1` no `.env`.
 
+### Senhas
+
+A senha do banco é gravada **dentro do volume `db_data` na primeira instalação**. Trocar `WORDPRESS_DB_PASSWORD` ou `MARIADB_ROOT_PASSWORD` no `.env` depois disso **não** atualiza o banco — o WordPress perde a conexão (`Error establishing a database connection`) e o setup aborta com erro em vez de reinstalar por cima.
+
+Para voltar ao normal, devolva a senha original no `.env` e reinicie (`docker compose up -d`).
+
+Para trocar a senha de verdade, altere-a nos dois lugares, nessa ordem:
+
+```sh
+# 1. No banco em execução (troque NOVA_SENHA pela senha nova):
+docker compose exec db mariadb -u root -p"$MARIADB_ROOT_PASSWORD" \
+  -e "ALTER USER 'wordpress'@'%' IDENTIFIED BY 'NOVA_SENHA'; FLUSH PRIVILEGES;"
+
+# 2. No .env:
+WORDPRESS_DB_PASSWORD=NOVA_SENHA
+
+# 3. Reinicie:
+docker compose up -d
+```
+
 ## Deploy
 
 O tema está preparado para deploy em ambientes WordPress padrão (VPS, shared hosting, WP Engine, Kinsta, etc.).

docker/wp-init.sh

@@ -38,8 +38,34 @@ warn() {
 }
 
 # ─── Wait for dependencies ───────────────────────────────────────────────────
+# The loop fails fast on wrong credentials instead of spinning forever: when
+# the password in .env does not match the one stored in the db_data volume,
+# `db check` answers "Access denied" immediately, and waiting longer changes
+# nothing. Any other failure (server down, still starting) keeps waiting, with
+# a timeout so a dead database cannot hang the boot silently.
 log "Waiting for database..."
-until wp_run db check >/dev/null 2>&1; do
+DB_TRIES=0
+while true; do
+  if DB_WAIT_OUT="$(wp_run db check 2>&1)"; then
+    break
+  fi
+  if printf '%s' "$DB_WAIT_OUT" | grep -q "Access denied"; then
+    echo "[wpcli] ERROR: the database rejected the credentials from .env." >&2
+    echo "[wpcli]" >&2
+    echo "[wpcli] The database volume keeps the password used on the first run." >&2
+    echo "[wpcli] Changing WORDPRESS_DB_PASSWORD or MARIADB_ROOT_PASSWORD in" >&2
+    echo "[wpcli] .env alone does not update it, so WordPress stops connecting." >&2
+    echo "[wpcli]" >&2
+    echo "[wpcli] Put the original password back in .env and restart the containers." >&2
+    echo "[wpcli] (To really change it, see 'Passwords' in README.md.)" >&2
+    exit 1
+  fi
+  DB_TRIES=$((DB_TRIES + 1))
+  if [ "$DB_TRIES" -ge 150 ]; then
+    echo "[wpcli] ERROR: the database did not become ready in time." >&2
+    printf '%s\n' "$DB_WAIT_OUT" | tail -3 >&2
+    exit 1
+  fi
   sleep 2
 done
 
@@ -331,13 +357,21 @@ if [ -n "$REDIS_HOST" ]; then
 fi
 
 # ─── Theme (both modes) ──────────────────────────────────────────────────────
-if ! wp_run theme is-installed "$WP_THEME" 2>/dev/null; then
+# Checked on disk, not with `wp theme is-installed`: in an existing install
-  warn "theme '$WP_THEME' is not installed in wp-content/themes — skipping activation."
+# that check needs the database, and any hiccup made the script skip the theme.
-else
+if [ ! -f "$WP_PATH/wp-content/themes/$WP_THEME/style.css" ]; then
-  if ! wp_run theme is-active "$WP_THEME" 2>/dev/null; then
+  echo "[wpcli] ERROR: theme '$WP_THEME' is missing from wp-content/themes." >&2
-    log "Activating $WP_THEME theme..."
+  echo "[wpcli] It is part of the repository: run 'git checkout -- wp-content/themes'" >&2
-    wp_run theme activate "$WP_THEME" || warn "could not activate theme '$WP_THEME'"
+  echo "[wpcli] on the host, then restart the containers." >&2
-  fi
+  exit 1
+fi
+
+# Always attempted (harmless when already active) and fatal on failure: a site
+# without its theme renders broken pages while the script reports success.
+log "Activating $WP_THEME theme..."
+if ! wp_run theme activate "$WP_THEME"; then
+  echo "[wpcli] ERROR: could not activate theme '$WP_THEME'." >&2
+  exit 1
 fi
 
 # Only project themes stay available: every other theme (the WordPress defaults)