Improved views for config_log_views

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

You have a point, I assumed that everyone was having the config_update module installed, which is not the case.

I've reworked the upgrade hook to use core functions instead.

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.

Excellent points!

Here are my thoughts:

1. That's my fault, I didn't see the warning/deprecation warnings on the page as i had them mute. For that issue, I would cover it by altering the explode function like this:

    $newValue = ($values->config_log_data) ? explode("\n", $values->config_log_data) : [];
    $originalValue = ($values->config_log_originaldata) ? explode("\n", $values->config_log_originaldata) : [];

At the end, Drupal's Diff module wants array(s) to work with.

2. I think that's the most challenging part and here's what I would do: Since this is an array, I can get a count of its elements. If, for example, the elements are more than 7, I can instead make this field collapsible and hide the difference inside there (see the example screenshot).

That's just a thought, feel free to spam your ideas if you got any!

Collapsible is also good.

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

A basic date filter yes, besides, it's just a view that anyone can alter for his own purposes once they have the submodule installed.

What I wouldn't do is to add popup date selector as it's a separate module at the moment.

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

If that's the case, then attaching the r3 patch that covers this.

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

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.

As far as I am aware, that's the way with the built in Drupal Views on D9/10 at the moment (unless I'm completely mistaken!). Take the "Recent Logs" for example, if you add a date filter and expose it along with the operator, you get the exact same behaviour, so unless we add dependency with popup selectors/3rd party drupal modules, I can't do much about it.
However, even if annoying, my personal belief is that experienced users can still work with it.

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

That I can do, yes (I'll create a new patch tomorrow for that)

(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 agree, we can create a new issue and deal with those tasks

Hello !

Attaching a new patch (r4) for the install/uninstall process part (mostly dependency and uninstall hook) as also some minor corrections (added description to the menu item of the reports)

Cheers!

Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.