Opened 22 months ago
Closed 17 months ago
#57573 closed enhancement (duplicate)
Provide a way to signify a "development mode" (independently of `WP_DEBUG`)
Reported by: | flixos90 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
[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 enablingWP_DEBUG
, they get alerted on potential code issues as usual, and the caching is disabled as well. All good, for this use-caseWP_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 enableWP_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:
- Maybe just the specific purpose we know about now? (e.g. something like a boolean
WP_THEME_JSON_CACHE
) - Or maybe a general theme development mode? (e.g. something like a boolean
WP_THEME_DEVELOPMENT_MODE
or evenWP_BLOCK_THEME_DEVELOPMENT_MODE
)? - 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...
- Either just a constant (e.g.
WP_DEVELOPMENT_MODE
)... - Or just a filter (e.g.
wp_development_mode
)... - 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.
Change History (5)
#2
@
22 months ago
@flixos90 This ticket seems very close/almost identical to #57487. Maybe better to keep the discussion in one place.
#3
@
22 months ago
@azaozz Ah thanks, I had missed that.
That said, the discussion there is going in a rather different direction so far, so maybe worth keeping this for now. I have suggested a few different alternatives in the ticket here, and only the 3rd one would be similar to what is being discussed in #57487; the other two options would be separate.
My suggestion would be to discuss what the best approach for the concrete problem outlined here is in this ticket, and if we think it's the 3rd, we can close this and move the discussion to #57487.
#4
in reply to:
↑ description
@
22 months ago
Replying to flixos90:
The other question is whether we want this to be...
- Either just a constant (e.g.
WP_DEVELOPMENT_MODE
)...- Or just a filter (e.g.
wp_development_mode
)...- 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).
I think a function makes sense, it would complement wp_get_environment_type()
.
Pinging @azaozz @hellofromTonya @spacedmonkey @oandregal here since you were involved in previous conversations about this.