Content Guidelines: Add plugin extensibility via SlotFill

[aagam-shah]

What?

Adds plugin extensibility to the Content Guidelines admin page via the SlotFill pattern, allowing external plugins to inject custom UI next to each section's Save button.

Why?

Currently, the Content Guidelines page is a closed system with no way for plugins to extend it. The SlotFill pattern is the standard Gutenberg approach for enabling third-party plugin extensibility.

How?

• Adds PluginArea with scope content-guidelines to the page
• Adds ContentGuidelineSectionActions/{slug} named slots in each section
• Exposes fillProps (section, content, setContentGuideline) so plugins can read and update guideline content
• Adds SlotFill reference documentation

Test plan

1. Navigate to Settings → Content Guidelines and verify the page loads without errors
2. Expand each section, edit a guideline, and click Save guidelines — confirm save works
3. Open browser console and run the following snippet to verify SlotFill extensibility:

wp.plugins.registerPlugin( 'test-slot', {
  scope: 'content-guidelines',
  render: () => wp.element.createElement( wp.components.Fill, { name: 'ContentGuidelineSectionActions/site' }, ( { section, content, setContentGuideline } ) => wp.element.createElement( wp.components.Button, { type: 'button', variant: 'secondary', onClick: () => setContentGuideline( 'Test AI generated content for ' + section ), }, 'Generate' ) ),
} );

4. Confirm a Generate button appears next to Save guidelines in the Site section
5. Click Generate and confirm the textarea updates with the test text

[Mamaduka]

Maybe we should let the feature mature a bit before introducing extensibility. Early SlotFills can create constraints and hinder future iterations.

Maybe we could leverage more semantic APIs for extensibility, Fields and DataForms could be suitable for similar pages. cc @oandregal

P.S. In WP it's always easy to add public APIs, but almost impossible to remove them.

[talldan]

I think it does use DataForms, but the buttons are currently not DataForm actions. (edit: actually I think I'm getting confused, DataViews has actions, not DataForms).

I'm assuming 'Generate with Plugin' implies using AI to generate the content. It's not clear to me how that fits in with other AI initiatives. For example, if someone connects 'OpenAI' (using #75833), then it might be expected that 'Generate with OpenAI' is available as an option without needing an extra plugin.

[oandregal]

Agree with George: it'd be good to hold off on adding extensibility and refactor this to work with entity-based extensibility. FWIW, I've started to explore that approach right now for #76045 (site editor extensibility)

[aagam-shah]

Thanks for the feedback, all!

To address @talldan's question about Connectors (#75833) - As per my understanding, I see Connectors as a shared layer for storing API keys and config, but it's still early and could evolve in multiple ways. But I think, there's still a gap between having an API key and generating guidelines: something needs to orchestrate fetching site content, feeding it into the LLM with appropriate prompts, and producing the output. That orchestration is plugin-specific, which is why I was exploring plugin extensibility here.

That said, I hear the concern about committing to a public API surface too early. I'll hold off on this and follow along with @oandregal's work on #76045 to see if entity-based extensibility can serve this use case.

[soderlind]

I've written a guide on how to add an AI provider, and I've added AI Provider for Azure OpenAI