feat: check wp_supports_ai() before initializing experiments

[justlevine]

What?

Part of https://core.trac.wordpress.org/ticket/64706

This PR adds a check for wp_supports_ai() before initializing specific AI experiments.

Why?

wp_supports_ai() will allow for sites to completely disable AI functionality via a WP_AI_SUPPORT constant and the wp_supports_ai filter. Our plugin should respect that.

• fix: add wp_supports_ai() and related constant + filter wordpress-develop#11149

How?

• Currently the check happens in bootstrap.php and prevents the entire plugin from loading, due to implementation details from the 0.1.0. scaffold that make it unwieldy to check on a per-experiment level.

  While technically there can be Experiments (less likely full-on Features) that don't require AI to run (e.g. the Abilities Explorer), since we'll anyway need to refactor a significant about of boilerplate for the transition to canonical AI plugin it seems like a waste to detangle now.

• The admin notice triggers on both admin_notices and network_admin_notices. Assumedly it's an unintentional omission on the other notices from the initial implementation, that should also be handled during the aforementioned cleanup.

Use of AI Tools

N/A

Testing Instructions

1. Checkout fix: add wp_supports_ai() and related constant + filter wordpress-develop#11149
2. Set define( 'WP_AI_SUPPORT', false ); in your wp-config.php and ensure you see an admin notice and the plugin doesn't load.

Testing Instructions for Keyboard

Screenshots or screencast

Before	After

[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: justlevine <justlevine@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>

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

[justlevine]

Labeled this blocked until https://core.trac.wordpress.org/ticket/64706 is in core.

[Copilot]

Pull request overview

Adds an explicit AI-capability gate so the plugin does not initialize (and instead informs admins) when WordPress has AI support disabled via wp_supports_ai().

Changes:

• Introduces check_ai_support() to detect disabled AI support and register an admin notice.
• Updates load() to include the AI support check alongside PHP/WP version requirements.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.44%. Comparing base (e63d8c0) to head (e1e3446).
⚠️ Report is 12 commits behind head on develop.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #268      +/-   ##
=============================================
+ Coverage      67.41%   67.44%   +0.02%     
  Complexity       907      907              
=============================================
  Files             59       59              
  Lines           4352     4356       +4     
=============================================
+ Hits            2934     2938       +4     
  Misses          1418     1418              

Flag	Coverage Δ
unit	67.44% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gziolo]

Overall, this looks good. It needs to be brought up today after the core patch lands.

[jeffpaul]

Punting to 0.7.0 as we'll likely get 0.6.0 out before RC1 / when the linked Trac ticket will get to a resolution.

[jeffpaul]

Now that the upstream PR/patch has been merged, @justlevine @dkotter do we want to refresh this PR such that Features and Experiments that rely on an LLM are disabled respectively? Something like Abilities Explorer still seems like something that could be enabled.

[justlevine]

@jeffpaul next item on my cleanup list is the Bootstrapper. between that and the changes in #316 I think we're in a good place to only disable AI specific functionality before WP7.0 🤞

[jeffpaul]

@dkotter given there's still discussion and no set agreement on the upstream work, I'm inclined to punt this to 0.8.0 in hopes that things will settle upstream and allow us to properly extend in the AI plugin?

[dkotter]

@dkotter given there's still discussion and no set agreement on the upstream work, I'm inclined to punt this to 0.8.0 in hopes that things will settle upstream and allow us to properly extend in the AI plugin?

Works for me. Also lots of test failures here that need looked at first

[jeffpaul]

@justlevine looks like the upstream PR has landed, mind coming back to this so we can appropriately respect things within the AI plugin if someone has toggled OFF LLMs?

[justlevine]

PR has been updated to fully require that WP_AI_SUPPORT isnt disabled.

do we want to refresh this PR such that Features and Experiments that rely on an LLM are disabled respectively? Something like Abilities Explorer still seems like something that could be enabled.

This is still on my to-do, but I think it's worth merging this already and then handle the per-feature scoping in a followup.

Tl;dr the next step is to turn the entire Dependencies class into something that could be reusable by individual Features, although instead of an admin_notice, we'd assumedly want to show it in the Settings UX as toggle requirements etc and other things I want to think about and shouldn't require breaking changes to iterate to.