[10.3] Update ConditionManager to support PHP Attributes

That's due to core switching to use PHP attributes for plugin discovery in 10.3.

Rules extends the core ConditionManager, and the Rules version apparently needs to be updated to support the new PHP attribute plugin discovery as well as the <10.2 plugin discover mechanism (needs to support both for backwards compatibility).

See https://www.drupal.org/node/3229001 →

Patches welcome ...

Following here, and renaming the issue so others can more easily find it (related issue was closed as a duplicate).

I have the same issue after update from 10.2.7 to 10.3.0

I have the same issue after update from 10.2.7 to 10.3.0

I have the issue with Drupal\Component\Plugin\Exception\PluginNotFoundException: The "user_role" plugin does not exist.
Updated from 10.2.7 to 10.3.0

I try to find a solution to recover my site.
Until a patch will published I have to make my site running again.

I have no access to my admin interface. So I try to make some changed in db to disable visibility condition for some blocks per user role.
Could someone help me where I can find configuration per block in db?

Thanks

I try and find the configuration for blocks that have visibility per role setup. Check one sample.

a:12:{s:4:"uuid";s:36:"9e85a5c2-2040-4289-ab3d-41cb9980fb8a";s:8:"langcode";s:2:"el";s:6:"status";b:1;s:12:"dependencies";a:3:{s:7:"content";a:1:{i:0;s:56:"block_content:basic:efcc1f8f-5087-4038-ad15-b857a0bba42c";}s:6:"module";a:2:{i:0;s:13:"block_content";i:1;s:4:"user";}s:5:"theme";a:1:{i:0;s:14:"viosarp_barrio";}}s:2:"id";s:10:"bannerespa";s:5:"theme";s:14:"viosarp_barrio";s:6:"region";s:9:"slideshow";s:6:"weight";i:-22;s:8:"provider";N;s:6:"plugin";s:50:"block_content:efcc1f8f-5087-4038-ad15-b857a0bba42c";s:8:"settings";a:7:{s:2:"id";s:50:"block_content:efcc1f8f-5087-4038-ad15-b857a0bba42c";s:5:"label";s:15:"Banner ΕΣΠΑ";s:13:"label_display";s:1:"0";s:8:"provider";s:13:"block_content";s:6:"status";b:1;s:4:"info";s:0:"";s:9:"view_mode";s:4:"full";}s:10:"visibility";a:1:{s:9:"user_role";a:4:{s:2:"id";s:9:"user_role";s:6:"negate";b:0;s:15:"context_mapping";a:1:{s:4:"user";s:39:"@user.current_user_context:current_user";}s:5:"roles";a:1:{s:9:"anonymous";s:9:"anonymous";}}}}

But I cannot edit blob column in phpmyadmin to clear visibility as this
s:10:"visibility";a:0:{}

Is someone else that find solution. It is crazy that all my sites are down after update to 10.3.0

@TR

Until the necessary changes for 10.3 are added, it may make sense to update the Composer versioning for Rules - which presumably would prevent people from inadvertently updating to 10.3 and breaking their sites.

I believe something like this would do it.

^9.1 || 10.0 - 10.2

So until new version we will have all our websites down? Any help to find a solution on this?

After upgrading to 10.3 Block visibility changes with Rules installed.

Rule uninstalled:

Rules installed:

Note that Page, Response status, Roles, Content type and Roles disappear. I understand that Rules adds new Block visibility options but it shouldn't be removing core options.

I try to recover my site back from a backup.
For home directory I think I can find some previous version. But for db the changes from 10.2.7 to 10.3.0 must be back to 10.2.7 version or not? What tables change 10.3.0? Is this problem to work with 10.2.7 as I have a backup from 10.2.7 db nut there are a lot of new entries in my ecommerce website.

Yes I think this is important for rules
^9.1 || 10.0 - 10.2

uninstalling the rules modules got my site back.

How did you uninstall the rules module? Can I do this for the user roles on my site as that is the indicated missing plugin?

What I did was delete the database with the 10.3 data and restored it with the 2.7 backup. I could then access the site and uninstall Rules. Then I ran updates again and was up and running again.

You can also remove any Blocks that have visibility settings or remove the visibility settings for all Blocks.

As a quick way to recover, renaming rules/src/RulesServiceProvider.php should stop the error on the site. May have to do the usual clear your caches and rebuild the service container with drush. Be aware that this will break Rules and may cause other errors on your site if you have Rules enabled and active Rules in use.

Drupal locates service providers by the naming pattern, so renaming this file to literally any other name will prevent Drupal from finding it. This service provider is how the core Drupal ConditionManager gets replaced by the Rules version, and renaming it will cause Drupal to use the default core ConditionManager.

It's troubling that Drupal introduced a major BC breaking change between minor point releases of core. 10.3 is not backwards compatible with code that works under 10.2. The fix, from my point of view, is a new branch that supports 10.3 and up. All the plugins in Rules and its dependency TypedData need* to be rewritten for PHP attributes. All the plugins in modules that support and extend Rules need to be rewritten for 10.3. And that's a LOT of plugins. About 100 in Rules/TypedData alone. The only way IMO to manage this BC break is to have separate branches for 10.2 and 10.3.

*"need" is a strong word, but to do the same thing as core in an attempt (and fail) to support both the old and the new plugin discovery schemes is clearly not going to work. The way to avoid similar failures in the future is to provide a clean break by having different branches support the different schemes.