Problem/Motivation

In an effort to ensure site owners have the information they need, we can add lifecycle information to module .info.yml files https://drupal.org/i/3215042

Steps to reproduce

N/A

Proposed resolution

Add deprecated lifecycle status to the module info file.

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork config_filter-3484472

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

trackleft2 created an issue. See original summary.

trackleft2’s picture

trackleft2
Primary language English
Location Tucson, AZ 🇺🇸
commented
Issue summary: View changes

trackleft2 opened merge request !11

bircher’s picture

bircher
Location 🇨🇿
commented

I am wondering if we should have a dedicated page, maybe documentation? maybe change record?? I don't know what would be best.
Because i think it would be good to give more background information as to why this module is scheduled to go away and what to do about it.

trackleft2’s picture

trackleft2
Primary language English
Location Tucson, AZ 🇺🇸
commented

I've started a draft change record, please feel free to edit it. https://www.drupal.org/node/3487924

bircher’s picture

bircher
Location 🇨🇿
commented

Thanks! Yes a change record is a great start.
Though one of the things Config Filter is still used for in Config Split and Config Ignore is for testing. I created a trait that abstracts the difference between the config filter and core API so that one can write a Test for the module when it is using filter plugins and and then rewrite the module to use the transformation events and the same test will still pass. It was instrumental for the refactoring of the two mentioned modules.

Maybe we add the trait to core too and if it doesn't get in Drupal 11, maybe we create Config Filter 3.0.x with just the trait and none of the actual code. Does that sound like a plan?

trackleft2’s picture

trackleft2
Primary language English
Location Tucson, AZ 🇺🇸
commented

Do we need a new Drupal core issue to propose creating a new test trait for the config import export transformation api? If so where would we propose adding it? Maybe here? https://git.drupalcode.org/project/drupal/-/tree/11.x/core/modules/confi...

Are we talking about this file? https://git.drupalcode.org/project/config_filter/-/blob/8.x-1.x/tests/sr...

bircher’s picture

bircher
Location 🇨🇿
commented

I don't know if we need an issue in core, I don't remember if I created one years ago. But maybe I didn't and yes we need one? But on the other hand do we?

And yes that is the trait, though for core we would probably rather use the one from 2.x ie https://git.drupalcode.org/project/config_filter/-/blob/8.x-2.x/tests/sr... (if you compare the two versions of the trait you can see where config filter 1.x does in the trait what config filter does in the event subscriber bridging the API)

But also if Config Filter is not involved any more then maybe it could also make sense for the modules that needed it to adopt that code. The original point was to make the transition from Config Filter to the storage transformation API easier. So getting rid of the dev dependency on config filter requires some amount of code, either by changing the namespace of the trait if it goes "as is" into core, or copying the trait to the module and renaming the namespace. Maybe the difference between the SyncFileStorage and the sync storage service is negligible when config filter is not swapping it out, and the active storage doesn't need to be a readonly storage if you know what you are doing?

You can tell I haven't made up my mind :D
Thanks for helping me figure this out!