Set development mode to 'plugin' in the dev environment and allow pages to be optimized when admin is logged-in (when in plugin dev mode)

[ShyamGadde]

Summary

Fixes #1423

• Sets WP_DEVELOPMENT_MODE constant to plugin in development environment.
• Adds plugin development mode configuration for Optimization Detective.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ShyamGadde <[email protected]>
Co-authored-by: westonruter <[email protected]>
Co-authored-by: felixarntz <[email protected]>
Co-authored-by: mukeshpanchal27 <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[felixarntz]

+1 to set the development mode to "plugin" in our config. For the Optimization Detective specific tweaks, I am not sure it's a good idea to rely on it in all of these places.

The modified condition for od_can_optimize_response() makes sense to me as that makes development a lot easier, and it's not very risky as it's a general on/off switch for almost the entire feature. But adjusting the TTLs and sample sizes I find questionable. These kinds of changes will mean that realistically we'll almost never naturally test this in the way that it actually behave, but only how it behaves with the development mode set to "plugin". Why are those tweaks necessary? And if they are, what is our strategy to mitigate that risk?

[westonruter]

But adjusting the TTLs and sample sizes I find questionable. These kinds of changes will mean that realistically we'll almost never naturally test this in the way that it actually behave, but only how it behaves with the development mode set to "plugin". Why are those tweaks necessary? And if they are, what is our strategy to mitigate that risk?

During development I have a plugin active which does this:

add_filter( 'od_url_metric_storage_lock_ttl', '__return_zero' );
add_filter( 'od_url_metric_freshness_ttl', '__return_zero' );
add_filter( 'od_url_metrics_breakpoint_sample_size', function () { return 1; } );
add_filter( 'od_can_optimize_response', '__return_true' );
add_filter( 'od_maximum_viewport_aspect_ratio', function () { return PHP_INT_MAX; } );
add_filter( 'od_minimum_viewport_aspect_ratio', function () { return 0; } );

With the changes in this PR, such a plugin won't be necessary anymore to start development. These tweaks do a few key things to facilitate development:

1. od_url_metric_storage_lock_ttl: Allows a user to submit a new URL Metric to be stored with every page load.
2. od_url_metric_freshness_ttl: Makes it so that URL Metrics are always considered stale so that new ones are accepted.
3. od_url_metrics_breakpoint_sample_size: Reduces the number of URL Metrics from the sample size of 3 to be considered "complete". Some optimizations only start applying once the gathered URL Metrics all concur that a given element is LCP, so by reducing this from 3 to 1 then fewer reloads are needed to flush out stale URL Metrics to start seeing the expected optimizations apply from the most recent page load.
4. od_can_optimize_response: Already discussed above.
5. od_maximum_viewport_aspect_ratio/od_minimum_viewport_aspect_ratio: Disabling these ensures that metrics will be collected when, for example, Dev Tools is open and the window aspect ratio is not normal.

[felixarntz]

@westonruter This only answers my first question, not the primary concern I'm raising. Makes sense that you may use a utility plugin like this for development, and I think for this kind of tweak that's actually better. This means at least that not everyone contributing to OD will get that experience by default, so we'll get some usage of the way this plugin behaves in production.

I don't think the benefit of not needing such a helper plugin outweigh the risks of not running the code in the way it should usually behave out of the box.

[westonruter]

@felixarntz Well, then I guess what's the point of plugin development mode if enabling it doesn't get you what you need to start developing? So there's actually two levels of development mode essentially? A shallow development mode and a deep development mode?

[felixarntz]

@westonruter

Well, then I guess what's the point of plugin development mode if enabling it doesn't get you what you need to start developing? So there's actually two levels of development mode essentially? A shallow development mode and a deep development mode?

I think it's more nuanced, yes. Any of the changes currently in this PR could be implemented as dependent on the development mode config, but tweaking production behavior for development comes with the aforementioned risk, so I think this should be used very selectively.

Examples where I think development mode makes sense:

• Enabling logic to run in a condition where it would otherwise almost never run in development (e.g. the od_can_optimize_response() example here, or the Site Kit plugin not printing any Analytics tags when an admin is logged in)
• Skipping various caches to avoid having to always clear caches when debugging

Both of these are more or less on/off switches, but they don't tweak any more granular logic outcomes. There is definitely a fine line between the developer convenience and the risk of running a too altered version of the plugin in development mode, so it makes sense to discuss specific cases. But per the above, here I think tweaking numbers like TTL and sample sizes may go a bit too far.

[westonruter]

@felixarntz OK, makes sense. Undone in 6da3ddc.

[felixarntz]

@ShyamGadde @westonruter Thanks for the updates, looks great!

Just a few documentation notes that I think should be revised.