#!/bin/bash
set -euo pipefail
# Overlay le thème ENFANT baké, puis délègue à l'entrypoint base WP Reactor
# (qui overlaye le thème parent + plugin et lance WordPress).
WP_CONTENT="${WP_CONTENT_DIR:-/var/www/html/wp-content}"
if [ -d /opt/__PROJECT_NAME__/theme ]; then
	echo "[__PROJECT_NAME__-entrypoint] overlay thème enfant -> $WP_CONTENT/themes/__PROJECT_NAME__"
	rm -rf "$WP_CONTENT/themes/__PROJECT_NAME__"
	mkdir -p "$WP_CONTENT/themes"
	cp -a /opt/__PROJECT_NAME__/theme "$WP_CONTENT/themes/__PROJECT_NAME__"
	chown -R www-data:www-data "$WP_CONTENT/themes/__PROJECT_NAME__" 2>/dev/null || true
fi

# --- Provisioning automatique (WP_AUTO_BOOTSTRAP=1) --------------------------
# Remplace le `docker exec -u 33:33 … bootstrap.sh` manuel de docs/deploy.md.
#
# En tâche de fond, car bootstrap.sh a besoin d'un WordPress qui tourne : il
# attend l'arrivée du core (que l'entrypoint officiel copie juste après) puis la
# base. On ne peut donc ni le lancer avant `exec`, ni bloquer dessus.
#
# En www-data (uid 33), jamais en root : wp-cli écrit dans wp-content, et des
# fichiers appartenant à root y rendent les plugins ingérables depuis l'admin.
# C'est la raison du `-u 33:33` documenté pour la version manuelle.
#
# Un échec ne doit pas empêcher WordPress de démarrer : il est journalisé, et le
# script étant idempotent, le démarrage suivant retente.
BOOTSTRAP=/usr/local/bin/__PROJECT_NAME__-bootstrap.sh
if [ "${WP_AUTO_BOOTSTRAP:-0}" = "1" ] && [ -x "$BOOTSTRAP" ]; then
	echo "[__PROJECT_NAME__-entrypoint] WP_AUTO_BOOTSTRAP=1 — provisioning en tâche de fond"
	(
		if [ "$(id -u)" = "0" ]; then
			su -s /bin/sh www-data -c "$BOOTSTRAP"
		else
			"$BOOTSTRAP"
		fi
	) || echo "[__PROJECT_NAME__-entrypoint] bootstrap en échec — nouvelle tentative au prochain démarrage" &
fi

exec wp-reactor-entrypoint.sh "$@"