request_path pluign does not exist error in Drupal 10.3

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.

I need to update another site but how can I prevent to upgrade to 10.3 and stay at 10.2.x?

Add a conflict on drupal/core >10.2.

Anyone: 📌 Update 10.3 release notes to indicate Rules module is not compatible Active exists, but if Core has a backward-compatibility break in a feature release, there needs to be a bug issue in the Core queue indicating exactly the problem.

Can you use DeprecationHelper::backwardsCompatibleCall in the getDiscovery method and do it the new way for 10.3+ and the old way for 10.1 and 10.2? See https://mglaman.dev/blog/writing-backward-compatible-deprecation-fixes-c...

You'd need to bump the minimum version to 10.1, which is the minimum supported version now anyway.

Same problem as described, for me it was "user_role" like described #7 above. My solution was to export all my "reaction rules" and save each locally; then uninstalled rules and Drupal core 10.3 updated perfectly. while not a perfect fix, it keeps my site open. I wish I could help develop a solution, but I don't have that skill set. Coforting to see that I am not the only person with this problem.

"Same problem as described, for me it was "user_role" like described in #7 above. My solution was to export all my "reaction rules" and save each locally"

For those of you who want to do that, type drush help rules:export where it shows you how to exports all rules and save them individually with just one easy command.

Can you use DeprecationHelper::backwardsCompatibleCall in the getDiscovery method and do it the new way for 10.3+ and the old way for 10.1 and 10.2? See https://mglaman.dev/blog/writing-backward-compatible-deprecation-fixes-c...

You'd need to bump the minimum version to 10.1, which is the minimum supported version now anyway.

The fix is perfectly do-able. But it does involve extending the core Attributes classes to support Rules extensions for the Condition plugins.

With DrupalCI, we had forward-looking tests which would have revealed this problem as soon as core made the change. But DrupalCI is being turned off and won't test higher than D10.2. And GitLabCI by default runs only against the current core version, so the D10.3 errors didn't start showing up until 10.3 became the current version a few days ago.

Now that I know about the problem, it's not too hard to fix, but it will take more than a day.

Changing dependencies in composer.json and/or rules.info.yml won't prevent this - it's occurring because existing sites are upgrading Drupal core, and they're not picking up a new version of Rules when that happens. New dependencies would only help people trying to install Rules on 10.3.

It's apparent that I have to make a new branch anyway, what with dropping D9 support and with the 10.2/10.3 break (which affects typed_data as well, which Rules depends on).

Linking related issue.

Sorry but I'm confused hoe to prevent my 10.2.7 to update to 10.3 on some websites that I have to update the rest modules etc.
I have to change my composer.json

from
"drupal/core": "^10",
"drupal/core-composer-scaffold": "^10",
"drupal/core-project-message": "^10",

to
"drupal/core": "^10.2",
"drupal/core-composer-scaffold": "^10.2",
"drupal/core-project-message": "^10.2",

I need some help to not crash my next website too.

Use Composer’s “conflict” configuration. This is what it is for.

So I need to add conflict on views module for drupal/core >10.2.
Sorry just im not specialist.
If someone could help on this, please welcome. As I think it will be useful for other people too.

I had in my composer.json this

"conflict": {
"drupal/drupal": "*"
},

so if I change it to below, I'm ok to prevent updating to 10.3?

"conflict": {
"drupal/drupal": "*",
"drupal/core": ">10.2"
},

That may be correct. I think Composer has a —dry-run mode to see what it would do.

Why we have rules, if we have ECA? Isnt it overlapping, modules doing same thing?

Rules has a more intuitive interface, and I prefer it over ECA. Not to mention with Rules you can easily get an overview of the entire workflow on a single page without having to dive deep into individual actions or triggers to see details. I suppose ECA could be useful for mapping more complex workflows with multiple, conditions, paths, and actions, but for most things Rules works better.

I agree @Anaconda777. There's a big overlap, and migrating from Rules → to ECA → makes sense. Even if the user interface is complex, it's very powerful.

ECA is growing fast now, and could surpass 10,000 installations later this year. It just got included in Starshot Project: Starshot should include ECA, to allow custom business logic to be implemented in the admin UI #99.

See also 📌 Link to ECA module at the top of Rules project page Closed: won't fix .

Good for ECA. Its interface is overly complex, and has a steep learning curve with multiple sub modules required for adding even simple single-step actions.

BTW, it's already listed as an alternative module on the main Rules page, and this really has nothing to do with the issue being discussed here.

@Anaconda777
@ressa

This issue, and this issue queue, is not about ECA.

Please don't hijack issues for your own agenda.

@tarasiadis

You probably want the 10.2.2 security update

"conflict": {
"drupal/drupal": "*",
"drupal/core": ">10.2.2"
},

Need a new branch to support the D10.3 changes. The 8.x-3.x branch will be marked as conflicting with D10.3.

In case it helps anyone else, the attached patch got me out of this hole while things get sorted. Basically it just puts the annotations back into the core request_path plugin, allowing the attributes to carry on working whilst Rules can do its thing.

Sorry @TR, I got carried away. I do think there should be a discussion about ECA, but in the other issue.

In case it helps anyone else, the attached patch got me out of this hole while things get sorted. Basically it just puts the annotations back into the core request_path plugin, allowing the attributes to carry on working whilst Rules can do its thing.

Yes, that should work if it's just request_path that's not being found on your site.

That's what core should have done in the first place - left all those annotations in place. They are just code comments after all so they don't hurt anything. And they would have ensured that the core plugins in 10.3 remained compatible with code written for 10.2.

By removing the annotations and replacing them with attributes, core is forcing contribute to switch to attributes immediately when going from 10.2 to 10.3, in a minor-point transition.

#38 patch didn't help me, site was still down. I had to add the lines to Composer conflict, and rolled back to Drupal 10.2.7.

What I did:

"conflict": {
        "drupal/drupal": "*",
        "drupal/core-composer-scaffold": ">10.2.7",
        "drupal/core-project-message": ">10.2.7",
        "drupal/core-recommended": ">10.2.7"
    },

Refactored #38 for 10.3.0.

Patch #42 didn't work for me on the 4.0.x-dev branch

Applied #42 patch, then another error surfaced

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "user_role" plugin does not exist. Valid plugin IDs for Drupal\rules\Core\ConditionManager are: response_code, rules_text_comparison, rules_node_is_promoted, rules_path_alias_exists, rules_user_is_blocked, rules_user_has_role, rules_node_is_published, rules_list_count_is, rules_list_contains, rules_node_is_of_type, rules_ip_is_banned, rules_entity_field_access, rules_data_is_empty, rules_entity_is_of_type, rules_node_is_sticky, rules_entity_has_field, rules_path_has_alias, rules_data_comparison, rules_entity_is_new, rules_entity_is_of_bundle, scheduler_publishing_is_enabled:taxonomy_term, scheduler_publishing_is_enabled:media, scheduler_entity_is_scheduled_for_unpublishing:taxonomy_term, scheduler_entity_is_scheduled_for_unpublishing:media, scheduler_entity_is_scheduled_for_publishing:taxonomy_term, scheduler_entity_is_scheduled_for_publishing:media, scheduler_condition_node_scheduled_for_unpublishing, scheduler_condition_node_scheduled_for_publishing, scheduler_condition_unpublishing_is_enabled, scheduler_condition_publishing_is_enabled, scheduler_unpublishing_is_enabled:taxonomy_term, scheduler_unpublishing_is_enabled:media, request_path in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).
Drupal\Core\Plugin\DefaultPluginManager->getDefinition('user_role') (Line: 16)
Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('user_role', Array) (Line: 67)
Drupal\Core\Condition\ConditionManager->createInstance('user_role', Array) (Line: 21)
Drupal\rules\Core\ConditionManager->createInstance('user_role', Array) (Line: 81)
Drupal\Core\Plugin\DefaultLazyPluginCollection->initializePlugin('user_role') (Line: 80)
Drupal\Component\Plugin\LazyPluginCollection->get('user_role') (Line: 26)
Drupal\Core\Condition\ConditionPluginCollection->get('user_role') (Line: 149)
Drupal\Component\Plugin\LazyPluginCollection->getIterator() (Line: 134)
Drupal\google_tag\TagContainerResolver->passesConditions(Object) (Line: 111)
Drupal\google_tag\TagContainerResolver->resolve() (Line: 106)
google_tag_page_attachments(Array) (Line: 311)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}(Object, 'google_tag') (Line: 396)
Drupal\Core\Extension\ModuleHandler->invokeAllWith('page_attachments', Object) (Line: 312)
Drupal\Core\Render\MainContent\HtmlRenderer->invokePageAttachmentHooks(Array) (Line: 285)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 286)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 128)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 186)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 191)
Drupal\page_cache\StackMiddleware\PageCache->fetch(Object, 1, 1) (Line: 128)
Drupal\page_cache\StackMiddleware\PageCache->lookup(Object, 1, 1) (Line: 82)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 741)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Sounds like there are more to fix

We're also getting the Drupal\Component\Plugin\Exception\PluginNotFoundException: The "user_role" plugin does not exist
variety of the bug on one of out sites. The site does use a couple of rules. Using D10.3.0

Upgrading from drupal 9 to 10 i am getting below error.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "node_type" plugin does not exist. Valid plugin IDs for Drupal\rules\Core\ConditionManager are: language, rules_data_comparison, rules_data_is_empty, rules_list_contains, rules_list_count_is, rules_entity_has_field, rules_entity_is_new, rules_entity_is_of_bundle, rules_entity_is_of_type, rules_ip_is_banned, rules_node_is_of_type, rules_node_is_promoted, rules_node_is_published, rules_node_is_sticky, rules_path_alias_exists, rules_path_has_alias, rules_text_comparison, rules_entity_field_access, rules_user_has_role, rules_user_is_blocked, current_theme, request_path, user_role, webform, entity_bundle:block_content, entity_bundle:comment, entity_bundle:contact_message, entity_bundle:crop, entity_bundle:entity_subqueue, entity_bundle:file, entity_bundle:media, entity_bundle:message, entity_bundle:node, entity_bundle:redirect, entity_bundle:shortcut, entity_bundle:taxonomy_term, entity_bundle:token_custom, entity_bundle:webform_submission, entity_bundle:menu_link_content, entity_bundle:paragraph in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 of core\lib\Drupal\Component\Plugin\Discovery\DiscoveryTrait.php).

Patch #42 works with D10.3.0
Thanks a lot for the update @uberhacker

It looks like the reason the core ConditionManager service is overridden is to add additional annotation namespaces to the annotation reader:

      // Make sure to add our namespace first, so our ContextDefinition and
      // Condition annotations gets picked.
      $this->annotationReader->addNamespace('Drupal\rules\Context\Annotation');
      $this->annotationReader->addNamespace('Drupal\rules\Core\Annotation');

I'm not sure why these need to specifically go *first*. If they didn't, then the $additional_annotation_namespaces parameter could be used in the plugin manager's __construct(), and that **DOES** have BC handling.

Also, why does Rules need to put its annotation classes into silly places?

I tried the new 10.3.1 core release and this issue still exist.

Hi, the attached patch remove the getDiscovery function to use the DefaultPluginManager::getDiscovery() which compat with the 2 annotations methods

@netsliver Patch # 50 Didnt worked :(

OK sorry, I'm moving towards the eca module which seems to be much more maintained and more powerful
https://www.drupal.org/project/eca →

Same issue with "request_path" plugin after updating to D10.3.1. This is very blocking issue. We need a quick fix by the rules maintainer as downgrading to previous drupal version is not an option while this implies database looses, and moving to ECA not an option either when other modules rely on rules.

There is no "quick fix" for a breaking core change between minor point releases of core (10.2 and 10.3) that affects pretty much every aspect of Rules. Everything works in 10.2 still. And BTW all the Rules extensive tests run properly in D10.3 and D11, with no deprecation warnings shown from the 10.3 change that broke everything. Fixing this requires a new major branch release of Rules, with all the BC implications of that which I have to manage.

The situation is still as I said in #17 and #23, except that since then I have made hundreds of commits and changed thousands of lines of code in a half dozen modules, with more work still needed. Maybe this week, if all goes well.

You could always contribute to the solution in some way, if this is important to you.

I'm not sure why these need to specifically go *first*. If they didn't, then the $additional_annotation_namespaces parameter could be used in the plugin manager's __construct(), and that **DOES** have BC handling.

Also, why does Rules need to put its annotation classes into silly places?

Well, short answer is ask @fago. Long answer is that the whole Rules plug-in architecture was co-developed along with the Core plug-in architecture back in the pre-D8.0 days. And just like Core has remnants of silly things dating back to the D4.5 days, Rules still has remnants of code that was considered to be good practice when it was first written. While I have refactored large parts of Rules over the years, some of this stuff which was decided and implemented long before I became a maintainer has persisted because it works and has lots of tests to make sure it stays working.

Regardless, Rules Conditions are a fundamental part of Rules, and they have an extensive set of tests that have been running against the current and upcoming versions of Drupal core, on a weekly and per-commit basis, for something like 8 years. That's why this core change between minor point releases of core, which didn't raise any core deprecation notices or warnings, is so disruptive.

Hid patches #38 and #42 to reduce confusion. Those patches are for core, not for the Rules module. And as I said in #40, that will only help if user_roles is the only core Condition you are using. In principle, adding annotations back to *all* the core Conditions (or simply leaving them there in the 10.2 to 10.3 transition) will avoid this problem. But it's not a long-term solution.

Thanks a lot @TR for so many years contributing. Sure you all find the solution :)

The one test failure is intentional at this point - CoreUserRoleConditionTest was added to demonstrate the failure described above, namely that the Rules ConditionManager doesn't find core Conditions in D10.3 because the core Conditions dropped their annotations between D10.2. and D10.3. When the Rules ConditionManager fixes are added to the MR, then this test will pass - that will help prove the fix and prevent / detect similar breakage in the future.

The latest Merge Request for these fixes by TR has failed. I have downloaded the patch file for these changes but will not upload them here since it's a large and risky patch file. I am available to help fix this module since it's used on several high profile websites and this issue needs to be fixed ASAP.

A link to the pipeline job.
https://git.drupalcode.org/project/rules/-/jobs/2141736

Uploading artifacts...
WARNING: junit.xml: no matching files. Ensure that the artifact path is relative to the working directory (/builds/project/rules) 
/builds/project/rules/web/sites/default/files/simpletest: found 231 matching artifact files and directories 
/builds/project/rules/web/sites/simpletest/browser_output: found 1182 matching artifact files and directories 
apache.access.log.txt: found 1 matching artifact files and directories 
apache.error.log.txt: found 1 matching artifact files and directories 
Uploading artifacts as "archive" to coordinator... 201 Created  id=2141736 responseStatus=201 Created token=glcbt-64
Uploading artifacts...
WARNING: junit.xml: no matching files. Ensure that the artifact path is relative to the working directory (/builds/project/rules) 
/builds/project/rules/web/sites/default/files/simpletest/phpunit-*.xml: found 115 matching artifact files and directories 
Uploading artifacts as "junit" to coordinator... 201 Created  id=2141736 responseStatus=201 Created token=glcbt-64
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: command terminated with exit code 1

The latest MR is not complete; it contains some changes that are necessary to the solution, including a test case to prove the eventual solution, but it is not yet intended to solve the entire issue. Specifically, the ConditionManager is not yet changed in the MR, and that's the ultimate point of this whole issue.

I will set the status to "Needs review" when it is ready to review. I have now set the current status to "Needs work" to make this point more clear.

Thank you for the offer to help. You're the first one to offer - I wish I had that offer 5000 lines of code and 100 hours of work ago ...

I am currently prototyping what I think is the last of the needed changes in 📌 [10.3] Convert RulesAction plugins and discovery to attributes Active , since the RulesAction plugins affect only Rules and not core. I have committed some of the changes made there, and I have added similar changes that I know work into the above MR for this issue. When RulesActionManager is demonstrated to be able to discover RulesActions plugins either by Annotation or Attributes (or both) in that issue, then we will have a solution for this issue.

I think this is now fixed. The new test case reproduces the error before the fixes, and succeeds after the fixes.

I installed the current 4.0.x-dev version (as of 21 Jul 2024 at 22:13 UTC) on a test site and enabled a pair of fairly simple user account related rules.

The site continues to function normally (before it would throw a fatal error) and both rules work exactly as intended (with no errors in the Drupal log). 🙌

Thanks for the amazing work here @TR! I realize this was a huge task that was unexpectedly thrown into your lap, and if there's somewhere we can make a contribution as a small token of gratitude for your efforts please let us know.

My dev and staging sites are up and running again with latest drupal and rules-dev.
I did not test all my rules, but the login redirection works like expected.
Thanks TR!

@TR thank you for your hard work on this issue. Your perseverance and dedication to the community is deeply appreciated. I'm sorry that I couldn't help you with it. I've had other obligations demanding my free time.

I tested the 4.0.x branch on one of our sites today. The site loaded successfully without any WSoD. We only have a couple of rules in place on it: one for emailing admins when a new user is registered and another emailing after a content workflow transition. Both rules worked correctly after the update.

Confirming rules 4.0.x is working on a project of mine running 10.3.1, thanks @TR.

Thanks for the amazing work here @TR! I realize this was a huge task that was unexpectedly thrown into your lap, and if there's somewhere we can make a contribution as a small token of gratitude for your efforts please let us know.

Hear, hear!

Does this also work on 10.2? What is the upgrade path to 10.3?

If you are using Drupal 10.2 then nothing is broken with Rules and you don't have to do anything.

The 4.0.0 release can not be installed on Drupal 10.2 because it uses features from Drupal core 10.3 that don't exist in Drupal core 10.2. The 4.0.0 release will only work on Drupal 10.3+ and Drupal 11.

If you upgrade to Drupal 10.3 using composer then Rules will automatically be upgraded as well - composer will use the version of Rules appropriate to your Drupal core version. If you upgrade core manually, then you will have to upgrade Rules manually.

Thank you.

If I have a rule plugin for 3.x will it likely need to be rewritten for compatibility with 4.x, or will it vary?

A Rules plugin written for 8.x-3.x will work with Rules 4.0.x.
That is a very important consideration, and I spent a lot of time on to make sure it would still work.

If you have problems running your plugin with the new version of Rules please open an issue here in the issue queue and I will look at it. It is supposed to work without a problem.

That's great.

Thanks again.

Just to follow up on the upgrade path I ended up doing the following:
1. Updated latest version of 3.x (latest version seems to require cache clear in order to discover new service)
2. Updated Drupal 10.2.x to 10.3.1
3. As I had specified prior version of rules (^3.0@alpha) in my composer.json, this has to be manually updated with 4.x e.g. composer require 'drupal/rules:^4.0' --with-all-dependencies. "With dependencies" flag appears to be required as old version of typed data is in composer.lock file (prior 2.x)
4. Another cache clear is required.

So far so good.

#75 Thank you!

I've been holding off dealing with this issue for a while now and finally got the energy to tackle it again. Once I isolated the error and Googled it, found this thread, and implemented the following with success!

composer require 'drupal/rules:^4.0' 'drupal/typed_data ^2.1'

vendor/bin/drush cache:rebuild

Same.

composer require 'drupal/rules:^4.0' 'drupal/typed_data ^2.1'
composer update
drush updb
drush cr

All green!
Thanks for all your hard work on this.

I'm left in a limbo state for 1 out of 3 sites. This issue is not resolved when going from 10.3.0 to 10.3.1 using the above commands do not resolve the site not being able to access the admin pages. I don't get that only a single site has this issue though. Is there a way I can remove the rules module and update correctly?

@tneo: Open a new issue if you are having problems. When you update Drupal core to 10.3 with composer (assuming you use --with-all-dependences, but why would you not do that?) you will also update Rules and Typed Data. A cache rebuild and cache clear is part of that normal upgrade process. If you see problems after doing that post the exact error messages etc. in a new issue.

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

#77 worked for me... Thanks All

#77 worked for me... Thanks All

#77 Worked fine, thanks