Make WordPress Core

#57573 closed enhancement (duplicate)

Provide a way to signify a "development mode" (independently of `WP_DEBUG`)

Reported by: flixos90's profile 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 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.

Change History (5)

#1 @flixos90
22 months ago

Pinging @azaozz @hellofromTonya @spacedmonkey @oandregal here since you were involved in previous conversations about this.

#2 @azaozz
22 months ago

@flixos90 This ticket seems very close/almost identical to #57487. Maybe better to keep the discussion in one place.

#3 @flixos90
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 @SergeyBiryukov
22 months ago

Replying to flixos90:

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).

I think a function makes sense, it would complement wp_get_environment_type().

#5 @flixos90
17 months ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

It was decided to go with the option 3 outlined in this ticket, which was addressed via #57487, so this can now be closed as a duplicate.

Note: See TracTickets for help on using tickets.