[YvesCesar]

reset_local_user_passwords and sync_site_urls ran on every start whenever their variables were set, with no check of the environment. If WORDPRESS_LOCAL_USERS_PASSWORD or PROD_SITE_URL reached a production container (copied override, shared .env), every account got the shared password, or the database URLs were rewritten.

Changes

• Both steps only run when WP_ENVIRONMENT_TYPE is local or development. The variable is the one WordPress itself reads; when it is missing the environment is treated as production. Otherwise the entrypoint logs an error and skips the step.
• common-services.yml passes WP_ENVIRONMENT_TYPE to the container, and the development example in the README declares WP_ENVIRONMENT_TYPE: local.

Local setups that use these variables need to add WP_ENVIRONMENT_TYPE: local to their override.

Tests

tests/security/local-only-setup.bats runs the real entrypoint with a stubbed wp and checks which commands it issues: no password change and no search-replace without the variable or with production/staging, both still happen with local/development. The skip cases fail on main and pass here. bats tests/security: 23/23; ShellCheck clean.

On a fresh stack started from this branch, with the reset and URL variables set: without WP_ENVIRONMENT_TYPE the admin password and siteurl stay unchanged; with local both are applied as before.