[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