🇭🇺Hungary @nagy.balint

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

I think we need a new update hook, as otherwise sites that already run this update hook won't run this new part.

Looks nice!

Not sure if we need some basic date filter.

Hi!

I think it is a good idea to include that.

I wonder how the diff will look in that view.

4.x version updates.

Updates for the 4.x version.

Added ddev instructions for install.

Change for the 4.x version.

Update for ddev informations.

Thanks!

I think the patch is still needs work, as Database subscriber also has the import event.

Thanks!

It is good, but on a fresh install with simlytestme I still got Tag based cache for some reason

Thanks!

I just realised that this views config however won't be imported on existing installs of the module.

So we have two ways to go:
a) We can create a sub module (something like config_log_views) and then anyone can enable the new sub module to get the views integration.

b) We can create an update hook to read this config and apply it.

Maybe a) is better, as even though db table logging is the default setting, it can be configured to not log anything into the database, so in some configurations this views integration is not needed, or maybe the developer does not need it.

Thank you!

1. However the UUID should not be part of the yml file: https://www.drupal.org/docs/creating-modules/include-default-configurati... →

https://www.drupal.org/project/config_devel → could help as well.

2. The Tag based caching should be disabled on the view, cause otherwise it will not show the recent entries, or only after cache clear.