[WIP] feat/489: Add Rewrite Tone feature

[Sidsector9]

Description of the Change

Closes #489

Screencast

The Tone Rewriting options are preserved in local storage so that the admin does not have to perform the same selection every time.

Screen.Recording.2025-03-03.at.4.57.22.PM.mov

How to test the Change

Changelog Entry

Added - Rewrite Tone feature.

Credits

Props @jeffpaul @Sidsector9

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All new and existing tests pass.

[Sidsector9]

Update

The Rewrite Tone feature is integrated inside the Chat UI:

Screen.Recording.2025-04-15.at.1.13.38.AM.mov

[fabiankaegy]

@Sidsector9 still love this :)

Just wanted to quickly share my thoughts:

https://share.cleanshot.com/V6GCYlJ8

[Sidsector9]

@fabiankaegy thanks for the input.
I'm having a difficult time integrating Rewrite Tone as per your suggestion, while also keeping the ChatUI extendible for any future features that might want to integrate within the ChatUI component.

Currently, a feature can integrate into the ChatUI using the following filter:

const featureTabs = applyFilters( 'classifai.chatUI', [] )

• The ChatUI then uses the TabPanel component to loop over featureTabs and render Slot with a unique name.
• Each feature can then use the unique name and render the content in the Slot using a Fill.

Your suggestion can be implemented by introducing a Slot inside the Content Generation feature, and the Rewrite Tone feature can Fill within that Slot. My question is, should all future-features leveraging the ChatUI populate the same way?

But this creates another issue, if Content Generation Feature is disabled, but the Rewrite Tone feature is enabled, then the Slot inside Content Generation won't work.

[jeffpaul]

So I think there are two separate concerns we're talking about here. (1) visually how the UX/UI works/looks in the Chat UI interface. (2) how the ChatUI component exists within the codebase and can be extended.

On (1), I believe this is more generally where @fabiankaegy is commenting and providing guidance. I think sorting out the optimal UX/UI handling within the Chat UI interface is something we should precise about as this PR gets merged in (as we're now potentially using that interface for more than one feature and now is the right time to sort things out better).

On (2), I believe this is more generally where @Sidsector9 is commenting and expressing concern. I agree that the Chat UI experience should be part of a top-level ClassifAI plugin component that features could inherit into. And if no features are enabled that utilize the ChatUI, then it won't appear in the editor. But having the ChatUI exist within the Content Generation feature that other features like Rewrite Tone need to inject into feels sub-optimal.

But this creates another issue, if Content Generation Feature is disabled, but the Rewrite Tone feature is enabled, then the Slot inside Content Generation won't work.

Sid's comment here expresses things fairly well on this (2) topic.

cc: @dkotter for review/input.

[dkotter]

I agree that the Chat UI experience should be part of a top-level ClassifAI plugin component that features could inherit into. And if no features are enabled that utilize the ChatUI, then it won't appear in the editor. But having the ChatUI exist within the Content Generation feature that other features like Rewrite Tone need to inject into feels sub-optimal.

Yes, this is correct. We'll need to refactor the code that renders the experience right now to make it not dependent on the Content Generation Feature. My thought would be to go with the slotfill approach where each Feature can register what they need within the experience (and properly enqueue that) and then each Feature will also be responsible for enqueuing the default ChatUI code (with WordPress being smart enough to not load that multiple times if multiple Features are in use)

[Sidsector9]

My thought would be to go with the slotfill approach where each Feature can register what they need within the experience (and properly enqueue that) and then each Feature will also be responsible for enqueuing the default ChatUI code (with WordPress being smart enough to not load that multiple times if multiple Features are in use)

@dkotter This is exactly how it is currently implemented. If you disable Content Generation but keep Rewrite Tone enabled, the ChatUI would still show, but the downside to this approach is that it makes it difficult to implement the UI that Fabian is suggesting.