[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:  assigned
 Priority:  normal                    |   Milestone:  6.3
Component:  General                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------

Comment (by flixos90):

 Replying to [comment:24 peterwilsoncc]:
 > If different development modes are to be defined, then `site` would be
 helpful for agencies developing sites using both custom themes and custom
 plugins.

 Good point, there may be cases where both are being developed. I think
 `core`, `plugin`, and `theme` are the natural first choices, but happy to
 explore adding more. I think this could happen either as part of an
 initial commit or as a follow-up.

 > If the goal is to avoid a constant that over complicates things then
 using `true` or `false` seems the least complicated way of doing it.

 That would not satisfy the requirements though, as developing a theme has
 different implications than developing core for example.

 Replying to [comment:25 schlessera]:
 > Just reading through this, I think that the proposed solution of having
 a "development mode" is not a good approach and is so vague that it will
 most certainly lead to a lot of confusion and issues down the road.
 >
 > What if I want to "develop", but I need caches to see the scaling
 behavior? What if I want to disable caching on a production server?

 That's why the development mode is not just a true/false consideration, it
 is more granular than that. If you are developing a theme, the scaling
 behavior of core caches is "irrelevant", as only core controls them. If
 you are developing core, the caches would be enabled - the granularity is
 why this concept came up in the first place. The example you outlined is
 precisely what this development mode concept would address.

 The relevant caches are around file-based logic that is reasonable to
 cache in regular WP usage, but not when developing and possibly changing
 those files every minute or so. For example: `theme.json`-based logic can
 easily be cached as long as you're not currently working on that theme, as
 it would only possibly change during a theme update. However, if you're
 currently working on that theme's code, the caches should be disabled to
 avoid messing up your workflow. So you would set `WP_DEVELOPMENT_MODE` to
 "theme". When you're directly working on core though, that doesn't apply
 to you.

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