I can't put into words how important this is and why it is drastically needed. I will break this down from a few angles and explain the problem and why it is under the radar. So please bare with me, bit of a long one.

The first context, as an agency WordPress dev I need a straight forward way of separating logic for different environments typically for bespoke data syncs and safe guards from WordPress executing production based code on a test site. A classic case is WordPress sending emails connected to a SMPTP endpoint on a CRON job on a dev/staging site for example cloned from live. Hoping I don’t need to explain why that is really bad. With environment locks it can be prevented easily with safe guarding controls.

WordPress has built a function for this into the core almost 5 years ago. The function is called wpgetenvironment_type(). The way this works is it reads an env variable set via the web server or the fpm pool and accesses the defined environment by using getenv(). If this can’t be read it defaults to production. This needs to be defined effective immediately which should be at the application server level.

There's currently no support for wpgetenvironment_type() on CW. The function reads an environment variable using getenv which can either be set via an nginx, apache param or inside the fpm pool. Currently can’t set custom env variables on CW and can't alter webserver config. Meaning this can’t be set in the correct way. Instead developers have to define this inside the wp-config file using a define statement which is setup by WP as a backup method. This however is flawed as a site clone would knock this out. Someone is going to forget to add an exclusion path or by mistake remove the define statement in wp-config.php and it’s an accident waiting to happen. All of a sudden your dev/staging site is in production mode.

Over time more and more plugins are now using the wpgetenvironment_type() function. The biggest being Yoast SEO and they have an article on that here https://developer.yoast.com/customization/yoast-seo/wp-get-environment-type-in-yoast-seo/. That plugin is on millions of installs.

This is an issue specific to devs that dealing with business sites with complex solutions. This is a very small subset of a subset of CW customers. But the ones it does affect it’s a real nightmare.

The best way forward is to add the env declaration on the fpm pool so something like env[WPENVIRONMENTTYPE] = development for example. The reason for this is the webserver route won’t catch devs making custom WP CLI commands and because it defaults to production lets say you have a CLI command that runs a process that sends data to an API and your testing it, if it’s missing the env declaration it will default to production. If your authentication keys and endpoints are swapped via env checking you’re gonna run into a lot of problems.

The WordPress function is here https://developer.wordpress.org/reference/functions/wp_get_environment_type/. It’s a very small function.

Outside of very small low risk websites I can’t see how I can put sites onto Cloudways or recommend to clients. It’s very frustrating given other providers have this sorted as part of their tech stack and done it a number of years ago.