External AI Chatbot Functionality

was going to review the MR but then realised it looked AI generated so not going to

@tim.plunkett let me know this is ready for review, I will try to do that tomorrow

New component!

kunal.sachdev → made their first commit to this issue’s fork.

Created a follow-up issues in which we can add tests [PP-1] Add test coverage for Experience builder AI submodule. 📌 [PP-1] Add test coverage for Experience builder AI submodule. Active .

I tried using Vite as per request in this comment but I am unable to get the CI passing for the UI checks.

This will add a composer dependency to ai_agents/ai_agents to every site that uses experience builder, even if they never install this module. As a result will also mean that XB is unable to be fully compatible with major versions of Drupal core until https://www.drupal.org/project/ai_agents → is.

Making it a separate project that depends on both xb and ai_agents would avoid both of these issues.

I tried reverting the changes in this commit but still the tests were failing.I am wondering that could this be because of some random wait?I see that explicitly the wait was set to 40000.
I am unable to get the Cypress running on my local(DDEV) machine so it's hard for me to figure out what's causing this to fail.

This will add a composer dependency to ai_agents/ai_agents to every site that uses experience builder, even if they never install this module. As a result will also mean that XB is unable to be fully compatible with major versions of Drupal core until https://www.drupal.org/project/ai_agents → is.

Making it a separate project that depends on both xb and ai_agents would avoid both of these issues.

I don't think we should move this to a separate project. There will be a deep integration to XB from this module so moving this to a separate project will cause overhead given that you'd often likely have to modify both XB and this module. It will make managing versions / dependencies between the modules complicated too.

Could we remove the module from the main composer.json file? We will have to install these in the CI but is that something we could do without introducing a hard dependency? This would solve the former problem, but not latter. I think the latter we could accept as a risk.

. There will be a deep integration to XB from this module so moving this to a separate project will cause overhead given that you'd often likely have to modify both XB and this module.

So while XB is trying to reach beta and stability, if a critical change in XB breaks tests in this module, is that going to then prevent the change being made in XB? Seems like it would be better for that overhead to be isolated in a separate module.

tim.plunkett → credited balintbrews → .

Adding credit

So while XB is trying to reach beta and stability, if a critical change in XB breaks tests in this module, is that going to then prevent the change being made in XB? Seems like it would be better for that overhead to be isolated in a separate module.

Yep that seems like an acceptable trade-off to me for now to be able to move much faster towards a good user experience. We might want to reconsider that decision in future, but since this is not being built as a proper extension, it would be really challenging to get to this experience if this was kept in a separate module.

I had no idea this was happening — intriguing!

Can we get some screenshots and/or screencasts for when I blog about this? (And for others to see what it looks like.)

Also: zero tests? 😱

I think there's now enough actionable feedback on the MR.

I agree 📌 [PP-1] Add a new subagent for moving the components using experience builder AI. Active should be a follow-up.

And apparently @lauriii +1'd already that tests would be done in a follow-up: 📌 [PP-1] Add test coverage for Experience builder AI submodule. Active . Where was that discussed? 🤔 Can we at least describe in that issue what things will be tested? 🙏

But, I think all of these should be addressed in this MR:

1. 🐛 [PP-1]Uninstalling the Experience builder AI module leaves some configs behind. Active (just adding a few lines to new config — see ✨ Delete xb_avatar on uninstall Active for an example)
2. 📌 List all the available components in ListXbComponents not just plugins. Active (simply using Component::loadMultiple() instead of the SDC plugin manager)
3. 📌 Determine a way for other modules to extend the Experience builder API spec. Active (an example of doing this landed last week in 📌 Personalization Segment internal HTTP API integration Postponed — that follow-up should be repurposed instead to solve the general problem … which I just did: #3528311-3: Split /openapi.yml in multiple files for maintainability → )

@Wim Leers Contributing in a single MR makes it difficult for multiple people to contribute. We want to get away from that as soon as possible because it's already hurting the velocity. The module should be hidden and no one except people developing it should be installing it and therefore the harm from those issues should be minimal.

the harm from those issues should be minimal.

It causes overhead for those reviewing (including me) and triaging the issue queue (which is mostly me).

Trivial things should not be getting follow-up issues. They should be fixed here. Especially if the point is to add a new big part to a repo, intended to be developed mostly stand-alone, then it's important to avoid issue queue management overhead.

It should take <1 hour, probably <30 minutes to address the 3 points in #22. Then I won't have to context switch back to this different space/mindset 3 times. 🙏