Connectors: account for mu-plugins when resolving plugin.file status

[Adi-ty]

What?

Closes #76984

This PR updates connector plugin status detection so connectors continue to appear when their plugin is installed as a must-use plugin.

Why?

The connectors screen was checking plugin.file in the regular plugins directory only.
If a connector plugin was moved to mu-plugins and loaded via a mu-plugin bootstrap file, the connector could disappear even though the plugin was in use.

How?

• For connector plugin.file, check both: WP_PLUGIN_DIR and WPMU_PLUGIN_DIR
• Mark plugin as activated when it is found in mu-plugins (mu-plugins are always loaded), or it is a regular plugin and is_plugin_active returns true.

Testing Instructions

1. Start wordpress-develop trunk with Gutenberg plugin active from this branch.
2. Ensure Akismet exists in wp-content/plugins/akismet and is not activated.
3. Visit Settings > Connectors.
4. Confirm Akismet connector is shown.
5. Move Akismet to wp-content/mu-plugins/akismet.
6. Create wp-content/mu-plugins/a.php with:<?php require_once __DIR__ . '/akismet/akismet.php';
7. Reload Settings > Connectors.
8. Confirm Akismet connector is still shown.

Screenshots or screencast

Before	After

Use of AI Tools

[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: Adi-ty <iamadisingh@git.wordpress.org>
Co-authored-by: peterwilsoncc <peterwilsoncc@git.wordpress.org>
Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>

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

[peterwilsoncc]

The location of a plugin relative to mu-plugins is a little less predictable than it is in the plugins directory.

It may be in the location mu-plugins/slug/file.php but depending on how the developer has configured their site, it might just as easily be in mu-plugins/file.php, mu-plugins/vendor/slug/file.php or some variation of all of these.

The most robust approach to determine if a plugin is active is to check if a function or class exists.

This would require allowing the plugin developer registering the connector to provide a callback. Using Hello Dolly as an example the callback would be:

is_active => function() { return function_exists( 'hello_dolly_get_lyric' ); }

If the callback returns true the plugin can be considered active, regardless of any other checks.

[Adi-ty]

The location of a plugin relative to mu-plugins is a little less predictable than it is in the plugins directory.

It may be in the location mu-plugins/slug/file.php but depending on how the developer has configured their site, it might just as easily be in mu-plugins/file.php, mu-plugins/vendor/slug/file.php or some variation of all of these.

The most robust approach to determine if a plugin is active is to check if a function or class exists.

This would require allowing the plugin developer registering the connector to provide a callback. Using Hello Dolly as an example the callback would be:

is_active => function() { return function_exists( 'hello_dolly_get_lyric' ); }

If the callback returns true the plugin can be considered active, regardless of any other checks.

Thanks for the thoughtful feedback, this makes sense.

Planning to go with an optional is_active callback on connector registration if provided, it becomes the source of truth; if absent, the existing fallback (path checks + is_plugin_active()). For Akismet I'd use a class existence check like

'is_active' => function () {
	return defined( 'AKISMET_VERSION' ) && class_exists( 'Akismet', false );
},

Does that align with what you had in mind, or do you see edge cases I should account for?

[jorgefilipecosta]

I think we may have a connector passing an is_active callback, is_active returning false, but the plugin be installed. When call_user_func( $connector_data['plugin']['is_active'] ); returns false we should probably check if the plugin is_installed file_exists( WP_PLUGIN_DIR . '/' . $file ).

[jorgefilipecosta]

I think we may be able to avoid this Akismet specific logic in core by having Akismet registering a connector which overwrites the core one with the is_active callback.

[jorgefilipecosta]

When is_active is not provided we know the plugin was not active and could rely on the normal core file exist checks.

[jorgefilipecosta]

cc: @bluefuton

[jorgefilipecosta]

For all AI providers (included in core or not), we don't expect them to need to register providers, and we have standardized ways to check if they are active e.g: via plugin, so we should probably have a default customized is_active solution for these. But I can take of that, just leaving a comment to not miss it.

[jorgefilipecosta]

Thank you for working on this @Adi-ty just left some comments but the direction seems good 👍

[Adi-ty]

Thank you for working on this @Adi-ty just left some comments but the direction seems good 👍

Thanks for the feedback @jorgefilipecosta

I've removed the hardcoded Akismet-specific logic from core and prioritised the is_active callback before falling back to is_plugin_active() and file_exists() for standard plugins. I'm also happy to handle the backport for these changes to WordPress Core once we’ve finalized the logic here.

[jorgefilipecosta]

The logic looks good to me 👍 cc: @gziolo

[github-actions]

I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: e2970ba