Call to undefined function rules_set_cache() in modules/all/rules/rules.install,line 517

I had disabled the rules modules in my test site once I enabled it I was able to update it.

The same is for my installation

drush -y updatedb -l site.com
 Rules  7214  Switch out the rules_event_whitelist variable for a cache 
              equivalent.
Do you wish to run all pending updates? (y/n): y
PHP Fatal error:  Call to undefined function rules_set_cache() in /sites/all/modules/contrib/rules/rules.install on line 517

Fatal error: Call to undefined function rules_set_cache() in /sites/all/modules/contrib/rules/rules.install on line 517
Drush command terminated abnormally due to an unrecoverable error.   [error]
Error: Call to undefined function rules_set_cache() in
/sites/all/modules/contrib/rules/rules.install,

Same as comment 1 - the module is there because the contributed modules directory is shared with another site, but Rules is not enabled. It shouldn't cause a fatal error when that's the case.

I added a module_exists() check.

Hit the same issue as others here with the update failing because Rules is installed but not enabled. In my case I have installed the updated version of the module and am running db updates via drush during a build process.
Looking at Brad's patch I'd be concerned that this would just cause Rules to never be updated (if you wanted to enable it later for example) but not sure what a better solution would be...

that's a good point. i guess the problem would be if you had Rules running previously, so that you had whitelist information in that variable. when you enabled Rules again, that whitelist information would be lost, abandoned in the old variable. maybe a call from the hook_enable() function to check for a non-empty "rules_event_whitelist" variable, that would run this same code?

confirmed. i had this on all my sites when updating 2.6 to 2.9
using multisite!

I encountered the same issue with sites that didn't have rules enabled, but it was present in the site/all directory. The patch in #3 solved my issue, but I understand the hesitation about using it.

I'm not well versed with the api/functions available in rules, but is a potential solution to delete the variable from the db, and then only perform the cache cleanup if rules is enabled?

my question is, as i ignored the error, if i can fix that later or if it will be fixed in the update of a newxt version?

this error will come up whenever rules is disabled but not uninstalled. the best workaround here would be to uninstall rules.

i'm not sure the test in the patch above is safe, since it will update the database schema version in the system table without having actually run any updates. if a user later enables this module they would have to manually run these database upgrades, or uninstall & re-install, which would mean losing any custom configuration they had done.

all of this is really a general problem with drupal update hooks. there's no clean way to run module specific code like this. unfortunately, the update hook can't depend on any other code from the module being available. fixing this would probably mean putting (renamed) copies of the relevant functions into the .install file. but just uninstalling rules where it's no longer needed is enough for my client, so i'm afraid someone else will have to write that.

this error will come up whenever rules is disabled but not uninstalled. the best workaround here would be to uninstall rules.

In a multi-site install you just cannot uninstall rules. We ran into this error when one of the multi-sites needed rules, the other did not. I remmed out all statements in function rules_update_7214() to get past the error. No nice solution, but rules_update_7214 was blocking other updates.

In a multi-site install you just cannot uninstall rules

what i mean is that the status of the rules module should not be "disabled", it should be either "installed" or "uninstalled". update.php will update the schema of disabled modules but not of uninstalled modules. the problem came up when the rules database schema was still in the db, but not being used.

the only reason to leave a module disabled but not uninstalled is when you expect to use it again later and you don't want to lose the configuration & data.

the only reason to leave a module disabled but not uninstalled is when you expect to use it again later and you don't want to lose the configuration & data.

No, there is another reason. In Drupal multi-site you will have a lot of modules that are installed because they are needed in one of the sites. They are not necessarily enabled in the other sites of the multi-site. To make it real clear:
http://axelfunke.nl and http://platformarbeidsverhoudingen.nl run under the same Drupal instance. The have some modules in common, but not all. All of these modules (and some more) are installed, but not always enabled. In Drupal multi-site it is a common practice to have modules disabled although they are installed.

Jan-E: in fact I am familiar with the drupal multi-site setup; I help maintain a server which currently runs 128 drupal sites spread over 9 platforms. many modules are in use (installed) on one or more of these sites but not on others.

the problem here is that the rules module *used* to be installed on one of your sites. it's now no longer in use, but if you look at the database, all the tables are still there. you need to get back to the state *before* you enabled rules on the site that doesn't use it.

please read http://cms.about.com/od/drupal-glossary/fl/Drupal-Modules-Disabling-vs-U... for a description of the difference between the "uninstalled" and "disabled" states, http://drupal.stackexchange.com/questions/22/do-non-enabled-drupal-modul... for an explanation of why leaving unused modules as disabled but not uninstalled can cause performance issues, #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed for a description of why none of this makes any sense and is a source of annoying problems in D7, and https://www.drupal.org/node/2193013 for a description of how and why this was fixed in D8 by eliminating the state "disabled" entirely so that things will in the future work as you describe.

I just wanted to chime in and say that I agree with mvc in this matter. If, for some reason, you don't want to lose your rules config when uninstalling, you could make a backup of the rules db tables.

Also, as mvc explained in comment #14, when you uninstall Rules from one site within a multi-site install, it will not affect a different site, assuming that you have not set rules tables to be shared across multiple sites in your settings.php file.

Despite the arguments about best practice when disabling modules, the fact is that some people are getting caught out by this update.

This patch will basically check to see if the module is installed and enable it if it's not, let the update do its thing and then return the module back to its original state.

This *should* mean that noone should get stuck during builds. Let's see if it works!

This time without the facepalm-worthy errors.

....aaand another one - I wish you could test patches in make files for build processes locally so I didn't have to post so many silly mistakes.

--------------------

So after testing this one out I can confirm that it's working.
https://www.drupal.org/files/issues/rules-fix-for-undefined-function-dur...
works to allow builds to go through.

Depending on your make files you'll probably want to use something like this:

projects[rules] = "2.9"
projects[rules][patch][] = "https://www.drupal.org/files/issues/rules-fix-for-undefined-function-during-db-updates-2449513-18.patch"

So for anyone else later, this patch is for when:

• You have had the Rules module installed in the past, you've disabled it, but haven't uninstalled it.
• You are using a build system that runs updates as part of the build.
• You're on a multisite setup or some other configuration where you can't just remove the Rules module from the build.

What this patch does is:

• Checks to see if the Rules module is enabled before trying to run functions from the Rules module.
• If it has to enable Rules to do the update, it also re-disables it afterwards.

And in all cases:

If you have to have the Rules module installed, but your site doesn't need it, uninstall it as well as just disabling it.

+1 does what it says on the tin. Did not review code. Looked at code, seems sane, and fixed issues on upgrade from D6 for this instance.

Enabling Rules would also have resolved the issue, but this patch is good as it enables it only during the update process.

Same for me, I put rules in my module folder then ran update, and got the error.It couldn't find that function because the module was not enabled. enable it, then ran update, no more error.

Patch works

Patch looks great and solves the issue, confirming RTBC and attaching a re-roll

Agreed. Adding definition of $disable_rules for the case when Rules is enabled to avoid "undefined variable" error.

ok, not the nicest workaround but makes sense. committed.