🇭🇺Hungary @nagy.balint

Should be fixed in 3.0

Unfortunately this patch did not work for me anymore, so I fixed it slightly differently under #3497645

Let me know if the problem still exists in some situation in 3.x

I do not think that removing behavior is a good idea. While it is unlikely that one would use this on two tables on the same page, but normally this is bad practice to remove.

It is better to use the once library.

I also had to tweak the css to make it work.

This seems to have similar functionality to ✨ Collapse all/ Expand all functionality RTBC

nagy.balint → created an issue.

Thanks!

Hmm,
The add-retention-policy-to-logs-3547908-5.patch in #5 already had a cron which was simpler, you have not found it good enough?

Hi!

Definitely I had the goal to eventually not depend on jQuery, which would also remove around 100kb from the project.

I have removed many of the dependent modules, but it seems we have a lot of them.

At least now it seems that maybe cookie consent is not dependent anymore since we use Klaro.

I am not sure yet if I would like to switch away from BEF, but I am not completely against the idea.
Of course this is just a starting kit, so you can switch to using Trufil in your own projects in the meantime.

By the way I have noticed that in your second screenshot for the module, the "BEF" string is still in the text.

Hello!
I am still interested!

nagy.balint → created an issue.

Unfortunately this likely only works on drupal 10 since the service does not exist in the Drupal 11 version of the core patch :(

Reroll.

True,
but the media UI is quite complex for my needs, which is a simple icon selector, without uploading or any complexity.

Maybe I will create a simple picker widget in the future.
For now I added the default value from config import.

I am sad to hear that the Picker is going away.

Unfortunately for me the autocomplete is not the best, because my plan was to use this not with a big database of icons, but my own defined icons for a content type, and so if the User always have to type and search for names instead of simply getting the icons to choose from, then it is an UX issue.

It would be really cool if We could disable this automatic translation download on module install more easily.

It can cause issues in deploy scripts, and also with config where after running config import it suddenly produces a lot of new diffs when installing a module.

17 days passed, I am still interested.

nagy.balint → created an issue. See original summary → .

Hi!

Thank you!

Can you reroll the patch for the 4.x branch? as that is the main supported branch?

Also in the cron we might need to do the same
$row_limit = \Drupal::config('config_log.settings')->get('logs_to_keep');
to add ?: 0

even though NULL > 0 i think is false, would be better.

interdiff

@drupov
Hi!
Thanks for the merge request.

I needed to be able to select the allowed text formats, and also the schema was missing the new settings.

I made a patch file for now for review, but if it is good then we can add it to the merge request of course.

Thanks!

If I understand correctly, this will fix new routes, but already created routes remain broken, and so an update hook would be required?

On one of our sites where content entity builder was used to create a base field on an entity, we got the undefined index as in the title.

The patch #4 fixes the issue.

I sent a message via the contact form to @ajay_reddy at 27th of September 2025

nagy.balint → created an issue.

Then would simply installing this module work as well?
https://www.drupal.org/project/jquery_deprecated_functions →

Thanks!

Thank you for the patch!

I have the following feedback:

1. We use ConfigLogDatabaseSubscriber::$type to define "custom" so the line
+ ':input[name="log_destination[custom]"]' => ['checked' => TRUE],
should also use that.

And likely below in the getValue as well.

2. $config_log_conf->get('logs_to_keep') might be problematic if a site updates to this version and the config does not exist. It would be better to add a fallback value to that.

3. config_log.schema.yml and config_log.settings.yml is missing the new config item.

4. If logs_to_keep is int type, then it might be better to store a 0 in the else instead of $config->set('logs_to_keep', '');

Hi!

I cannot decide on this matter personally, as I am not the original owner of the project, but I committed your two merge requests.

Thanks!

Seems like phpcs is still failing.

Can't we improve the library instead?
https://github.com/noli42/chosen

Thanks!

Thanks!

Thanks!

Same here, issue fixed by patch #14

Based on my testing MR50 #6 fixes my issue. Seems to have no side effect in my case.

I have the same issue now.

I believe this commit broke the module, since
Fatal error: Uncaught Error: Class "Drupal\languagefield\Plugin\Field\FieldType\TranslatableMarkup" not found in languagefield/src/Plugin/Field/FieldType/LanguageItem.php:38

as the commit introduced

  label: new TranslatableMarkup("Language"),
  description: new TranslatableMarkup("An entity field to store a custom language."),

but TranslatableMarkup is not in the "use" section.

Branch is incorrectly named, will fix soon.

Hi!

14 days passed, and I am still interested!

Hi!

If you can fix phpunit in a separate issue that would be awesome!

I can commit it quickly and then we can return to this.

This merge request is somehow incorrect, but the issue has been fixed in the Drupal 11 compatibility issue.

Thanks!

Thank you!

Hello!

14 days passed, and I am still interested.

I think that 4.x will only get small improvements and security/critical fixes but if it is a small change which has likely no negative effects then we can commit it.

If setTimeout is the simplest and more robust solution then we can go with that.

Likely easy to do since we already have chosen.claro defined, and just need to extend it with the gin specific ones.

So based on 🐛 Add Better Exposed Filters support Fixed
data-bef-auto-submit-exclude attribute was added, which was also in 4.x so by earlier version perhaps you meant 3.x

the issue that was solved by this is

As a consecuence, after updating to Better Exposed Filters to 6.0.4 or newer, and using Chosen on a select filter, makes the input search unusable because it auto-submits the form right after the user type just a character.

So then the solution here is to revert that change, but to solve the original issue in a better way.

As far as I saw core is also moving away from jQuery, so I think we will need a solution without jQuery.

Hi!

This issue description is incorrect since 5.x uses no jQuery.

More than a month passed without reply.

Moving to the project ownership queue.

Thanks!

We will need to fix the tests to make a new release though.

Thanks!

I guess it is best to commit this here.

Thanks!

Hello!

14 day passed.

I am still interested.

Thanks!

Thanks!

Moved it to Drupal.org project ownership as 1 month has passed already.

Not yet unfortunately.

I will move it to the project ownership queue.

Since the common practice is to create a new branch when we drop compatibility for major versions of Drupal,
I am pretty sure that defining core version as >=10 is not a good idea,
as we also know that this module will become incompatible with either Drupal 12 or Drupal 13, when the hook system is deprecated for example.

So it is better to define the compatibility the normal way
core_version_requirement: ^10 || ^11

Message sent via contact form to @adcillc at 20th of July 2025.

nagy.balint → created an issue.

2 weeks passed without reply.