WP Copilot
Search… /
Wrap-up

Course Recap: A Migration Checklist

⏱ 9 min

You’ve now covered the corrected picture of what’s actually in WordPress core, removed the archived Composer dependency, updated your local environment, fixed the single most common visibility bug, audited for subtler deprecations, tested across two core versions, and corrected any code or docs that assumed the MCP Adapter didn’t need a separate install. This lesson pulls all of it into one ordered checklist you can run against any codebase still on the old package.

What you'll learn in this lesson
The full migration checklist, in order
Every step from this course, as a single reference you can work through top to bottom.
The one sentence to remember
A compact restatement of this course's corrected premise, worth keeping close.
A final verification script
One command that reports your migrated site's complete, accurate status.
Where to go next
Back into the rest of the track, now with a corrected foundation.
Prerequisites

All seven prior lessons in this course. This is a wrap-up, not a new topic.

Step 1: The one sentence worth remembering

If you keep only one fact from this entire course, make it this: the Abilities API and the PHP AI Client are in WordPress core (since 6.9 and 7.0 respectively), the MCP Adapter is not, and never was, a separate plugin, on its own release cadence, by deliberate design. Almost every mistake this course corrected traces back to confusing that third fact with the first two.

Step 2: The full migration checklist

Migration checklist, run top to bottom
Confirm your target WordPress version
6.9+ for Abilities API only, 7.0+ if you also need the PHP AI Client. (Lesson 1)
Remove wordpress/abilities-api from composer.json
composer remove wordpress/abilities-api, then check composer why for transitive references. (Lesson 2)
Delete any manual bootstrap require pointing at the old package
A require_once into vendor/wordpress/abilities-api that composer remove won't catch on its own. (Lesson 2)
Update readme.txt and plugin headers
Requires at least: 6.9 (or 7.0 if using the AI Client), replacing any package-existence guard. (Lesson 2)
Pin .wp-env.json to the version you're actually testing
A WordPress.org release zip URL, not a null core value. wp-env destroy before any version change takes effect. (Lesson 3)
Set meta.mcp.public explicitly on every ability meant for agent use
And run the wp_get_abilities() diagnostic script to confirm what's actually exposed. (Lesson 4)
Audit for package-era scaffolding, not function renames
Bootstrap requires, autoloader assumptions, and class_exists() checks against package internals. (Lesson 5)
Guard every wp_ai_client_prompt() call with function_exists()
And test against both a 6.9 and a 7.0 wp-env config. (Lesson 6)
Guard every direct MCP Adapter class call with class_exists()
Against WP\MCP\Core\McpAdapter specifically, keeping ability registration itself outside that guard. (Lesson 7)
Grep your own docs and deployment scripts for the same false premise
Language implying the MCP Adapter needs no separate install. (Lesson 7)

Step 3: One script to verify the whole migration at once

Run this against your migrated site as a final sanity check:

wp-env run cli wp eval '
echo "WordPress: " . get_bloginfo( "version" ) . "\n";
echo "Abilities API (core, 6.9+): " . ( function_exists( "wp_register_ability" ) ? "yes" : "no" ) . "\n";
echo "PHP AI Client (core, 7.0+): " . ( function_exists( "wp_ai_client_prompt" ) ? "yes" : "no" ) . "\n";
echo "MCP Adapter plugin (always separate): " . ( class_exists( "WP\\MCP\\Core\\McpAdapter" ) ? "active" : "NOT ACTIVE" ) . "\n";

$abilities = wp_get_abilities();
echo "Registered abilities: " . count( $abilities ) . "\n";
foreach ( $abilities as $ability ) {
	$public = $ability->get_meta( "mcp" )["public"] ?? false;
	echo "  - " . $ability->get_name() . ": " . ( $public ? "public" : "private" ) . "\n";
}
'

A clean migration reads: Abilities API “yes”, PHP AI Client matching whichever core version you’re on, MCP Adapter plugin “active” if you intend agent connectivity at all, and every ability listed with the visibility you actually intended, not a default you forgot to check.

Keep this script in your project

This is worth committing as a small WP-CLI command or a debug page in your own plugin, rather than something you retype from memory every time you touch this part of the codebase. Migrations aren’t one-time events, a future contributor adding a new ability will benefit from the same quick check.

Test it: a last confirmation against a real client

Reconnect an actual MCP client (Claude Desktop, Cursor, or whatever you use day to day) and confirm the tools it lists match Step 3’s “public” abilities exactly. This is the real end-to-end proof the migration succeeded, everything before this point is necessary but not sufficient on its own.

A migration checklist isn't a one-time event

Treat this checklist as something to rerun whenever you add new abilities or update WordPress core, not a box you check once and forget. The most common way migrated codebases regress is a new contributor, unaware of this course’s history, reintroducing one of these exact mistakes on a new feature six months later.

Recap

This course corrected a specific, real misconception (that the MCP Adapter shipped in WordPress core) and walked through the concrete work that follows from getting it right: dropping the archived wordpress/abilities-api Composer package now that its functionality lives in core since 6.9, updating local environments to target the correct version, fixing the single most common visibility bug (meta.mcp.public), auditing for subtler deprecations, testing across the 6.9/7.0 boundary that actually matters (the PHP AI Client), and correcting any code or documentation built on the same false premise this course itself opened by rejecting.

Where to go next

With a corrected foundation in place, WordPress AI Foundations is worth a second pass if it’s been a while since you read it, its own first lesson now maps cleanly onto everything covered here. If you haven’t built a fresh MCP server the current, correct way, Build a WordPress MCP Server From Scratch is the natural next step, using the same core Abilities API and separate MCP Adapter plugin this course confirmed are the real, current architecture.

Resources & further reading

← Migrating Custom Code That Assumed MCP Adapter Was Core Finish ✓