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

WordPress Trac noreply at wordpress.org
Fri May 15 15:55:23 UTC 2020


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

Comment (by Clorith):

 I'd love to walk through it (since I made a very tangible proposal).

 Firstly, it's a function used for grabbing the current environment, this
 is to ensure everyone fetches the values the same way (to avoid using
 different terms and such).

 As you mentioned, the function would need to be loaded fairly early,
 probably alongside the same time as the fatal error handler and similar
 things, to make it usable in most scenarios.

 As for the filtering possibilities, although possible to circumvent by
 running code directly instead of through hooks, _most_ (based on my own
 experience at least) actions that fire would come from another hook or
 later down the call stack.

 Some examples where diverting based on environment would be useful:

 Outbound emails could be filtered, and if `get_environment()` isn't set to
 `production` then send them to the developer, allowing for legitimate
 email tests in stage setups without worrying about emails reaching end
 users.

 API endpoints where you want to use a test endpoint when not in production
 to prevent data pollution.

 Providing a wp-admin notice for non-production sites so it's much clearer
 that what you are doing now will/won't affect the site your business
 relies on.

 All of those examples fire so late that plugins would have had a chance to
 kick in a filter.

 As for why they might want to filter, you may use a "staging-plugin" to
 change environments on your site on the fly for testing purposes, or
 possibly conditionally set the environment "the core way" on a legacy
 project which has been doing it in some custom way without a good way to
 change that, but wanting to ensure compatibility with other plugins/themes
 moving forward.

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


More information about the wp-trac mailing list