🇮🇳India @Vivek Panicker

Tested the issue.

- Applied the patch.
- Did a fresh install of the Drupal site.
- Checked enabled modules: enabled: honeypot, captcha, friendlycaptcha, disabled: antibot .
- Ran the command: ddev drush recipe "../recipes/drupal_cms_anti_spam/" -v
- Checked enabled modules: enabled: honeypot, captcha, friendlycaptcha, disabled: antibot .

Anitbot module is not enabled, but it is however present in the system.
In the MR I see that the dependency on the antibot is removed in composer.json.
Am I missing any step here?

I raised an MR with the fix.
But I get an error like this:

  405   09/Jan 08:07   php    Error      TypeError:                             
                                         Symfony\Component\Yaml\Yaml::parse():  
                                         Argument #1 ($input) must be of type   
                                         string, null given, called in          
                                         /app/docroot/modules/contrib/ai_agent  
                                         s/modules/ai_agents_extra/src/Service  
                                         /WebformAgent/WebformActions.php on    
                                         line 365 in                            
                                         Symfony\Component\Yaml\Yaml::parse()   
                                         (line 73 of                            
                                         /app/vendor/symfony/yaml/Yaml.php).    

I believe it's not related to the code changes. Maybe something I am missing in config.
But the error mentioned in the issue is now no longer appearing.

My bad.
I forgot ai_agents is a different module, and not a submodule.
Hence moving this to ai_agents module.

vivek panicker → created an issue.

I applied the patch and checked the outcome.
I can see 4 styles available for paragraph.
I can see that 3/10 grid column is used.
Only the bottom margins seem to be varying for different styles.
Please check the attached screenshots.

Updated the MR.
Please review.

vivek panicker → made their first commit to this issue’s fork.

@marcus_johansson I applied the patch https://git.drupalcode.org/project/ai/-/merge_requests/377.diff.
Now the chatbot doesn't give the error - "Headers have already been sent".
But when you ask some contextual question, it gives the response -
"I am sorry, but I could not find any relevant information in the archives. Please try to ask the question in a different way or try to ask a different question."
Seems like it's not getting the context for some reason.

The situation is like:

Me: Tell me about xyz product.
Chatbot: xzy is a good product....
Me: What can you tell me about it's availability?
Chatbot: "I am sorry, but I could not find any relevant information in the archives. Please try to ask the question in a different way or try to ask a different question."

If I repeat the above steps again, the same things happen again.

Works fine for admin.
Note: I have provided access to the anonymous, admin and authenticated users in the advanced settings of the AI Assistant.

I am on the dev version with commit ID "591c0ee59e50619861cb81fe39ddbb84a0d25dc9".
The issue still exists.
I am getting a mix of JSON and text explanation.
I asked ChatGPT and it gave me the response: https://www.drupal.org/files/issues/2025-01-03/model_response.md →

So the idea that I liked here is that we can tell it to always respond in JSON.
If some action is there, it will respond with the action key, if no action, then it will respond with some other key, eg. {text: ''}.

Then in our code we can check if text or action and proceed accordingly.
cc: @marcus_johansson

@phjou I agree your solution is better. The cache variation then would only depend on the specific query argument based on the input field name and not on the entire URL. So even if other query args are present, the cached data would ignore those.

Tested the patch.
"Vector DB Explorer" link appears for me on the `/admin/config/ai/explorers` page.
No errors in dblog also.
The patch is good to go.

I believe we can ignore that one since it's not related to the work we are doing here.

Hey @mattlc!
I agree that's a better solution to the current one.
Would you like to implement it?

Seems like all tests are passing now.

@debdeep.mukhopadhyay The same person who codes, cannot move the issue to RTBC. Fixing the issue state to Needs Review.

I tried the patch provided in #4.
But it doesn't work properly for me.
I get the following response from the chatbot:

I am sorry, but I could not find any relevant information in the archives. Please try to ask the question in a different way or try to ask a different question.

Works fine for me in admin.

I think using the getTempstore() is what is causing the issue.
Instead we should try to use cookies, as that would reduce the load on the page, and also not cause any caching issues.

To add to this, I find that this happens mainly for Anonymous users.
The issue happens here .
The form response is already set and after that the $http_response->setCallback` is executed.

Asked the Deepchat maintainer about having consent modal here https://github.com/OvidijusParsiunas/deep-chat/issues/321.

vivek panicker → created an issue.

vivek panicker → created an issue.

I see a lot of us are assigning/unassigning themselves from the issue.
Please note that this is not a good practice, unnecessarily pollutes the issue history and makes things difficult for the maintainers.

As you are new contributors, please speak to the mentors in your company about the contribution guidelines.

@dhruv.mittal, @akulsaxena, @lavanyatalwar let's connect on a call to discuss any doubts we have regarding contribution best practices.

Thanks a lot for the quick action @anybody!
Very much appreciated! :)

Hi @berdir, I see the issue has been marked fixed but we don't have a D11 release yet.
Is there any plan to launch a D11 version soon?
We were working on updating our site to D11 and found that this module is not yet compatible.

Hi @anybody, I see the issue has been marked fixed but we don't have a D11 release yet.
Is there any plan to launch a D11 version soon?
We were working on updating our site to D11 and found that this module is not yet compatible.

Thank you @hestenet!
We will ensure to keep following the best practices in the contribution workflow.

hestenet → credited vivek panicker → .

Hi Robert and Nidhish, I have pushed the latest code to the dev branch. Can you please check?

Hey Nidhish.
The code is already there in my local system.
I just need some time to push it. :)
Hence assigning the issue back to myself.

vivek panicker → created an issue.

Thank you!
I myself have not tested it thouroughly.
Will update if I face any issues because of this change.

Hey @scott.
The code change I have pushed takes the vector input param from the query option.
So we can add it to the query during query alter phaese or while writing the vector services provider.

vivek panicker → created an issue.

vivek panicker → made their first commit to this issue’s fork.

Thanks @shalini.

@smustgrave the issue summary is fixed and MR is tested now.

vivek panicker → created an issue.

My bad.
It seems selecting the proper key at /admin/config/ai/vdb_providers/pinecone and re-saving the form resolved the error.
So closing this issue as there is notthing to fix.

vivek panicker → created an issue.

Updated the MR to make it compatible with the latest code version.

I can replicate this issue in D10.3 also in a view block.

Even I am facing this issue on a regular basis on one of the sites I am working on.

Is the Status of the issue correct?

vivek panicker → created an issue.

It has been done partially in https://www.drupal.org/project/ai/issues/3472525 📌 Improvement to Chatbot Needs review .
Still, for numbered list response from AI, it does not display the numbers probably... keeps starting from 1.

vivek panicker → created an issue.

marcus_johansson → credited vivek panicker → .

Wow!
This looks amazing.
I'lll give it a try!

vivek panicker → created an issue.

As discussed with the maintainers Scott Euser and Seogow, the alteration should not be made in the core AI module, but should be made in the Pinecone Provider itself.
Hence closing this issue.

vivek panicker → created an issue.

vivek panicker → created an issue.

vivek panicker → created an issue.

I think this is a very valid suggestion and would not interfere with the Drupal Core routing system also.
We should go ahead with this.
Kernel.terminate would be a good time to do it since by that time the response would already have been sent, so there wouldn't be any extra processing happening during the request.

I have updated the code as required.
Also made some changes in chatbot since namespace was not being passed to the search query when using the chatbot. If required we can handle that as part of a separate issue.

The only concern here is the deletion of items part.
When performing indexing, at first items are deleted from the index. That code was throwing an exception when items were not found in the index. So I added a try catch block.
We need to fix that logic so that we can delete by ID instead of metadata filtering, since deletion by ID is supported for all types of indices in Pinecone.

Added line to index data.

Vivek Panicker → created an issue.

True.
I took a looked at the MR and I didn't find anything off there.

Hi @anybody.
I see that the related issue is already updated.
If I understand correctly, https://www.drupal.org/project/checkall_widget/issues/3459243 ✨ Extend core's Checkboxes Element Active needs to be worked on?

Also I might not be able to devote time to this right now, so will ask a colleague to help to move this forward. :)

Hi @Anybody.
Sorry I missed replying to your earlier comment.
Sure, I'll try to look into the related issue as soon as possible! :)

I guess what @bluegeek9 is mentioning is right and the issue should be closed.

Hi oleksandr.s,
I was working on a custom Ajax form with file upload field, and I faced the issue mentioned in the description.
I followed your solution and it fixed the issue for me too!!! :)
So thanks a lot for the patch!

So that I understand the fix, can you please explain the reason how making the change fixed the issue?

Yes, that is true.
But for facets, we need to install an additional module.
Those who don't install that module and only need search available, which this module provides, for them searching will not work because the fields are not fulltext fields.
I was wondering if we could like have default fulltext fields, then when the facets module is installed, clone the fulltext fields to text fields, using hook_modules_installed().

I just created a new site and I was not aware that only full text fields were searchable.
It took me a long time to get to know this fact.
If indexed fields are fulltext by default, then it would be very helpful for those setting up a new site, since if someone is setting up a search index, they would surely want to search for content also.

Converted patch#7 to MR.

Happy to help! :)

After reading the above comment, I have a question that shouldn't the original field value be checked before rendering, instead of waiting for the render phase to check if the field is empty or not?

Closing this as duplicate of https://www.drupal.org/comment/14984195#comment-14984195 → .

This patch worked for me!

As the issue has been tested and verified by @Kanchan Bhogade, moving the issue state to RTBC.

As @Kanchan Bhogade has already tested the patch and things are looking fine, moving the issue to RTBC state.

As the issue has already been tested by @Yashaswi18 and things are fine, updating the issue state to RTBC.

As @bindu has already tested this issue and mentioned it's fine, moving this issue to RTBC.

Vivek Panicker → created an issue.

Seems like as part of https://www.drupal.org/project/drupal/issues/2407745 → , we have removed some code from the template but missed removing the documentation for it.
That's great actually, becuase that is what helped me to backtrace the changes.

Looks like these changes were done considering the classy theme but it is now breaking in newer versions of Drupal.

So should we revert the code instead to how it was here instead of how it has been done in the current MR?

Regarding setting resizable=>'none', there seems to be an existing CORE issue: https://www.drupal.org/project/drupal/issues/2787025 🐛 Setting #resizable on a textarea has no effect Needs review .

The issue was closed, but I re-opened it since it still exists.

So adding the attribute from the backend is not having any effect, so I marked it resizble: false in the CSS.

I have addressed the feedbacks you have mentioned and updated the MR.

I have raised an MR to fix the issue.
The Twig template seemed to have the variables defined in the docblock but were not using them.
I have added them now back to the code.

I did some debugging and found that the resizable argument is not sent to twig for the text area.

I confirm that this issue still exists on vanilla Drupal 11 install.
My system config is this:

I have generated a Drupal form using drush gen command which provides a text area by default.
I just added `'#resizable' => 'none',` to it.
After doing that, the text area is still resizable.

Thanks @joachim for the explanation.

Vivek Panicker → changed the visibility of the branch aws_bedrock_chat-3443827 to hidden.

Inspiration taken from Autogrow textarea module.

Vivek Panicker → made their first commit to this issue’s fork.

Vivek Panicker → created an issue.

@smustgrave Except for point 2, I have fixed the rest.
Not sure what to do about point 2.
So leaving this issue in the same state.