Pull in the various AI dependencies we'll be using

[dkotter]

Description of the Change

The AI Experiments plugin will be building on top of the other AI building blocks, namely the Abilities API, the MCP Adapter and the WordPress/PHP AI Client.

This PR brings all of those in as composer dependencies, though worth a discussion here on if that's the way we want to handle things. We could instead require those to be installed as separate plugins (probably using the Requires Plugins header) or even just rely on what ends up in WordPress 6.9 (at least for the Abilities API).

My opinion here is that by bundling, we make the user experience nicer (don't require multiple additional plugins to be installed) and we control what versions we're relying on (allowing us to use newer things that may not end up in WordPress 6.9). But open to other thoughts.

At the moment, this is what's pulled in:

• v0.3.0 of the Abilities API
• The trunk version of MCP Adapter, as the only current release (v0.1.0) requires PHP 8.1+
• The trunk version of WP AI Client, noting I debated pulling in this branch so we could take advantage of the settings that introduces, but hoping that can be merged in soon
  • Also noting since this plugin isn't recognized by packagist, had to set the repositories config to pull this in

In addition, the MCP Adapter suggests using the Jetpack Autoloader so also pulling that in and switching to loading that over the default composer autoloader.

How to test the Change

1. Checkout this branch locally
2. Run composer install
3. Activate the plugin. Ensure no errors occur. Note that we currently have a bug where our minimum WordPress version is set to 6.9, which isn't out yet. This means WordPress won't allow you to activate the plugin. Can either force this using WP-CLI or temporarily modify ai.php to change 6.9 to 6.8 (this is fixed in Add in various test GitHub Action workflows #49)

Test using WordPress Playground

The changes in this pull request can be previewed and tested using this WordPress Playground instance:

Click here to test this pull request.

[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: dkotter <[email protected]>
Co-authored-by: jeffpaul <[email protected]>
Co-authored-by: gziolo <[email protected]>

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

[gziolo]

https://packagist.org/packages/wordpress/abilities-api#v0.4.0-rc is available now. It contains all the latest and greatest from WordPress 6.9 beta. It will be promoted to the stable release as soon as we confirm it integrates seamlessly with plugins.

[dkotter]

https://packagist.org/packages/wordpress/abilities-api#v0.4.0-rc is available now. It contains all the latest and greatest from WordPress 6.9 beta. It will be promoted to the stable release as soon as we confirm it integrates seamlessly with plugins.

Thanks for the heads up on that. I've updated this PR to pull the 0.4.0-rc version, noting all of these versions will continually be updating as needed going forward but might as well use the latest and greatest from the start

[felixarntz]

Just chiming in here with a thought (not reason to change anything at all, just something to think about): An alternative to trying to only load one version of the dependency would be to prefix the bundled dependencies.

Benefit: More robust, as it prevents conflicts due to minor differences between different versions if one plugin used an API slightly differently.
Drawback: Code will be "unnecessarily" (at least almost unnecessarily) loaded multiple times, and the initial setup is a little more tricky.

It's certainly a tradeoff. But I'd be inclined to eventually document both as reasonable alternative paths for pulling in and loading those dependencies.