πŸ‡­πŸ‡ΊHungary @nagy.balint

Account created on 13 January 2012, over 12 years ago
#

Recent comments

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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?

πŸ‡­πŸ‡Ί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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

So the change is at

$media_original->addTranslation($current_langcode, $media->toArray());
$media = $media_original;
πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

Thank you!

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

@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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

Thanks!

This will be in the 3.0.x branch.

πŸ‡­πŸ‡ΊHungary nagy.balint

Hi!

Thanks!

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

πŸ‡­πŸ‡ΊHungary nagy.balint

I think a
$option_title = $element_title;

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

Thanks!

It worked fine for me.

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

Hi!

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

Can you try on a fresh Drupal install?

πŸ‡­πŸ‡ΊHungary nagy.balint

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 :(

πŸ‡­πŸ‡ΊHungary nagy.balint

I created πŸ› TypeError in admin/content/site-settings Fixed for that purpose.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

Hi!

Yes, unfortunately I cannot reproduce it either.

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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?

πŸ‡­πŸ‡ΊHungary nagy.balint

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)

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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)

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

Fixed a deprecation warning on php 8.1.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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.)

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

Collapsible is also good.

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

πŸ‡­πŸ‡ΊHungary nagy.balint

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
πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

Looks nice!

Not sure if we need some basic date filter.

πŸ‡­πŸ‡ΊHungary nagy.balint

Hi!

I think it is a good idea to include that.

I wonder how the diff will look in that view.

πŸ‡­πŸ‡ΊHungary nagy.balint

4.x version updates.

πŸ‡­πŸ‡ΊHungary nagy.balint

Updates for the 4.x version.

πŸ‡­πŸ‡ΊHungary nagy.balint

Added ddev instructions for install.

πŸ‡­πŸ‡ΊHungary nagy.balint

Change for the 4.x version.

πŸ‡­πŸ‡ΊHungary nagy.balint

Update for ddev informations.

πŸ‡­πŸ‡ΊHungary nagy.balint

Thanks!

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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

πŸ‡­πŸ‡ΊHungary nagy.balint

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.

Production build 0.69.0 2024