In an attempt to improve on maintainability when dealing with multiple Composer based WordPress instances, I am moving config related code from wp-config.php, Bedrock’s config/ directory, custom plugin, and theme code to a dedicated Composer package called EnvPress. It uses a “standard set” of environment variables to configure a WordPress instance, from constants usually found in wp-config.php, to backing services like SMTP, that usually are configured later using WordPress hooks.
After testing the package internally in multiple projects I’d like to bring it to your attention to get outside feedback. Is the concept of a shared Composer package to configure WordPress interesting, in general? Is the “standard set” of env vars using intuitive and descriptive naming? Is it scoped well? Is it following best-practices? What is missing?
If you care about this topic, I would love to hear your thoughts!
Hi @ffraenz - welcome, and thank you for sharing your package!
Some features that really stand out to me are:
Creating feature gates for common WP features - eg. FEATURE_COMMENTS
Mailer DSN (We run WP on Kubernetes, and DSNs via env vars are nice to work with)
Proxy / Edge header handling
I do wonder whether this is slightly too monolithic though. I’d prefer to be able to keep the Bedrock config/ directory so I can easily switch and override with WP_ENV. A lot of the vars set by EnvPress are also set by Bedrock already.
In my opinion (pinch of salt please ), the new, powerful features could be implemented orthogonally to Bedrock, rather than overlapping. Could we just keep the existing Bedrock env / wp-config structure, but provide the feature flags, upstream proxy rules, etc. in isolation?
There may be an architectural reason why you’ve chosen your approach which I might be overlooking!
Have starred, will follow
PS - Not sure if the trusted proxy CSV will support subnets / CIDRs, but that’s an important feature for us if it’s not already handled.
I wrote this package above all to get rid of configuration boilerplate code outside of the theme directory (wp-config or Bedrock’s config/) as I saw myself copying it back and forth between projects many times.
The package should move this code away from the projects to a central place, where it can be maintained, updated, tested, and distributed to many instances. Of course, the config code differs between WordPress instances. Instead of using code, I want to express these differences exclusively via a set of env vars. Similar to Bedrock’s config/, they may be organized/overridden by env type (e.g. using Ansible vars). I’m aware that it might not be possible to offer all the ways you may write config code with env vars alone. But this might be a good starting point for discussing it.
However, for developers who prefer to have that config directory, I could look into exposing APIs to enable partial functionality of the package. Thank you for bringing this to my attention.
When it comes to the trusted proxy logic, the current implementation is naive and only allows for a list of IP addresses. I will prioritize a better implementation here, allowing for one or more IPs/CIDRs. Thank’s again!
), the new, powerful features could be implemented orthogonally to Bedrock, rather than overlapping. Could we just keep the existing Bedrock env / wp-config structure, but provide the feature flags, upstream proxy rules, etc. in isolation?