🇮🇳India @Vivek Panicker

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.

Thanks for the explanation.

Tests are failing because of media_library test https://git.drupalcode.org/issue/drupal-3442833/-/jobs/1413833#L79.
Not sure how to resolve it.

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

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

@prudloff Question: The method expects a CSS identifier as argument. Why are we passing the output of file_get_contents()?

@smustgrave can you please explain a bit more on what all is necessary now?
I can then give it a try.

I have done all that you've mentioned.

> It's meant as a basis for all entity references including entities that are not revisionable as well is config entities.
This point I can understand.
Anyways I have raised an MR.
Let's see what the core maintainers have to say about this.

Seems like a CORE issue.
Trying to fix in https://www.drupal.org/project/drupal/issues/3442267 🐛 Entity Reference Revision not loaded in EntityReferenceFormatterBase Active .

Seems like a Core issue.
Trying to fix in https://www.drupal.org/project/drupal/issues/3442267 🐛 Entity Reference Revision not loaded in EntityReferenceFormatterBase Active .

Vivek Panicker → created an issue.

Thanks @adam-delaney
Much appreciated!

@Indranil Roy has mentioned to me that the issue is resolved now.
Hence closing the issue.

@adam-delaney Hi, just noticed that no credits were given for the contribution.
I believe @sandipta and @MukhtarM should receive credits for the help they've rendered?
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →
Thanks!

@theMusician

> Not sure we need to target against 10.3.x, this should all work against the 11.x branch.
Got it, thanks.

> We'll keep this branch open as more attributes become available.
But we don't have any other code using annotations.
Is there any other code for which we are waiting for the attributes to become available?

> Thank you for your contributions to this work.
Happy to help! :)

No comment on this ticket for past 2 years.
Closing this ticket.
Please feel free to re-open if required.

Code looks good.
Also requirements are fulfilled.
Hence moving to RTBC.

@tjtj can we move the issue to RTBC state if that patch resolves the issue?

Thanks a lot @drumm and @fjgarlin for helping to resolve the issue!

Hello everyone!

Can someone please look into this?

I am not able to contact the module maintainers to help with review/merge of MRs :(

Hello everyone!

Can someone please look into this?

I am not able to contact the module maintainers to help with review/merge of MRs :(

@joachim @anybody, can someone help review the PR please?

@Tarun Chauhan, if you encounter the issue again, please feel free to open this issue.
Closing this for now.

@SteveHanson As the issue does not seem related to Drupal Core, I am closing this issue.
Please feel free to re-open in case you do not agree.
Thanks.

As the issue is very old, I am assuming that newever versions of the project has fixed it.
Hence closing this issue.

Does not look like an issue.
Please follow the steps mentioned by Tanushree Gupta to resolve the issue.
Closing this issue.

As discussed with the maintainer, @hansa11, a new version of the theme is in the works and so this fix is no longer required.
Closing this issue.
@hritick @hansa11, kindly close the MR.

@ak-lbo Gaurav Gupta did not seem to receive any credit for the work done in this issue.
Any reason why?

Patch looks good!

I have raised the MR, but that needs to be targeted against the Drupal 10.3.x branch.
I am not sure how to do that.
Also, we need to thoroughly test this.

Annotations are used by the following Field Formatters:
- AbleplayerVideoFormatter
- AbleplayerSignLanguageFormatter
- AbleplayerRemoteVideoFormatter
- AbleplayerPosterImageFormatter
- AbleplayerChapterFormatter
- AbleplayerCaptionFormatter
- AbleplayerAudioFormatter

We have Attribute available for Field formatter: https://www.drupal.org/node/3420980 →

So we can start working on this.

Happy to help!

@ramil g, actually what I am trying to say is that I am not able to reproduce the issue on a fresh Drupal installation with only this contrib module installed.
So can I request you to try to reproduce the issue on a fresh installation and then note down the exact steps followed to reproduce the issue?

First of all, we get $value == _none only when we intially had given a value for the field and saved the content and later selected None from the options.
So I think that point needs to be mentioned in the description.
The first time we save the content without selecting any value in the term reference field, we get "" in $value.

2nd point is regarding this code:

1.    if ($element['#shs']['settings']['anyValue'] === reset($value)) {
2.     if (!$element['#required']) {
3.        return;
4.      }
5.      elseif (count($element['#options']) > 1) {
6.        $form_state->setError($element, t('You need to select a term from the deepest level in field @name.', ['@name' => $element['#title']]));
7.        return;
8.      }
9.    }

Even when there is _none in $value, still the code seems to return from line 2, since the element is not required.

So I don't get the part where the error is occurring for you.

I see that the form that you have is a bit different from the one that I have, for eg. a toggle button saying "Is Registration".

What I would request you to do is try out the module on a fresh install of Drupal and try to reproduce the issue.
Once you are able to do that, can you update the description with the exact steps you followed to arrive at the problem so that someone else can also reproduce the issue?

@linhnm I tried with the steps mention and see the date correctly appearing on the node page.
I have tried with smart_date_recur version 4.0.3.
Can you tell me what issue you see in front end?

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

@theMusician Opened MR https://git.drupalcode.org/project/ableplayer/-/merge_requests/33.
Hid the uploaded patch files.

Seems some conflict with your existing configurations.

I installed the module on a Drupal 9.5 site and checked this.

Can you ping me in Drupal Slack?
My name is Vivek Panicker.

Followed the Drupal recommentations here and modified the previous patch.

Please provide more details on how to reproduce the issue.

Nice info!
Thanks for sharing!

@slogar32 Hi!
It seems neither me or @ankithashetty received any credit for this :|

I have updated the patch for D10.
Request everyone to review it once.