[wp-trac] [WordPress Trac] #57487: Add support for "development mode"

[WordPress Trac]

#57487: Add support for "development mode"
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  flixos90
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  6.3
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note                                           |
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:68 azaozz]:
 > > We can always add more supported development mode values
 >
 > I'll be a bit worried about changing it much though. As far as I see the
 last thing that can be added would be to return when a development mode is
 set, regardless of which particular flavor.

 Again, I am unsure about a use-case for that. `WP_DEBUG` could be used
 just as well for this.

 > > If there is a real use-case where it becomes useful to check for any
 development mode
 >
 > Yes, there are few although I couldn't get the time to test and
 implement them. One is to change `_doing_it_wrong()` behavior (or the new
 proposed function that would replace it) depending on whether dev. mode is
 set. Thinking it may even throw a fatal error in some cases on a
 particularly "wrong" things.

 Why should debugging/error logging/error handling work differently between
 `WP_DEBUG` vs `WP_DEVELOPMENT_MODE`? The `WP_DEBUG` constant is the
 current way to control those things, so making tweaks depending on
 `WP_DEVELOPMENT_MODE` would intertwine things.

 Either way, what is being discussed here does not fit in the scope of this
 ticket, for the following reasons:
 * The reason `WP_DEVELOPMENT_MODE` was introduced was to allow certain
 core behaviors to change based on what kind of development is happening on
 the site (see e.g. #57573). That was a problem which `WP_DEBUG` would have
 been unable to address.
 * This follow-up conversation is about expanding the purpose of the
 `WP_DEVELOPMENT_MODE` to express a ''general'' development mode. This is
 different from the original purpose and even from the value "all". While
 I'm personally not a fan of that value, it still fits into the original
 paradigm and also addresses a real use-case, such as agencies working on
 all three things (core, plugins, themes) in a single environment.
 * The proposed change could be added at any point in the future without
 breaking backward-compatibility. It would be ''expanding'' the scope of
 the current concept, but not remove or change anything.

 To clarify: The function renaming discussion was different, as that
 clearly belonged to this ticket's scope, since such a change would have
 been impossible to make in the future. That's not the case here though.

 For those reasons, whether to expand `WP_DEVELOPMENT_MODE` to be usable as
 a "yes/no" constant and whether to potentially replace some `WP_DEBUG`
 usage with it should be discussed in a separate follow-up ticket. FWIW I'm
 not necessarily against the proposal, but it is an entirely separate
 purpose from the original scope of the `WP_DEVELOPMENT_MODE` constant and
 therefore requires careful consideration. It shouldn't be rushed into 6.3,
 and it also doesn't need to be, since adding it later is perfectly
 possible without BC breaks.

 Let's open a follow-up ticket to discuss the rationale and use-cases for
 such a potential change further.

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