🇮🇳India @nikunjkotecha

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

MR merged

Considering workaround is possible in 9.x and 9.x is no longer supported I am inclined towards not doing any fix for this.

Wrong project in previous comment
Considering workaround is possible in 9.x as explained in https://www.drupal.org/project/search_api_algolia/issues/3381297 🐛 Algolia Library Version Active and 9.x is no longer supported I am inclined towards not doing any fix for this.

Need an MR to review and merge.

@alex9000

I recommend to move to latest version and/or provide steps to reproduce with configurations (you can redact secret info)

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

@vasyok please share more details

Can we please have full steps to reproduce so we can review the patch and confirm the fix?

Details required
* Content type
* Taxonomy / reference fields
* Views, what field is the filter applied on

Also, how is this different from https://www.drupal.org/project/search_api_algolia/issues/3352807 🐛 Views "IN" filters not working Needs review ?

Can we please have full steps to reproduce so we can review the patch and confirm the fix?

Details required
* Content type
* Taxonomy / reference fields
* Views, what field is the filter applied on
...

Also, how is this different from https://www.drupal.org/project/search_api_algolia/issues/3223351 ✨ Handle 'IN' operator Needs review ?

Closing in favour of https://www.drupal.org/project/search_api_algolia/issues/3256840 ✨ Item splitter processor to avoid record size limit Postponed: needs info

Closing in favour of https://www.drupal.org/project/search_api_algolia/issues/3256840 ✨ Item splitter processor to avoid record size limit Postponed: needs info

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

Thanks Jan.

privacy by design / privacy be default

I belive this is enough to say we should have a config. However it should be applied only if required. Meaning, by default there should not be any limit but only if a configuration is enabled it would set the expiration time, only if it is not already set (even if it is set to 15 days and configuration is 10 days it should stay 15 days).

In the PR I would expect
* New configuration in the module to allow setting this expiration, default value 0
* Config form to set the value in hours
* Override the cache set function and set the default value for $expire to null
* if it is NULL, set the default if available in config, if not available set it still to Cache::PERMANENT
* Call parent function

This is very high level, feel free to modify based on issues you encounter while implementing. Only thing is the function in the class should only set expire if it is NULL and it should not copy/paste code, call parent instead

Lastly, please update tests.

Please raise MR against 4.0.x and also check Error handler has changed error

Hi Jan,

Setting expiration time of cache is available out of the box, any reason we should not use that?

This module only provides way to cache data, it doesn't decide whether the data is product for commerce or customer information. In my opion it is upto the dev team to use it as per the requirements and make sure any compliance is maintained.

Drupal CORE uses garbageCollection to removed expired entries which is not overridden. Meaning, if the custom code ensures cache expiration time is set to 14 days instead of -1 it will be removed automatically.

Merged into 4.0.x, will create new release for it

too many changes, little hard to review

I will try and validate the code changes in my project

To be honest it makes sense to add the check but I am just wondering how was the data indexed?

Is there an exception even when indexing data?

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

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

@mediabounds @segi

Apologies for the delay.

Can you please rebase your changes with latest, test once and confirm?

I will merge in max 2 working days after you update.

This got merged into another (more recent ) ticket, apologies for this. I should have started looking from old to new.

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

Fixed in https://www.drupal.org/project/pcb/issues/3451251 📌 Automated Drupal 11 compatibility fixes for pcb Needs review

Please check if https://www.drupal.org/project/search_api_algolia/issues/3437458 ✨ Add ability to "Partially update" items instead of overriding. Fixed fixes the issue.

If need more support please add more details, steps, use case to understand and try to develop.

can we have some steps to reproduce?

For my project we do import database from different environment but indices are never deleted.

This is good. I am not convinced though that we should index huge objects in Algolia, can we have some real use case to help understand the need for this?

Will create 4.x for git clone git@git.drupal.org:project/mobile_app_links.git
Will merge this in 3.x

This looks interesting, need to test and confirm this.

Please provide some details / screenshots if possible to confirm the functionality.

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

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

We should add more details and make it an error

I reviewed both and considering that merge of 26 will start giving errors for the lint I am thinking of merging https://git.drupalcode.org/project/search_api_algolia/-/merge_requests/2..., @David, any other reason apart from ticket scope?

Will create new release in this week after reviewing and merging all the bugs which are ready for review.

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

joseph.olstad → credited nikunjkotecha → .

Policy should be added even if $route is empty, right now if $route is empty it doesn't add Referrer-Policy header

Check the headers tab Arun :)

Drupal 9 code:
=?UTF-8?B?2YXZiNmC2Lkg2KfYrtiq2KjYp9ixINiv2LHZiNio2KfZhA==?=

Drupal 10 code:
=?utf-8?Q?=3D=3Futf-8=3FQ=3F=3DD9=3D85=3DD9=3D88=3DD9=3D82=3DD8=3D?= =?utf-8?Q?B9=5F=3DD8=3DA7=3DD8=3DAE=3DD8=3DAA=3F=3D?= =?utf-8?Q??= =?utf-8?Q?=D8=A8=D8=A7=D8=B1_=D8=AF=D8=B1=D9=88=D8=A8=D8=A7=D9=84?=

@arunkumark

* Please add Tamil characters in Site Name
* Please try to install both Drupal 9 and Drupal 10 and compare the number of UTF8 characters in FROM address

Issue is that the number of characters increases drastically (with D9 we had around 79 characters and for the same text in D10 it became 358 characters.

Number of characters limitation may be environment specific but increase in characters can be reproduced. (you can check the original headers of the mail to observe this)

One reason to support stdClass explained in https://medium.com/@joshirohit100/drupal-8-custom-normalizer-c9d71c06c6e

We are supporting this today using custom normaliser, it would be great to have support in CORE.

Please release a new version 4.0.1, I see tag is already created but release is not created

https://git.drupalcode.org/project/endroid_qr_code/-/compare/4.0.0...4.0...
https://git.drupalcode.org/project/endroid_qr_code/-/compare/4.0.1...4.0...

Thanks Snadeep.

We will need tests for this so moving to needs work.

I agree, changing the validation should be based on configuration.

Thanks everyone, I would really appreciate if we can have some tests added to the patch.

I am trying to reproduce and confirm the fix and improve the solution (make it generic and work even without inline_form_errors module), I have got radios working but not able to make normal required validation work for checkboxes.

Thanks Robert for the patch, added tests to validate the solution.

https://git.drupalcode.org/project/clientside_validation/-/merge_request...

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

I am sorry Selwyn, I tried with exact same steps with vanilla Drupal and PCB module but I am not able to reproduce the issue.

Is there any other customisation done around caches in your code?

Hi @sophron,

I think this should be in webform module as the file you are referring to is inside webform?

This looks like Drupal CORE issue, will try to dig a little.

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

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