feat: Enhance Connectors page on read-only file system

[coderGtm]

What?

Closes #77352

This PR addresse the following:

• Adds a notice to inform users why connectors are not available on their installation.
• Shows the AI plugin bannerbut without the Install button.
• The paragraph at the bottom remains, with an external link to the tag search on the plugin directory (https://wordpress.org/plugins/search/ai-connectors/) when the DISALLOW_FILE_MODS constant is true.

Why?

... because a user is completely blocked from knowing how to enable the AI functionality. I know that on Pantheon, for example, all production live environments have a readonly filesystem. This is an issue for any site configured with the DISALLOW_FILE_MODS constant enabled in wp-config.php. Users will have no idea how to proceed.

How?

TODO

Testing Instructions

TODO

Screenshots or screencast

Before	After

Use of AI Tools

GitHub Copilot was used in part for coding purposes. All code has been reviewed by me before pushing it.

[westonruter]

Idea: Instead of including the WP-CLI commands here, what about including them inline with each respective plugin? This should allow them to make more sense in context.

[coderGtm]

Personally, I don't find the idea of displaying wp cli commands (anywhere on this screen) very appealing.

The average user hanging here and facing this situation should only be informed that installing plugins is not possible from here (as per your new notice text). We should mention a couple of ways they can try like "using WP CLI or FTP" Adding specific commands is too much technicality imo for this screen, apart from the fact that it is the job of the docs. It also adds the extra overhead of maintaining the command accuracy in the long run.

Just sharing my point of view.

[westonruter]

Maybe they can be hidden in DETAILS element so developers can expand to get the command (and most importantly, the slug).

[coderGtm]

Agreed. So here we are now!

[westonruter]

I meant inline with each provider. So in the Anthropic card, there'd be the WP-CLI command to install that plugin if it is not installed. No need for the slug beforehand either, as that is already shown in the command.

[audrasjb]

Hello, I wouldn't show the WP-CLI command first (or event at all), I would rather link to the official documentation on Manual plugin installation.

The "normal deployment workflow" described in the official documentation of WordPress doesn't list any WP-CLI command 😉

[westonruter]

Humm. WP-CLI isn't mentioned in those docs, but we can always add that. Nevertheless, are those docs translated?

At least if we link off to the plugin on the directory then the user can figure out what the slug is for installation via WP-CLI. I was just hoping to reduce the significant friction the user is facing when confronted with this state.

[coderGtm]

I also think that directly showing the WP-CLI commands is too much technicality on the screen.

At least if we link off to the plugin on the directory then the user can figure out what the slug is for installation via WP-CLI. I was just hoping to reduce the significant friction the user is facing when confronted with this state.

Yes I also was thinking about the same. Maybe we can go this way: We just link the manual installation doc in the notice without showing the commands and then, in the cards, instead of showing "Not available", we can link the wordpress.org page for the plugin. This way a technical user would also be able to easily figure out the slug and a non technical user can reach the correct official plugin page instead of something else.

[JasonTheAdams]

Agreed, we shouldn't assume the user is technical. We could also encourage the user to contact their site manager or some such person for installation. I think a link to the plugin on .org so the user can learn more about it, get the slug, and so forth is sensible! 👍

[westonruter]

See also comments starting at #77352 (comment)

[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: coderGtm <gautam23@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: audrasjb <audrasjb@git.wordpress.org>
Co-authored-by: JasonTheAdams <jason_the_adams@git.wordpress.org>
Co-authored-by: justlevine <justlevine@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>
Co-authored-by: fcoveram <fcoveram@git.wordpress.org>

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

[jeffpaul]

May be worth updating to use the notice from wp/ui, example: WordPress/ai#490.

[coderGtm]

Will do it. Also I think the text at the bottom should be updated as per the new design of the screen shared in #77352 (comment)

[t-hamano]

Adding the backport label as this PR seems to be expected to be included in 7.0

[coderGtm]

Updated the notice component but had to use // eslint-disable-next-line @wordpress/use-recommended-components

Do we have any concensus on the next steps?

Do we remove the WP CLI commands and just add the 2 buttons as shown in the image in #77352 (comment)?

Also, do we replace the "not available" text with an external link for the plugin?

[westonruter]

I think so. While still waiting for feedback on the design, I think it is safe to skip WP-CLI and replace the "not available" text with a "learn more" link to the plugin on the directory.

[t-hamano]

@WordPress/gutenberg-design, If you have the bandwidth, I would appreciate your design feedback.

To test, simply run the following command.

npx wp-env run cli wp config set DISALLOW_FILE_MODS true --raw

Then, after testing:

npx wp-env run cli wp config delete DISALLOW_FILE_MODS

[jorgefilipecosta]

I tried to apply all feedback it is ready for another review:

[t-hamano]

Overall, it looks good.

Regarding the removal of the WP-CLI command examples, what are your thoughts, @westonruter?

[westonruter]

And of course, how it looks when installation is available (and after I installed Anthropic):

[github-actions]

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

[t-hamano]

Heads up - we should not have used the Notice and Link components in this PR, as these have not yet been implemented in wp/7.0. Furthermore, the @wordpress/use-recommended-components rule does not exist either.

In fact, the static check is failing on the wp/7.0 branch: https://github.com/WordPress/gutenberg/actions/runs/25574179820/job/75077130438

Fortunately, no critical errors occurred in the 7.0 release, but these components are not displayed when DISALLOW_FILE_MODS is true.

WordPress 7.0 RC3	Gutenberg trunk
Note: The area that should display Learn more is showing Not available, which is an issue that requires further investigation.

Perhaps it should be replaced by components/Notice in the wp/7.0 branch, but I'm curious as to why the WordPress release process didn't detect this issue in the first place 🤔 cc @WordPress/gutenberg-components

[t-hamano]

Note: The area that should display Learn more is showing Not available, which is an issue that requires further investigation.

This problem should be fixed once changeset 62341 is backported to 7.0.