[wp-trac] [WordPress Trac] #50992: Consider removing the ability to alter the list of environment types

[WordPress Trac]

#50992: Consider removing the ability to alter the list of environment types
----------------------------+---------------------
 Reporter:  johnbillion     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  5.5.1
Component:  Bootstrap/Load  |     Version:  5.5
 Severity:  normal          |  Resolution:
 Keywords:  dev-feedback    |     Focuses:
----------------------------+---------------------

Comment (by batmoo):

 Howdy! Mo from the WordPress.com VIP team here.

 One of the challenges we've run into with the environment type label is
 that it's quite narrow and conflates different things:

 - Where is this application running? (e.g. local environment or remote
 environment)
 - What is the application’s purpose (e.g. production site; non-production
 site; staging site; etc.)

 In our case, we have customers running "develop", "preprod", "production"
 environments (purpose; these can have arbitrary labels) on our
 "production" servers (location). For most of our customers, all the
 environments are expected to behave the same way (there should be little
 to no variation in functionality on the "develop" site, for example). This
 actually created a problem for us with Jetpack when we integrated this
 feature as all our non-production environments ended up in Jetpack’s
 “Staging Mode” which is not what we want. At the same time, there may be
 plugins (e.g. ones that post to Twitter / Facebook) that would definitely
 need to be restricted on develop/preprod/staging environments.

 Customers may also have "develop" environments (purpose) running local
 machines or self-hosted servers (location).

 > Actual environments should fit within one of those types (eg. a UAT site
 can be classified as either development or staging, as you see fit).

 "as you see fit" starts to create ambiguity as well and what we're
 struggling with around this feature. In many ways, how you interpret
 "development" vs "staging" vs "production" is going to be subjective which
 means that plugin authors will implement behaviours that users may not
 want because their interpretation of "development" or "staging" was
 different (for example, "staging" could refer to an environment used to
 verify code changes before they're pushed to production, or an environment
 where content is prepare and then copied over to production).

 If core wants to restrict the number of types, we'll happily support that,
 but we would recommend setting very clear expectations around what each
 type represents to remove any ambiguity. For example:

 - "development": a test version of the site running on a local computer or
 not the target hosting environment.
 - "staging": a test version of the site running on the target hosting
 environment.
 - "production": a live version of the site running on the target hosting
 environment.

 While these wouldn’t cover all our use cases, we think the clarity and
 consistency would help.

 We may want to consider guidelines for plugin authors as well:

 Include overrides for behavior (e.g. a filter or option) whenever taking
 action based on the environment type
 Document behavior differences in plugins based on environment type,
 ideally in the readme.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50992#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform