🇭🇺Hungary @nagy.balint

Seems to work.

Thanks!

It seems to work.

Not sure if it is only due the upgrade,
but for me the site settings content list (admin/content/site-settings) did not list the Type only the Group and listed all translations, which looked a bit weird.
But since it is a view I was able to easily modify it.
I got Deprecated function: mb_strtolower() when saving the views, but as far as I see that could be a Core issue and not related to the module.

Of course I fully understand.

I have not tested yet the transition to the 2.x version, but if it is ready for production use, then it could be retagged to rc1 or similar, as currently it is still tagged as an alpha, and it seemed to me that maybe it is too early to switch.

While 1.x really just required a new tag, which is why I requested.

But then I will run some tests on the 2.x branch soon to see.

nagy.balint → created an issue.

Let me know if this works better.

I improved the kernel tests, and fixed the issue at the storage.

However this seems to only be an issue when the field is a date field, and works fine when date and time is selected.

So likely what we need to do in the code is to detect when it is a date only field, and ignore any time related parts.

I see what is wrong.

The default Date Format is Y-m-d H:i, but when the site's timezone is not set to UTC, then that format can cause issues when saving the date, and so it saves an earlier time.

However Y-m-d works fine, which is a good workaround in that case.

Then indeed there is an issue here.

I think it is just that the default Date format should only be changed in rare circumstances because it is linked to data storage.
For most users only the alternative input is needed.

Maybe what we could do is to hide the Date Format option by default.

I put it on needs review, since the dev release in the current state is not really useable...

The commit in #4 also broke ajax in the views admin, since TRUE and FALSE are not valid in javascript.

Seems to be several issues with this commit :(

Not the exact same code part, but this is related I think 🐛 Previous commit broke views_handler_area_result Needs review

At least in my setup I cannot reproduce the issue on 10.3.1.
Layout paragraphs: 2.0.6

Thanks!

The issue is around this code part:

  /**
   * {@inheritdoc}
   */
  public static function generateSampleValue(FieldDefinitionInterface $field_definition) {
    $values['conditions'] = new ConditionFieldData($field_definition);
    return $values;
  }

Because commenting it out makes it work.

Hi!

Can you provide a bit more information on how to reproduce the issue?

I tried it on my test drupal 11 beta as I had layout builder set up there, and I could not see the issue.

Maybe it works on nodes, but not on other entity types?

I have 3 translatable field, and 1 term reference which is not translatable on the media entity.
Maybe it has something to do with the not translatable field in that case.

The error message is similar to the related issue: 💬 How to translate an entity programmatically Closed: outdated

What I got is

Drupal\Core\Entity\EntityStorageException: Invalid translation language (und) specified. in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 818 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

#0 core/modules/media/src/MediaStorage.php(29): Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object(Drupal\media\Entity\Media))
#1 core/lib/Drupal/Core/Entity/EntityBase.php(354): Drupal\media\MediaStorage->save(Object(Drupal\media\Entity\Media))
#2 modules/contrib/media_library_edit/media_library_edit.module(204): Drupal\Core\Entity\EntityBase->save()

I got the same issue in a custom migration recently where I added translations to Media.

I had no time to dig very deep unfortunately. But when I search for addTranslation in core, I see examples for both usage.

But saving the media entity this way worked in my migration and also in this patch.

So the change is at

$media_original->addTranslation($current_langcode, $media->toArray());
$media = $media_original;

So this new patch is almost the same as MR16, but instead of making $media to be the return value of addTranslation, It receives the original media entity with the added translation, which works better for me.

MR16 did not work for me cause it kept throwing Invalid translation language (und) specified.

I made a simpler patch, as actually when adding translation we normally don't need to save the return value of the addTranslation method, but we can simply save the entity.

And this works for me at least.

MR17 was based on 3.0.2, and the merge with 3.0.x did not work out apparently.

I had the same issue.

Thanks for the patch, it works for me to remove the error.

Thank you!

I think that we could just add an !empty check, since even the $component could be empy in the current code.

I guess one way to fix it is to revert that part of the commit.

nagy.balint → created an issue.

@DamienMcKenna

Hi!

There is an issue with the previous commit, as there is an extra comma which causes:
ParseError: syntax error, unexpected ')', expecting variable (T_VARIABLE) in drupal_load() (line 2620 of views.module)

Attached patch.

As I cannot reproduce the issue when the alternative input format is used.
So with settings:
Alternative input format: F j, Y H:i K
Date format: Y-m-d H:i

I will have to set the issue to postponed.

Feel free to reopen the issue if someone can reproduce the issue with the recommended settings.

Thanks!

This will be in the 3.0.x branch.

Hi!

Thanks!

I cannot reproduce this issue anymore, so likely It was fixed in another issue.

Thanks!

Thank you!

Thanks!

Thanks!

greggles → credited nagy.balint → .

I think a
$option_title = $element_title;

is missing before the
if (in_array($element['#type'], ['checkboxes', 'radios'])) {

Thank you!

Thanks!

However I am not sure if the following condition is 100% correct
if (!empty($element['value']['#access']) && $element['value']['#access'] && !empty($element['value']['#value']) && !empty($element['end_value']['#value'])) {

Are we certain that $element['value']['#access'] exists in the array?
Because if it does not exist, then it should be considered as TRUE.
While in the above condition when it does not exist, it will skip the condition.

I think It could be better to first determine the access with something like
$access = isset($element['value']['#access']) ? $element['value']['#access'] : TRUE;
and then it can be checked later in the condition.

Thanks!

It worked fine for me.

I think this would be a very good addition to the module.

#8 seems to be working here too.

Thanks!

Thanks!

Hi!

As far as I see, for sites that already have this module installed, this setting will only be created if they save the config form.
The "$log_ignored_config_negate = $this->configFactory->get('config_log.settings')->get('log_ignored_config_negate');" line does not check if the setting exists or not.

Thank you!

Hi!

I cannot reproduce the issue on Drupal 10 in simplytest.me.

Can you try on a fresh Drupal install?

Thanks!

It fixed the issue.

Sidenote:
The module really needs a skip language script validation option, as currently I just had to enable all the checkboxes on that form :(

nagy.balint → created an issue.

The patch works fine, thanks!

I created 🐛 TypeError in admin/content/site-settings Fixed for that purpose.

nagy.balint → created an issue.

Yes currently 1.x is broken due to the commit here since "use Drupal\Core\Session\AccountInterface;" was removed.
This caused admin/content/site-settings to throw a TypeError

It might be easier to just open a new issue, and push this 1 line commit, unless the 1.x branch is discontinued soon.

This patch is likely outdated now.

Hi!

Yes, unfortunately I cannot reproduce it either.

Could be something related to server configuration, or collision with another module.

Thanks!

Thanks!

Hi!

It seems the issue is even bigger since 10.2 because the ListItemBase.php is changed now and it has code parts like
core/modules/options/src/Plugin/Field/FieldType/ListItemBase.php

    if (!$form_state->get('items_count')) {
      $form_state->set('items_count', max(count($allowed_values), 0));
    }

must be of type Countable|array, null given in count()
or

$current_keys = array_keys($allowed_values);

must be of type array, null given in array_keys()

Because it is possible to empty the allowed values by manually editing and importing config, but since 10.2 the system fails when the $allowed_values is empty.

Works for me as well on Drupal 10.2.2 and tablefield 2.4, php 8.2

Hi!

Are you using the JJJ fork of chosen?

I see this commit https://github.com/JJJ/chosen/pull/15 but then I guess that was not enough to fix the issue?

I think, this is a very important project, and eventually we will have issues if it is left without maintenance.

As the last reply is 7 months ago, I am not sure if we shouldnt try the procedure outlined at the following link:
How to become project owner, maintainer, or co-maintainer →

@Anybody, what do you think?

(based on the issue queue I set higher priority)

Are you absolutely sure that you are using the latest 2.0.9 version and cleared the drupal cache?

Can you try the latest version? There was an issue with saving the widget.

I reopen this, as I found an issue when saving the widget settings with empty day select.

Hi!

Try to keep the date format at the default.

To change the date format displayed to the user, the Aleternative Format should be used. (See image)

I think it is better to keep them separate.

This option could be implemented similarly to "Ignore logging on config import" checkbox.

So we could have a checkbox in the settings like "Omit logs with no modifications", and then the filter method could be in the base class, and each subscriber could call it to filter the logs.

As this is only needed for 2 subscribers out of the 3, for now I just added it to the other one, and also fixed the code style.

Reroll for Drupal 10 compatibility.

So then, this can be closed as the issue is with the other patch that needs a reroll.

Fixed a deprecation warning on php 8.1.

Hi!

It is good, but similarly to 🐛 Fix "Ignore logging on config import" feature Needs work , we should always consider that there are other subscribers, and this could be a more global change.
For example sending a mail about a no change could be useless as well.

Thanks!

Hi!

There are some sites that use the 3.x branch and would like to move to Drupal 10.
As 4.x is a rewrite it seems, I attach a patch for the 3.x branch for compatibility.

If the maintainers would like to make it easier for sites that run 3.x to keep using their existing module in Drupal 10, then it can be committed to the 3.x branch.

Hi!

1. Normally if I search for a date I would search for a specific date like "2023-10-12" or in between.
in between works, though we need to put 2023-10-11 and 2023-10-13 to search for entries 2023-10-12.
but equal to does not work for me. So currently I cant list the items with date of 2023-10-12 unless I use the in between above.

2. The config_log_views module should depend on config_log, so when config_log is uninstalled we also uninstall the submodule.

(And a followup issue could be that normally we should not log config changes that are "no change", for example i got like 5 lines with no change on language.types. But that is unrelated to this issue.)

I think it is fine, as this is an administrative view anyways.

Collapsible is also good.

Could we add some basic date filter? So the entries on a specific day can be found more easily.

Very nice!

I am afraid however, that this will require a bit more work.

1. We will need a fallback for old entries where the original data does not exist, otherwise we get
Deprecated function: explode(): Passing null to parameter #2 ($string) of type string is deprecated in Drupal\config_log_views\Plugin\views\field\ConfigLogDiff->render() (line 69 of modules/contrib/config_log/modules/config_log_views/src/Plugin/views/field/ConfigLogDiff.php).

2. If the diff is big, then the display becomes problematic, especially as the other columns put the text in the vertical center, so the user basically cant even see what the diff is about. I guess that is why when the admin/config/development/configuration page displays diffs, it is always done in modals, and not directly on the page.
Or if we can do it selectively and only put the big diffs into a modal would be even better.
Not sure what we can do to improve the situation without causing a lot of extra work, but we will need to do some improvement, as it is likely to have some big diffs I think.

Thanks!

Unfortunately this does not seem to work

>  [notice] Update started: config_log_views_update_8001
>  [error]  You have requested a non-existent service "config_update.config_update".
>  [error]  Update failed: config_log_views_update_8001