I just realized that the disabled reasons are somewhat nested here. There are 7 different possible reasons for OD being disabled in od_can_optimize_response(). Should the logic in that function be similarly structured in an array in another function so that its reasons can be exposed as well? Maybe this is overkill. But I just wanted to mention it since it came to mind.

I implemented this in bae1198. Please let me know if this matches what you had in mind.

This test could then test both od_get_cannot_optimize_reasons() and od_can_optimize_response()

Let's add a test for this for good measure.

Idea: How about we pass the $reasons into the od_can_optimize_response filter as the second argument? This would allow od_can_optimize_response filter callbacks to see any existing reasons for why OD was disabled, and then add their own considerations on top.

So for example, the above $reasons array could instead be an $disabled_flags (or maybe there is a better name) which is array<string, bool>, this could then be passed as the second argument to the filter.

The array of booleans can then be passed through array_filter to remove the non-disabled flags, and then the resulting can be intersected with associative array array<string, string> that has the disabled reasons provided as the string array values. This resulting intersection can then be returned as $reasons.

Why would this be useful to add? Consider the case where you want to selectively enable the search template to be optimized. In order to do this, you'd have to re-compute all of the conditions to flip the false value of $can_optimize_by_default back to true. But if all of the flags were passed in, then they could be examined before flipping that boolean. For example:

add_filter( 'od_can_optimize_response', static function ( $can_optimize, $disabled_flags ) {
	if ( ! $can_optimize && is_search() ) {
		unset( $disabled_flags['is_search'] );
		$can_optimize = count( array_filter( $disabled_flags ) ) === 0;
	}
	return $can_optimize;
} );

So in this way, the $disabled_flags would not just be array<string, bool> but rather it should be an array shape that defines all of the keys.

Implemented it in 28264af.

How about adding an explicit array shape for the return value here, defining all of the possible (nullable) keys mapping to boolean values?

Maybe this is overkill since we're never . If we do it here, then it should also be done in the param for the od_can_optimize_response filter.

Done in 9171d30.

When I was typing out these keys in a test case, I caught myself typing non_get_request first. This made me wonder if it would be better than not_get_request and Gemini seems to think so: https://g.co/gemini/share/53a822060e73