Missing Config Filter plugin when upgrading to 2.0.0

A team member is experiencing this issue related to 📌 Clear Config Filter plugin cache to update from 2.x to 3.x Fixed , and I wanted to create an issue for SEO and search engines.

We're encountering this when deploying updates using drush deploy. See 📌 Clear Config Filter plugin cache to update from 2.x to 3.x Fixed for work around and other related issues.

hi @jasonawant,

It looks like post clearing the Drupal's cache this issue should be resolved.

Thanks
Samit K.

Yes, agreed that does provide a work around, thx!

Sure, we can add a config filter plugin cache clear to the update hook as we did for config ignore. But bugs in a major version upgrade that go away when you clear caches seem very minor to me. If it prevented you from clearing caches then that would be another story, but I have not experienced this problem once so I am sure that there is a way to make the upgrade work with just the standard workflow and drush deploy.

I've also faced it on multiple projects. In one case different website environments would react differently - one would run through deployment process without issue, another died immediately on the the attempt to put website into maintenance mode with drush state:set system.maintenance_mode 1... However not sure sure if that was maintenance mode as the only output in the log was

In DefaultFactory.php line 97:
                                                                               
  Plugin (config_split:uat) instance class "Drupal\config_split\Plugin\Config  
  Filter\SplitFilter" does not exist.                                          

To me this doesn't look like minor, if the standard automated update process fails. At the same time I would expect that changed $settings['deployment_identifier'] would tell container to ignore the cache and rebuild it self, effectively forgetting about Drupal\config_split\Plugin\ConfigFilter\SplitFilter. Not happening unfortunately.

Speaking about core, I faced this when was deploying Drupal core 10.2.6 update. Maybe that is related?

We are experiencing the same issue. We are updating to Drupal core 10.2 and at the same time updating from Config split 1.x to 2.x. We have two sites where the update seemed to go fine initially but config sync and drush deploy seem to fail with this same error. Drush deploy faisl for us but also switching branches between 1.x and 2.x version of the module and trying to sync configuratin seems to also produce the same error in local development environment.

I think this is a critical issue because it breaks the whole deployment flow.

I was partly able to solve the problem by installing Config filter as a dependency with Composer to the project but it doesn't seem like a proper fix because the automated update process should handle this without needing to do an extra step.

I don't know how to reproduce this issue.

Bear in mind the following which is written on the module page of config split and the release notes of 2.0.0:

Attention: 1.x depended on Config Filter, but 2.x uses the core API. If you have not explicitly required Config Filter before Composer will remove it when updating. But then you are left with a drupal module still being installed but no longer available in the code base.
In order to properly uninstall Config Filter you should explicitly require it and then uninstall it, and remove it from composer.json only in a later deployment.

If you upgrade, you MUST explicitly require config filter, so that you can properly uninstall it.

Missing config filter is not the problem in my case - I have it required just to be properly uninstalled in production with a follow up removal from the code base.

In my case, I have a couple of sites with complex content that makes heavy use of the caching API (cache tags and cache contexts) and we try to avoid clearing the cache unless absolutely necessary. We even have a custom drush.yml with this:

command:

  updatedb:
    options:
      # Don't clear the cache by default to avoid unnecessary work.
      #
      # @see https://www.bounteous.com/insights/2020/03/12/automated-drupal-deployment-and-rollback-recipes/#don%E2%80%99t-clear-all-caches-instead-selectively-clear-what-you-need
      cache-clear: 0

Which I suspect may be part of the reason we also got hit with this Drupal\config_split\Plugin\ConfigFilter\SplitFilter error, despite following the 2.0.0 instructions and had drupal/config_filter required explicitly. Thankfully, this happened on a staging site so I could just restore a database back up and try a few things. What ended up working in our case to avoid a full cache clear was:

1. Upgrade Config Split in a dev environment; update database; export config; commit/push.
2. On the target site (staging/production) do drush pm:uninstall config_split
3. Deploy the updated codebase and config files.
4. drush -y updb and then drush -y config:import (our deployment process does this automatically)
5. Config Split 2.x is now installed and using the 2.x config without a problem.

Whoops, it looks like I accidentally replaced the issue summary with my comment. One of the maintainers should revert that if possible. 😬

I don't think you have to be a maintainer to update the issue summary.

I used this diff to revert the changes
https://www.drupal.org/node/3440013/revisions/view/13598088/13729680 →

I actually had this exact same problem but when upgrading the Config Ignore module instead. It was complaining about a missing Config Ignore filter. Like in #6, our deploys were failing at the first hurdle when maintenance mode was being enabled.

I fixed my deploy in a quick and dirty way by creating a patch file that re-added the old file so composer would add the file back in and the Drupal would be appeased. I'll then remove it in a subsequent release.

That said, I think the problem is something to do with the classes being cached and then attempted to be included before the cache has been rebuilt. My feeling is that the 'proper' solution is modify deploy processes to truncate `cache_discovery` prior to running any drush commands in the deploy, including enabling maintenance mode. Or perhaps investigating the ` cache_utility → ` module as that looks like it might flush everything a bit more thoroughly during a cache rebuild as it includes all cache tables as well as APCu and OPcache.

I'm not sure it's a bug with this module but it might be worth noting that this might happen in the project page section about upgrading for both this module and Config Ignore. The problem with the linked Config Ignore issue is that it is clearing `config_filter_plugins` from `cache_discovery` during an update hook which is happening too late in the deploy process for some people.