WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 4 months ago

#33161 new enhancement

Create a standard for defining and identifying site environment

Reported by: krogsgard Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Options, Meta APIs Keywords:
Focuses: Cc:

Description

There are a number of reasons I can think of that would make a site environment identifier quite handy.

What I'm proposing: The ability to potentially define and/or identify a site environment, i.e., local, development, staging, live.

For instance, if it were a constant, then it could be defined:

define('SITE_ENVIRONMENT', 'live');

Third party solutions like Mark Jaquith's WP_LOCAL_DEV are already popular, but this would be in core and include more environments.

I know that adding constants isn't popular, but this could also allow core as well as third party plugins and themes to remove code that attempts, often not that well, to determine the same kind of information. A definition in the site's config could help make that easier and more accurate.

I don't know if a constant is the best route for enabling the definition and identification of the site environment, but I'd like to start a conversation.

Change History (3)

#1 @krogsgard
4 years ago

To be fair upfront, one of the biggest downsides is that this would happen in wp-config.php and that's one of the ideal places to use this information.

It'd be great to more easily define site config constants (like database details) based on what environment is. I don't know the way around that, and that's my biggest question as to whether a constant would be the right route, or if there is a more low lying issue that would need fixing to make this the most valuable.

#2 @Frank Klein
4 years ago

You mention that Core does attempt to find out in what environment the code is running, would you mind pointing me towards an example for this?

In my opinion, your code should not care where it runs. Local, preproduction, production, those are just deploys of the same code base. Meaning the behavior of the code base should not change depending on the environment.

The current way of handling connection details in wp-config.php, and the workarounds like the one that Mark has written about are fine for use cases in which you do not want to put a deployment procedure into place.

However if you are at the point that you have a centralized development version, a staging environment, etc. then the time for poor workarounds like conditional handling of database connection information is gone.

There are solutions for all the problems that people encounter. There is software to automatically provision machines in the different environments to keep the stack the same. The config can be stored in environment variables. Differences in asset handling (unminified in development, minified in production) can be handled through build scripts.

There's a great site about best practices like this: http://12factor.net/

So in short I'm not in favor of this ticket. It encourages outdated development techniques and actually makes things more difficult for developers. Web development has moved on from these techniques, let's move along with it.

#3 @Maelacuna
3 years ago

What about incorporating dotenv?

https://github.com/vlucas/phpdotenv

This would avoid ever having to edit wp-config.php for configuration, like database credentials, as well as giving the ability to define enviroment variables for plugins, themes, etc. if desired. API keys spring to mind as an example. These things can then be kept out of the code base, out of version control, and even out of the document root if desired.

Frank, item 3 of the 12 Factor app is specifically about storing config in the environment and not in the code base, so I'm confused why you reference it and then say you're not in favour?

Here is an article by Eric Barnes highlighting one way that dotenv could be incorporated in to WordPress to help manage environments:

https://dotdev.co/tutorials/secure-wordpress-config-dotenv/

Last edited 3 years ago by Maelacuna (previous) (diff)
Note: See TracTickets for help on using tickets.