Filters order in filter.format.XXX.yml depends on the site instance history?

Created on 6 April 2017, over 7 years ago
Updated 19 September 2023, over 1 year ago

Hello there,

I apologize in advance if this is a works-as-designed or a not-core-problem bug :/ I just mean to give feedback if I discover something wrong. I'll try to be as descriptive as I can.

We found a strange behavior when we wanted to deploy our drupal 8. We had to import filter.format.our_filter.yml into the staging instance, using drush cim as usual. It kinda worked, but we found out that if we did a "drush cim" again, just after the first one, the same file was still listed as needing update.
So we made a "drush cex" and a "git diff" to see what happened. Actually the diff revealed that the format filters in the yml file where not in the same order (I'm not talking about weights, but only about order in the yml file). It was the only difference. Then I thought "maybe the order in the source file is wrong, and Drupal corrects that on export". So we committed the order change. But then, we got the same problem when trying to import this new commit back into our dev instances.

This is the time when I tried to figured out what happened by digging into core (XDebug breakpoints and so on). I found out there was a sortHelper() method in the FilterPluginCollection class, which was called on presave, that sorts the filters in a logical order based on criterias such as status and weight. It was much complex, so that I gave up with trying to find the cause of the problem, and just tried to reproduce on a clean Drupal.

Apparently, the filters are stored in the yml file in the order they were added. So that I found out a quite simple way to get the problem:
* install a fresh Drupal with two contrib filter modules enabled (I took video_filter and linkit, it might be reproduced with core filters though)
* export config and commit to master
* enable one of the filters in a format (linkit for example)
* export config and commit to a new branch (A)
* checkout master, import back the previous config
* at this stage, none of the filters are enabled into the format: enable the other (video_filter for example)
* export config and commit to a new branch (B)
* merge A into B, resolve the conflict and import: you get the two filters enabled when looking at the format
* checkout A and import: you get only one filter enabled (linkit in my example)

And this is where the problem arises. If you try to import again, you'll always see your format as needing update. An export and a git diff will show you that the order of the filters is not the same.

I would have expected that either:
- the first import would change the filters order in the DB, so that there's nothing to import at the second call,
- the filters order would be ignored, so that nothing needs update at the second call,
- the filters order in the yml file would follow some precise criteria (the ones from the sortHelper method), so that one order is the right one that is used on every export.

This is problematic because if you get to a point where the filters order is different in two instances of the same site (it can easily be two dev instances, when working as a team), you have no easy way to get a fix version of the yml file. Each time a site builder exports his config (to commit something unrelated), it erases the config of the other site builder, just to change the order in the yml file (which I guess has no impact on the site behavior).

I hope I've clear enough. Maybe there's a reason why there is no right order for the filters in the yml file?

NB: I suspect that we got to this problem after executing linkit module's hook_updates, which acts on the filter formats config.
NB: I found one issue queue that might be related: #1868772: Convert filters to plugins β†’

πŸ› Bug report
Status

Closed: duplicate

Version

8.3 ⚰️

Component
Configuration entityΒ  β†’

Last updated 3 days ago

Created by

πŸ‡«πŸ‡·France GaΓ«lG Lille, France

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024