[wp-trac] [WordPress Trac] #57573: Provide a way to signify a "development mode" (independently of `WP_DEBUG`)

[WordPress Trac]

#57573: Provide a way to signify a "development mode" (independently of `WP_DEBUG`)
-------------------------+----------------------------
 Reporter:  flixos90     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Future Release
Component:  General      |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+----------------------------
 [55138], [55148], and [55155] introduced changes that rely on `WP_DEBUG`
 for whether to cache `theme.json` related data. As discussed in PRs for
 those (e.g. https://github.com/WordPress/wordpress-
 develop/pull/3556#discussion_r1071510762 or https://github.com/WordPress
 /wordpress-develop/pull/3712#discussion_r1071518995), we should come up
 with an approach to signify some kind of "development mode", to control
 such caching. This is explicitly different from `WP_DEBUG`.

 For example consider the following scenario:
 * As a theme developer is developing their block theme, they want to see
 changes to `theme.json` be reflected immediately. Therefore they want to
 disable caching. By enabling `WP_DEBUG`, they get alerted on potential
 code issues as usual, and the caching is disabled as well. All good, for
 this use-case `WP_DEBUG` technically still works well.
 * For a WordPress core developer or a plugin developer working on core or
 their plugin, they don't (typically) make `theme.json` changes, so they
 want WordPress to behave as close to how it behaves in production (i.e.
 `theme.json` data being cached). Yet they still want to enable `WP_DEBUG`
 to get alerted on potential code issues as usual. But now they cannot do
 that without ''also'' disabling the caching. When working on something
 related to that data or the caching of that data in core or in a plugin,
 you will therefore run into the problem.

 The proposed solution is to come up with either a new constant, a new
 filter, or both in combination, to control the `theme.json` caching
 independently of `WP_DEBUG`. Potentially the default value (if the
 constant is not defined / filter is not used) could still be `WP_DEBUG`,
 that's a reasonable default for most scenarios. But it still needs to be
 possible to set the flag independently of `WP_DEBUG`, to satisfy the
 developer experience when you're ''not'' developing a theme.

 At this point, the only use case for this new mechanism would be to
 control whether or not to cache `theme.json` related data. This leads to
 the question on how we want to name the constant or filter and what scope
 it should cover:
 1. Maybe just the specific purpose we know about now? (e.g. something like
 a boolean `WP_THEME_JSON_CACHE`)
 2. Or maybe a general theme development mode? (e.g. something like a
 boolean `WP_THEME_DEVELOPMENT_MODE` or even
 `WP_BLOCK_THEME_DEVELOPMENT_MODE`)?
 3. Or something broader around a general development mode which would go
 beyond a boolean? (e.g. something like a string `WP_DEVELOPMENT_MODE`
 which could take different string values like "core", "plugin", "theme",
 or empty, i.e. no development at all)

 The other question is whether we want this to be...
 1. Either just a constant (e.g. `WP_DEVELOPMENT_MODE`)...
 2. Or just a filter (e.g. `wp_development_mode`)...
 3. Or a combination of both (e.g. function `wp_development_mode()` that
 checks the constant if set but also runs the value through the filter).

 Let's discuss the potential approaches in here. Implementing it will
 likely be straightforward once we have come to a decision. It would be
 great to get this into 6.2 already to enable such a mechanism sooner than
 later (also for future Gutenberg iterations) but since we're already so
 close I'll milestone this for a future release for now. If we can get to a
 decision soon, we can potentially still include it in 6.2.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57573>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform