WordPress
Consider checking/setting new development mode constant
From the Create Block Theme's README
The plugin is for development only — it is not intended for use on production websites, but to be used as a tool to create new themes.
Perhaps the soon-to-released, new WP 6.3 WP_DEVELOPMENT_MODE constant could be leveraged to check or set, which could provide a better developer experience?
Example
if ( ! wp_is_development_mode( 'theme' ) ) {
define( 'WP_DEVELOPMENT_MODE', 'theme' );
}
This could be beneficial for the following reason
However, if you are actively developing a theme on the site and modifying theme.json constantly, having to manually invalidate the cache all the time would be detrimental to the development workflow. Therefore, that specific caching functionality is bypassed if the development mode is set to “theme”.
This is an interesting idea. My vote would be that instead of changing it (for example, they might want it set to all) , it renders an admin_notice on the main CBT settings screen that says something like 'Your environment is not currently set to theme development mode' with a link to documentation (maybe this? https://make.wordpress.org/core/2023/07/14/configuring-development-mode-in-6-3/)
Considering that the CBT tool targets non-developers I think that setting the value automatically would be most beneficial. Perhaps we can check for 'all' or 'theme' and do nothing, if it is unset, set it to 'theme' and if it is set to something else ('plugin') then maybe switch it to 'all' or message the user?
Is it unreasonable to automatically engage this?
Alternatively, if it's not something we should do automatically then rather just messaging the user I believe we should provide them with an interface rather than just linking to documentation.
From this project's README:
Disclaimer: Create Block Theme enables development features and thus is a tool that should be treated like as such; you can think of it as a Development Mode for WordPress, and you should keep in mind that changes made through this plugin could change your site and/or theme permanently.
This seems to contradict
the CBT tool targets non-developers
If I were to read the prior statement as a non-developer then I would likely refrain from using the plugin. 🤔
I guess one alternative to the original comment on the issue could be
if ( ! defined( 'WP_DEVELOPMENT_MODE' ) ) {
define( 'WP_DEVELOPMENT_MODE', 'theme' );
}
which wouldn't override an explicit constant somewhere else.
+1 to perhaps a control that opts WP_DEVELOPMENT_MODE to theme for you—especially as style variations are cached much more aggressively since 6.4 I believe.
@richtabor Perhaps the cache is a little too aggressive since it won't clear for style variations even with the development mode enabled.
I looked at the core codebase and haven't found any implementation around define( 'WP_DEVELOPMENT_MODE', 'theme' ). It seems like using that constant will have no impact by itself.
Hosting providers could probably implement special behaviors based on that constant, but WordPress core, as far as I've seen today in the source code, doesn't seem to have anything already in place. One example of an implementation could be the use of custom cache rules based on the value of WP_DEVELOPMENT_MODE. Still, right now, setting the WP_DEVELOPMENT_MODE constant when the plugin is activated won't have any practical impacts and it would be just for hypothetical potential implementations that third-party providers could do.
What are the improvements in the developer experience you wanted to achieve by using this constant?
I just want to note that the wp_is_developement_mode() function is called a number of times throughout core: https://developer.wordpress.org/reference/functions/wp_is_development_mode/#related
From what I understand, it has a lot to do with how theme.json generated styles, patterns, etc are cached.
I just want to note that the wp_is_developement_mode() function is called a number of times throughout core: https://developer.wordpress.org/reference/functions/wp_is_development_mode/#related From what I understand, it has a lot to do with how theme.json generated styles, patterns, etc, are cached.
You are right; I wasn't searching for the right function. As you said, a few things ~are~ aren't cached if 'theme' development mode is enabled.
Since adding a constant to the main plugin codebase implies that those cached items are disabled for the sites that have the plugin active, we should probably include a switch to enable/disable the constant or include some kind of notice for the user around deactivating the plugin when it's not being used. Still, none of those two options seem great for user experience and simplicity.
As you said, a few things are cached if 'theme' development mode is enabled.
I believe it's sort of the opposite - it disables caching of things like generated styles (and maybe patterns?) so you can see your changes instantly as you develop your theme.
A few options were discussed in the thread:
- Rendering an admin notice that informs the user that development mode is not set with a link to documentation
- Checking to see if it's not already defined and, if not, defining it
As the plugin readme says "The plugin is development only — not intended for use on production websites".
I believe it's sort of the opposite - it disables caching of things like generated styles (and maybe patterns?) so you can see your changes instantly as you develop your theme.
Yes, it was a typo; I missed the n't.
I've explored this a little bit more, and I haven't found a way to define the constant in a plugin. The constant is defined in WordPress core with an empty string as the default value, and it doesn't seem possible to override it in a plugin.
/*
* Add define( 'WP_DEVELOPMENT_MODE', 'core' ), or define( 'WP_DEVELOPMENT_MODE', 'plugin' ), or
* define( 'WP_DEVELOPMENT_MODE', 'theme' ), or define( 'WP_DEVELOPMENT_MODE', 'all' ) to wp-config.php
* to signify development mode for WordPress core, a plugin, a theme, or all three types respectively.
*/
if ( ! defined( 'WP_DEVELOPMENT_MODE' ) ) {
define( 'WP_DEVELOPMENT_MODE', '' );
}
If something like the proposed code is added to the plugin's code:
if ( ! wp_is_development_mode( 'theme' ) ) {
define( 'WP_DEVELOPMENT_MODE', 'theme' );
}
WordPress throws this warning and the constant is not overridden:
Warning: Constant WP_DEVELOPMENT_MODE already defined
As the constant is always defined (by default as an empty string), it doesn't seem possible to define it from the plugin.
A few options were discussed in the thread:
- Rendering an admin notice that informs the user that development mode is not set with a link to documentation
- Checking to see if it's not already defined and, if not, defining it
Option number 2 doesn't seem to be technically possible right now.
Another thing to consider is that the plugin need to have WP_DEBUG defined as false:
https://github.com/WordPress/create-block-theme/blob/a621674bcd36c0a7c75dfe261634ce1917022ca2/readme.txt#L107-L112
and WP_DEVELOPMENT_MODE suggest users define WP_DEBUG as true.
Most likely, in this case you also want to make sure you have WP_DEBUG enabled and WP_ENVIRONMENT_TYPE set to “development” or “local”.
Reference: https://make.wordpress.org/core/2023/07/14/configuring-development-mode-in-6-3/
I've explored this a little bit more and I haven't found a way of defining the constant in a plugin.
Now that you mention it, I'm sure that's by design--thanks for researching @matiasbenedetto !
From what I see, the main need to use the theme mode for WP_DEVELOPMENT_MODE, is that it bypasses theme.json caching, which is really helpful if you're editing theme.json directly, so you can see the changes right away.
We don't currently offer a way to edit your theme.json file through the plugin, only to view it. If/when we add a theme.json editor to the plugin, I think it would make sense to add a notice instructing the user to define the constant, if theme development mode isn't already configured. But right now, I don't think there's any action to take for this issue.
We don't currently offer a way to edit your theme.json file through the plugin, only to view it.
I think this is not accurate because the plugin changes the content of the theme.json file on the disk when the option Save theme changes is used. Still, I think that the cache problem has already been fixed by https://github.com/WordPress/create-block-theme/pull/654 introduced to solve an issue related to cached patterns not loading as expected because of the cache.
I don't think there's any action to take for this issue.
I agree with this. As the initial proposal is not technically possible and the suggestion to the users to add the constant themselves to their WordPress instance doesn't seem to have practical effects after the introduction of https://github.com/WordPress/create-block-theme/pull/654, I will go ahead and close this as not planned. Feel free to re-open if you think there are still things to do regarding this or if you find any practical impact of the development mode while creating themes with the Create Block Theme plugin.
I think this is not accurate because the plugin changes the content of the theme.json file on the disk when the option Save theme changes is used.
Yes, that's true; it's a bulk edit of all theme files at once and the recent change to flush the cache after theme save seems to address this case nicely.
For theme development mode, I was thinking more of when you're manually editing individual theme.json properties or pattern/template files and then refreshing the browser to see the change--that seems to be the use case where theme development mode is most helpful.