You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
WordPress reports production whatever APP_ENV says #443
wp_get_environment_type() returns production on a local Pollora site whose APP_ENV is local.
Seen on a fresh skeleton (v13.35.2 + framework release/v13.35.3) under DDEV, with APP_ENV=local and APP_DEBUG=true: the WordPress environment reads production, while WP_DEBUG is true.
Why
Bootstrap::defineWordPressConstants() (src/WordPress/Bootstrap.php) defines WP_DEBUG, WP_DEBUG_DISPLAY, DISABLE_WP_CRON… but never WP_ENVIRONMENT_TYPE. WordPress then looks for a WP_ENVIRONMENT_TYPE environment variable and, finding none, falls back to production.
Why it matters
WordPress and plugins branch on wp_get_environment_type(): Site Health, update and indexing behaviour, payment gateways and caching plugins that switch to sandbox or off outside production, and core's application passwords (only allowed over plain HTTP when the environment is local). A Pollora site on a developer's machine is treated as production by all of them.
Expected
The WordPress environment follows Laravel's, unless the project sets it explicitly:
APP_ENV
WP_ENVIRONMENT_TYPE
local
local
development, dev
development
staging
staging
testing
development (WordPress has no testing type)
production, anything else
production
A wordpress.constants.WP_ENVIRONMENT_TYPE value, or a WP_ENVIRONMENT_TYPE environment variable, still wins.
Found by
The Pollora tab of pollora/debugbar (Pollora/debugbar#2), which shows the WordPress environment next to the constants.
Activity