Is there a way to skip rule(s) when using backup_migrate module

From what I can see the config for the rules reaction is stored in the config table. e.g. in this case:

rules.reaction.new_news_content_x_tweet

So as config is shared, not sure there is a way to skip this specific row?

Alternatively, perhaps there is a way to only apply rules on a specific environment or otherwise. e.g. not dev.

I've had issues with rules firing during migrations too. I just disable the rule temporarily. If that isn't sufficient for some reason, then I don't have an alternative suggestion. It's as simple as that for me.

I have added a patch to backup_migrate that allows you to skip certain config tables. This is useful for modules like search_api when using backup and migrate.

https://www.drupal.org/project/backup_migrate/issues/3412141/ →

Also I have created a module that allows you to specify an environment condition that checks against the base url.

https://www.drupal.org/project/rules_condition_environment →

I'm sorry if my earlier comment wasn't helpful, everybody. I didn't catch that this was specifically about backup_migrate, with which I have no experience. I'm going to blame it on having the flu right now.

Rules is based on Events. If code that reacts to Events is problematic for backup_migrate, then how you you disable all Events on a site?

This is not a Rules-specific problem. Events are part of the core Drupal API, and it must be assumed that these Events operate normally at all times. If backup_migrate doesn't function properly when Events are enabled, then backup_migrate should be disabling all Events. There are ways to do that, but they need to be done in backup_migrate, not in each and every module that uses Events.

Rules has no "off switch". Rules is based on an event model of programming, which is fundamental to both Symfony and Drupal core. And in particular Hooks are also used for the same purpose as events - do you disable Hooks in backup_migrate?

I don't know what purpose backup_migrate serves in your workflow in Drupal 10+. All Rules are configuration. With most things in Drupal moved to configuration, differences between dev and production are usually handled by modules like config_split. Using that you can easily and automatically disable specific Rules in dev, or even use different configurations for dev.

@dcam, hope you are feeling better soon.

I thought your comment was valid.

@tr. I agree with you. Happy to close this issue.

With https://www.drupal.org/project/rules_condition_environment → you can specify the base url. This helps to make sure that rules are not fired (even if the event is triggered) on environments other than prod, e.g. development environment.

If using config or config_split you can probably do similar, but not sure how this would be done exactly.

If using backup_migrate (very useful where not using CI e.g. on smaller sites), it just makes sure that rules are not fired. e.g. when using https://www.drupal.org/project/social_post_x → that also comes with rules support, I can use backup and migrate to sync the latest db and not have to worry about inadvertently posting tweets when working on the dev environment.

With the patch to backup_migrate mentioned above it may also be possible to skip certain config for rules between environments e.g. rules.reaction.new_news_content_x_tweet but have I not really tried this.

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