Testing Compatibility Across WordPress Versions

Your migrated code needs to work correctly on both a 6.9 site and a 7.0 site, and those two versions genuinely differ in what’s available, specifically around the PHP AI Client. This lesson covers exactly what changes, what doesn’t, and how to test both scenarios without keeping two permanent WordPress installs around by hand.

Step 1: Know exactly what differs between the two versions

If your migrated code only registers abilities and serves them through the MCP Adapter, a 6.9 site and a 7.0 site behave identically for your purposes, there’s nothing version-specific to test beyond what Lesson 3 already confirmed. The version split matters specifically for any code path that calls the PHP AI Client, which, being new in 7.0, simply does not exist as a function on a 6.9 site.

Step 2: Write a version-aware guard for AI Client calls

If your plugin uses wp_ai_client_prompt() anywhere, that code path needs an explicit check, since calling an undefined function is a fatal error, not a graceful failure:

// File: my-plugin.php
function my_plugin_summarize_content( string $content ): string {
	if ( ! function_exists( 'wp_ai_client_prompt' ) ) {
		// WordPress 7.0+ not available; fall back to a non-AI code path,
		// or surface a clear message rather than failing silently.
		return __( 'AI summarization requires WordPress 7.0 or later.', 'my-plugin' );
	}

	$result = wp_ai_client_prompt()
		->using_text_generation_model()
		->generate_text( "Summarize this content:\n\n{$content}" );

	return $result->get_text();
}

This same function_exists() pattern is the one Lesson 2 used for the Abilities API, applied here to the newer, 7.0-specific dependency. Both checks report exactly what they mean: “is this specific core feature available,” not “is some package installed.”

Step 3: Run the same code against both versions locally

Using the two wp-env config files from Lesson 3:

# Test against 6.9: Abilities API works, AI Client should gracefully report unavailable
wp-env start --config .wp-env.6-9.json
wp-env run cli --config .wp-env.6-9.json wp eval 'var_dump( function_exists( "wp_ai_client_prompt" ) );'
wp-env destroy --config .wp-env.6-9.json

# Test against 7.0: both should now work
wp-env start --config .wp-env.7-0.json
wp-env run cli --config .wp-env.7-0.json wp eval 'var_dump( function_exists( "wp_ai_client_prompt" ) );'

The first block should print bool(false), confirming your guard code’s fallback branch is the one that will actually execute on a 6.9 site. The second should print bool(true).

Test it: a single script that reports your site’s real capability tier

wp-env run cli wp eval '
$wp_version = get_bloginfo( "version" );
$has_abilities = function_exists( "wp_register_ability" );
$has_ai_client = function_exists( "wp_ai_client_prompt" );
$has_mcp_adapter = class_exists( "WP\\MCP\\Core\\McpAdapter" );

echo "WordPress: $wp_version\n";
echo "Abilities API: " . ( $has_abilities ? "yes" : "no" ) . "\n";
echo "PHP AI Client: " . ( $has_ai_client ? "yes" : "no" ) . "\n";
echo "MCP Adapter plugin: " . ( $has_mcp_adapter ? "active" : "not active" ) . "\n";
'

Keep a script like this in your project’s test tooling, it’s a fast way to confirm exactly what a given environment supports before debugging something that might just be a missing feature for that specific core version, not a bug.

Recap

The Abilities API behaves identically on 6.9 and 7.0, so most migrated code needs no version-specific handling at all. The PHP AI Client is the genuine dividing line, since it only exists from 7.0 onward, and any code calling it needs an explicit function_exists() guard with a real fallback. Test both versions locally using separate wp-env configs, and keep a small capability-reporting script handy to quickly confirm what a given environment actually supports.

Resources & further reading

• Introducing the AI Client in WordPress 7.0, make.wordpress.org
• Abilities API in WordPress 6.9, make.wordpress.org
• @wordpress/env (wp-env) package, GitHub
• MCP Adapter repository, GitHub