[wp-trac] [WordPress Trac] #33161: Create a standard for defining and identifying site environment

[WordPress Trac]

#33161: Create a standard for defining and identifying site environment
--------------------------------------+-----------------------------
 Reporter:  krogsgard                 |       Owner:  SergeyBiryukov
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  5.5
Component:  Options, Meta APIs        |     Version:  4.2
 Severity:  normal                    |  Resolution:
 Keywords:  needs-dev-note has-patch  |     Focuses:
--------------------------------------+-----------------------------

Comment (by kraftbj):

 Replying to [comment:48 SergeyBiryukov]:
 > To summarize, some open questions left from comment:33 and comment:46:
 > * Should the default value of `WP_DEBUG` and friends be dependent on the
 environment? eg. should `WP_DEBUG` be true by default for non-production
 environments?

 That makes sense to me that defining the site environment sets reasonable
 defaults for WP_DEBUG, et al.

 > * Would there be any objection to also includinig `'qa'` and `'uat'` in
 the default list of environments?

 No objection per se, but I'd like in the dev notes (and ideally in inline
 documentation IMO) some explanation of what each is intended to mean.

 For example, in Jetpack, we have a "development mode" that is intended for
 localhost where a site would not be connecting to WordPress.com. The
 original use case is for theme developers to be able to activate some
 features of Jetpack that would usually require a connection with a fair
 mockup of it so they can work on front-end theming. (I realize this mode
 isn't perfect, so let's not go down the rabbit hole if Jetpack is actually
 doing all that I'm claiming it does!). Major parts of Jetpack will not
 work in this mode and isn't foreseen as a new going-into-production-
 eventually site.

 We have a "Staging Mode" which is meant for sites that may be a copy of a
 production database (which in our case includes the knowledge that a site
 is connected to WordPress.com), but isn't production — so don't do
 anything that would impact that. Don't send out new posts to Twitter, etc.

 I think our use of "staging" matches what everyone else is using it, but I
 think we may have different definitions of a "development" environment in
 this instance. I'd reckon that "development" here means a version of a
 regular site that is early in the workflow toward production.

 In short, when plugins are looking at the site environment and deciding
 what to do, let's make it really clear what the site owner's intention
 should be when they set that environmental value.

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