[Tracking 📌] Path to WordPress.org Plugin Directory

[justlevine]

With submission to W.ORG approved, it's time to get this repo polished and ready for submission.

This is a nonexhaustive list of steps that need to happen:

TODO

• Align plugin scaffolding to WordPress/ai (in particular, there's some required files missing like readme.txt) @justlevine
• Run plugin-check and remediate exposed issues ci: Add PCP workflow #187
• Bump minimum WordPress to v6.9 feat!: bump minimum WordPress to v6.9 #197
• Cleanup and update install docs to prioritize usage via plugin (and wpackagist/wp-packages for Composer)
• Make plugin backwards-compatible with Composer Library + migration docs (May require an intermediary)
• Optional: Enforce SemVer auto-updates protection.
• Submit to W.ORG

Comment below if I'm missing something, and I'll add it to the list

[justlevine]

Optional: Enforce SemVer auto-updates protection.

@galatanovidiu This question is for you. Are we expecting to need to issue future breaking changes (e.g. updating/dropping schema versions?)

If so, then I'll add a modal warning to prevent autoupdates to major versions. If you think we're ready to keep things backwards, we can skip this and only introduce if the need presents itself in the future.

[galatanovidiu]

Optional: Enforce SemVer auto-updates protection.

@galatanovidiu This question is for you. Are we expecting to need to issue future breaking changes (e.g. updating/dropping schema versions?)

If so, then I'll add a modal warning to prevent autoupdates to major versions. If you think we're ready to keep things backwards, we can skip this and only introduce if the need presents itself in the future.

I'd skip it for now. The schema package is still additive (0.1.1), the spec move from 2025-06-18 to 2025-11-25 was additive only, and the adapter already negotiates all three protocol versions side by side, so older clients keep working. If we ever hit a real break that forces a major bump, we can add the modal then with a concrete context for users.

[justlevine]

Noting: as part of updating docs/cleanup we need to explicitly bump minimum WP to 6.9 (tooling+ci were bumped in #185, #189 #193 )

[andreilupu]

Hi @justlevine 👋 I'd like to help push this further, and I'd be happy to put some time and energy into it. Engineering, testing, docs, or anything else, as long as it's helpful.

[gziolo]

Thanks @andreilupu. Help would definitely be useful here.

I think @justlevine is probably best placed to clarify the exact remaining work for the WordPress.org submission, especially around the open checklist items.

From my side, the important next step after the plugin is accepted into the WordPress.org Plugin Directory would be integrating it into the AI plugin as an experiment. The direction discussed elsewhere is:

• MCP Adapter remains a standalone WordPress.org plugin
• the AI plugin exposes MCP support through an experiment or connector-style toggle
• enabling the experiment automatically installs and activates MCP Adapter if it is not already active
• once enabled, the AI plugin surfaces the UI or screen for managing MCP access, controlling what gets exposed and giving site owners a clear place to manage it

That would keep the adapter reusable by other plugins while letting the AI plugin provide the user-facing control layer. It also avoids making the initial MCP Adapter plugin submission depend on the AI plugin integration.

So maybe the immediate ask is:

1. @justlevine, could you confirm what still blocks the WordPress.org submission?
2. Once that is clear, contributors can help with the remaining docs, testing, and submission tasks.
3. In parallel, or as a follow-up, we can track the AI plugin experiment or connector integration separately.

[abhi3315]

Went through the repo against the open items instead of adding another question to the pile.

Composer library / migration docs

Looks like #172 (closed yesterday) already settles the design half of this. MCP Adapter ships as canonical, anything bundling it resolves the same WP\MCP classes through Jetpack Autoloader, prefixed copies aren't supported. And release.yml sets COMPOSER_ROOT_VERSION from the release tag, so "newest copy wins" actually works against a bundled older copy. So the build side is handled.

The docs haven't caught up though. README.md, docs/getting-started/installation.md and docs/troubleshooting/common-issues.md all still say Jetpack Autoloader is "highly recommended". That was fine before #172. Now it's the support boundary for anyone vendoring the library, which is a stronger statement.

So is what's left here mostly restating that across the docs, plus a migration note for sites that vendor the library and then install the plugin on top? Or is "may require an intermediary" pointing at a release sequencing problem I'm missing?

Packaging

• .wordpress-org/ isn't there yet, even though .gitattributes already export-ignores it. Banner and icon need to exist before the listing looks right, and they go to SVN assets/ rather than into the zip. Screenshots probably don't matter for a first release since there's no admin UI in trunk yet (feat(admin): add Settings > MCP Adapter page to opt registered abilities into the default server (fixes #183) #184 still open).
• Nothing deploys to .org. release.yml builds with wp-scripts plugin-zip and attaches the artifact to the GitHub release, that's it. WordPress/ai has wporg-plugin-deploy.yml. Whoever adds one will need the SVN credentials as repo secrets.
• Small one: package.json files lists LICENSE and CHANGELOG.md, but the repo has LICENSE.md and no changelog at all. Drift, or am I missing something?

readme.txt

38 lines, just Description / Installation / Changelog.

• Changelog links out to GitHub releases, so the Changelog tab on the .org page will be empty at launch.
• Contributors: is only wordpressdotorg, even though props-bot runs here.
• Installation still tells people to grab the GitHub release. I think that's the same work as the "cleanup install docs" item, just in the readme instead of docs/.
• No FAQ section.

Happy to take the readme.txt pass now, and the #172 docs cleanup if my read is right and @andreilupu isn't already on it. I work on Duplicator, so the .org review queue is familiar ground.

I can write the deploy workflow too, but it can't be tested until the SVN secrets exist. On assets I can scaffold the directory, but the banner and icon should come from whoever knows the AI team's branding.

One question: is the .org slug already reserved, or is submission still to be filed?