After upgrading to 7.x-2.4 from 7.x-2.3, I get the following fatal error:

Fatal error: Class 'RulesEventHandlerEntityBundle' not found in /home/user/website/sites/all/modules/rules/modules/node.rules.inc on line 147

Summary:


The error can be triggered via drush or the update manager. Please continue reading below to see how to fix it:

For the problems with drush Rules 2.5 has been released containing an update that should fix it. However, it turns out that there is still a problem running drush up - probably due to a bug in drush (see the issue).

The following should solve any troubles using drush:

drush dl rules
drush updatedb

Regarding the update manager we've been able to reproduce the problem and got the solution by not trying to put the site into maintenance mode after code-update, or to do it manually via settings.php - see #10.

Non-drush users
After upgrading to Rules 2.5 make sure all updates have run through by visiting update.php. If you want to put your site into maintenance mode, do so before updating the code or do it manually via settings.php - see #10.

Files: 
CommentFileSizeAuthor
#214 fix_errors_on_update-2090511-214.patch779 byteslikewhoa
PASSED: [[SimpleTest]]: [MySQL] 355 pass(es).
[ View ]
#169 fix_rules.txt7.81 KBjerdiggity
#100 rules.png39.01 KBastutonet
#83 drupal error 28-9-2013.jpg82.38 KBjmussi
#83 drupal error 28-9-2013b.jpg78.71 KBjmussi
#47 d7_rules_registry.patch464 bytesfago
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]
#37 RulesEventHandlerEntityBundle-2090511-9.patch2.57 KBjerdiggity
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]

Comments

lennart.maschmeyer’s picture

exactly the same here

GemstoneLLC’s picture

exact same issue. I tried rebuilding registry, but finally had to roll back to 2.3 to get my site back up

Jednorozec’s picture

I'm running a number of sites off the same code base. The upgrade went fine on the first site but then I got the fatal error on all of the other sites that were using Rules.

DavidoffC’s picture

Had the same issue with several sites with different hosts, rolled back to 7.x-2.3 and everything's fine.

fago’s picture

That's strange - as the class should be included in the registry. Could you please report whether you update via drush updatedb or update.php - in case that makes a difference?

I'm running a number of sites off the same code base. The upgrade went fine on the first site but then I got the fatal error on all of the other sites that were using Rules.

Sounds like the problem is rules could kick in before the registry is updated. When exactly do you get the error, when you try running update.php?

jerdiggity’s picture

@fago: actually it was kind of a strange series of events, because the error did not occur immediately. In fact, it went something like this:

  1. Submitted "Download these updates" at admin/reports/updates/update (no problems)
  2. Ran preliminary updates, site taken out of maintenance mode (no problems)
  3. Navigated to update.php (still no problems)
  4. Clicked the link to put the site into maintenance mode: this is when I got WSOD'd

So for me, Drush was not used (in this particular case). All browser.

EDIT: see this video to see the problem in action.

Arnoldski’s picture

Exact same problem here, did update with Drush.

fago’s picture

Thanks jerdiggity - the process core takes here seems to be broken for me. It's not a good idea to activate maintenance mode once the code has been already udpated - you should do so before and leave it that way until updates have gone through.

Howsoever, does running update.php without putting site back into maintenance mode solve it for you, or doesn't that work either?

jerdiggity’s picture

Follow-up: if you do not attempt to put the site into maintenance mode during the update¹, the update runs smoothly and the error disappears afterwards.

¹ In a development environment, of course. If you're new to Drupal, please be advised that you should always put your site into Maintenance mode before running the update.php script.

fago’s picture

OR - just put the site manually into maintenance mode by putting the following in your settings.php

<?php
$conf
['maintenance_mode'] = TRUE;
?>
jerdiggity’s picture

Looks like you beat me to it... See above. ;)

(Yes -- that route works.)

fago’s picture

As described on the update.php page and at https://drupal.org/node/250790 - you should put it into maintenance mode before doing code updates also. Afterwards it might be too late as the site might not be functioning any more - as in this case. If the update-manager does it differently that's a problem with it.

ok, still - problems seem to occur with drush as well. Please post the exact steps taken and at which step the error occurs + whether manually running update.php solves it.

fago’s picture

@jerdiggity: Great it works, thanks for the video! -> Created #2090817: Update manager takes you out of maintenance mode too early for the update manager issue.

fonant’s picture

Drush fails whether maintenance_mode is 0 or 1, and whether the caches are cleared in advance or not.

Code updates will be made to the following projects: Rules [rules-7.x-2.4]

Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project rules was updated successfully. Installed version is now 7.x-2.4.
Backups were saved into the directory /root/drush-backups/mysitename/20130917100546/modules/rules.                                                                     [ok]
PHP Fatal error:  Class 'RulesEventHandlerEntityBundle' not found in /var/www/shared/drupal7/sites/all/modules/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.                                                                                                          [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in /var/www/shared/drupal7/sites/all/modules/rules/modules/node.rules.inc, line 147
The external command could not be executed due to an application error.                                                                                                     [error]
Backups were restored successfully.                                                                                                                                         [ok]

z.stolar’s picture

Is it possible for the mean time, just so not to break many many drush updaters, to re-set the stable version to the last known stable version?

My output:

Updated with Drush.
Drupal is already at 7.23 (so up to date).
Cleared cache and put into maintenance mode.

zohar@Zohars-MacBook-Pro:/var/www/drupal$ drush cc all
'all' cache was cleared in /var/www/drupal#default                                                              [success]

zohar@Zohars-MacBook-Pro:/var/www/drupal$ drush vset maintenance_mode TRUE
maintenance_mode was set to TRUE.                                                                                                     [success]

...

PHP Fatal error:  Class 'RulesEventHandlerEntityBundle' not found in /private/var/www/drupal/sites/all/modules/contrib/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.                                                                    [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in
/private/var/www/drupal/sites/all/modules/contrib/rules/modules/node.rules.inc, line 147

Fatal error: Class 'RulesEventHandlerEntityBundle' not found in /private/var/www/drupaldrupal/sites/all/modules/contrib/rules/modules/node.rules.inc on line 147
The external command could not be executed due to an application error.                                                               [error]

REo’s picture

Same problem here. Cleared the cache. Updated using drush with site in maintenance mode:

PHP Fatal error: Class 'RulesEventHandlerEntityBundle' not found in
[...] sites/all/modules/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in
[...] sites/all/modules/rules/modules/node.rules.inc, line 147
The external command could not be executed due to an application error.

fago’s picture

Two questions for the folks having drush issues:
* Does "drush updatedb" solve it?
* Does manually running "update.php" solve it once you had the error?

fonant’s picture

* Does "drush updatedb" solve it?

No, because running this before the code is updated does nothing. Drush would normally run updatedb automatically after the code update, but the code update fails so drush reverts to the previous working version.

* Does manually running "update.php" solve it once you had the error?

No, because the code is automatically reverted by drush because updating the code breaks everything.

So "drush up" won't ever work while this problem is present. It might be possible to force a download using "drush dl rules" and then "drush updatedb" but I suspect we'll still have this error, as that's effectively what "drush up" is doing anyway.

REo’s picture

Well, in my case:

*Does "drush updatedb" solve it?

No. It gives me the same error.

(PHP Fatal error: Class 'RulesEventHandlerEntityBundle' not found in
[...] sites/all/modules/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in
[...] sites/all/modules/rules/modules/node.rules.inc, line 147
The external command could not be executed due to an application error.)

*Does manually running "update.php" solve it once you had the error?

No, but I got:

Fatal error: Declaration of RulesReactionRule::events() must be compatible with that of RulesTriggerableInterface::events() in [...] sites/all/modules/rules/includes/rules.plugins.inc on line 348

JamesOakley’s picture

Ditto here.

drush dl rules - fine
drush updatedb - fine (7210 and 7211 went through)
drush cc all - failed on "Class 'RulesEventHandlerEntityBundle' not found" ... on line 147

To get the site back online, I had to do

drush dl rules-7.x-2.3
drush cc all

However I now have the database schema for 7.x-2.4, and the code for 7.x-2.3.

Is that a problem? Do I need to revert to a backup of my database too?

RaulMuroc’s picture

I think the point of view to solve this problem is not suitably focused.

This error always rises up, either the module is updated through Drush, Updates Manager or manually through ftp/ssh/other. Not just with Drush!

Reversing to Rules 7.x-2.3 solves the broken page.

JamesOakley’s picture

I wasn't meaning to imply that the error occurred because I used Drush. But I included the steps I took because (a) the precise way in which people update does seem to be a factor - not everyone is getting this, and (b) it left my database in the new state, and I wanted to know if that's going to cause problems for me.

fago’s picture

It looks like the error can be triggered via update manager + drush. Did someone trigger it otherwise also?

Regarding the update manager, we've been able to reproduce the problem and got the solution by not trying to put the site into maintenance mode after code-update, or to do it manually via settings.php - see #10.

Regarding drush I've not been able to reproduce the problem. Maybe, it's depending on the drush version used? In my test I've been running 5.8 - please report yours.

REo’s picture

My test has been done with drush 6.0 (and the error occurred).

haegar der schreckliche’s picture

I triggered the error with drush version 5.9.

fredcy’s picture

I get the same error as the OP. I'm using drush 5.8. I did not put the site into maintenance mode (I'm running this on a test system before I try it in production).

I tried running registry_rebuild per https://drupal.org/node/2048003 -- that made no difference.

olak’s picture

same problem here. updated rules for a site (trying to fix other unrelated issue) via drush (version: 4.5), from 7.23 to 7.24 and WSOD.
following https://drupal.org/node/2090511#comment-7869961 i reverted back to 7.23 and all is ok again

fonant’s picture

Drush 5.7 here.

z.stolar’s picture

Is there any coordination regarding the solution of this problem in IRC/IM somewhere?

jpstuddard’s picture

Running Drush 4.5
Ran drush cc all did not work
Ran drush updatedb did not work
Ran drush rr, FIXED!

z.stolar’s picture

#30 Did not work for me.

chicagomom’s picture

Drush 5.8
Drupal 7.20
All other modules up to date.
Tried drush pm-update rules in maintenance mode and not.

drush updatedb didn't work
drush rr didn't work

Manually updating rules renders the site inoperable. Reverting to Rules 7.x-2.3 fixes that.

z.stolar’s picture

To bypass the problem in the meantime:
drush up --lock=rules rules-7.x-2.3
drush up --lock=rules

Jednorozec’s picture

I have Administration Menu enabled and just went to Modules/Update and let Drupal take care of the download and installation. Then clicked the link to do the database update and that went fine. However, every other site that had Rules enabled presented the Fatal error when I tried to go to it. So all of those sites were totally down.

rkneale’s picture

Add another to the pile who did drush update to Rules and now everything is ka-flooey. I have had no luck with any of the above (cc all, set the site offline manually, run updatedb, run update.php) - nada. How do you revert to the earlier version of Rules? I tried disabling 7.x-2.4 and downloading 7.x-2.3, but each command (dis and dl) gives me the same abnormal early termination.

I am far from a Drupal guru and trying not to completely panic here...

torgosPizza’s picture

The tip in #10 worked for me, with a minor modification:

1. Rolled Rules back to 2.3.
2. drush cc all
3. Using drush sqlq I set {system}.schema_version for 'rules' back to 7209 (to run the updates again).
4. Updated Rules code to 2.4 with settings.php $conf['maintenance_mode'] = TRUE;
5. drush cc all, drush updb (only update 7211 failed because the 'owner' field had been created previously.
Ignored it and set {system}.schema_version for Rules back to 7211.)
6. Site is online, no Fatal errors.

Not sure if this will help anyone but it worked for me. Drush version 7.23.

jerdiggity’s picture

Status:Active» Needs review
StatusFileSize
new2.57 KB
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]

@fago: Is this an acceptable fix? Worked for me... Only potential problem I could see would (maybe) be a miniscule performance hit, but you would know better than I would.

Sam Moore’s picture

Patch in #37 works for me.
Thank you sir.

nwehner’s picture

I was able to fix the problem for 6 hours by rebuilding my registry. But after those 6 hours, I had to rebuild my registry again to make my site operational. Reverting to 2.3 has not created any errors so far. Odd thing is, I never had to rebuild registry ever on my Dev and Test environments, only Live!

roman_pro’s picture

drush rr worked for me.
make sure you have the latest version of registry_rebuild though

cpritz’s picture

update to latest dev version worked for me

orlitzky’s picture

There's a subtle problem with conditionally defined classes that's going to get worse as php-5.5 adoption increases. Any time a file's interface (classes, functions, DEFINEs,...) is created dynamically, you create a race condition for opcode caches. In php <= 5.4, users had to go out of their way a bit to install e.g. APC. But with php-5.5, opcache is included by default, so this is going to cause difficult-to-debug problems.

We already hit this once with APC; here's an example scenario (which may or may not be accurate, I haven't looked at the rules code):

  1. Someone hits a page that includes node.rules.inc, the class gets created, and the result is cached
  2. Things work for a while
  3. Someone hits a page that includes node.rules.inc multiple times, and processing begins. The first time it needs node.rules.inc, it looks to the cache: the class is there. Great. But the page isn't done processing yet.
  4. We run out of memory, and the cache begins to purge.
  5. The second (or third, or...) time that node.rules.inc is included, it isn't in the cache. So it's compiled again. But this time, the class already exists (from the first time it was included). Now, the resulting node.rules.inc doesn't contain the class, and we cache this version as 'node.rules.inc', since the other one was just purged.
  6. From now on, the cached 'node.rules.inc' doesn't contain the class.
JamesOakley’s picture

Re: #41

update to latest dev version worked for me

The latest dev version has identical code to 7.x-2.4. If 7.x-2.4 broke for you, but 7.x-2.x-dev worked, there must be some other explanation for that.

ben_chad’s picture

Subscribing.

dema501’s picture

I've updated rules on my env
All works fine!

I did:

1) drush dl registry_rebuild
2) drush @env up rules
3) drush @env rr
4) drush @env cc all
FreeFox’s picture

Indeed, strange problem ...

I had the same error. drush rr and drush cc didn't help.
After reading #41 & #43, I checked the 2 versions too and ... all the same except the versions and timestamps in the info files.

- While having the error I did => drush dl rules --select and selected the dev version.
- It installed fine
- drush cc gave an error of a missing column in db
- drush updb ran fine and updated Rules 7210, 7211, 7203 and 7204.
- drush cc => no errors
If error => drush rr => drush cc again
- drush dl rules --select and selected the 2.4 (stable) version => overwrite
- drush cc => no errors

So now I have the stable version without errors.

Conclusion: try downloading dev, update database manually

Hope this helps

fago’s picture

StatusFileSize
new464 bytes
PASSED: [[SimpleTest]]: [MySQL] 351 pass(es).
[ View ]

Thanks for the patch, but I do not think conditionally defining the classes is a good idea. If people end up with the broken registry, the breakage is just postponed until one of the classes would be required.

The latest dev version has identical code to 7.x-2.4. If 7.x-2.4 broke for you, but 7.x-2.x-dev worked, there must be some other explanation for that.

I guess it's related to the update invoking a cache clear, so a registry rebuild.

ok - so this issue sucks a lot. I cannot follow why this does not work on a regular update.php, so I can only guess: So here is a patch that should help - I guess. Anyone experiencing the issue, please try applying the patch + running update.php via drush and report whether it helps.

Then, it would be awesome if someone experiencing the issue could test a direct upgrade from 2.3 with the patch, i.e. apply the patch + run drush updatedb or update.php.

FreeFox’s picture

Edit: I added the line "If error => drush rr => drush cc again" in my post #46.

ano.nimmus’s picture

While this is being worked on, how do we get out of the failure mode?

drush up --lock=rules rules-7.x-2.x-dev
PHP Fatal error:  Class 'RulesEventHandlerEntityBundle' not found in /svr/www/drupal7/site003.loc/sites/all/modules/contrib/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.                                        [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in
/svr/www/drupal7/site003.loc/sites/all/modules/contrib/rules/modules/node.rules.inc, line
147
drush up --lock=rules
PHP Fatal error:  Class 'RulesEventHandlerEntityBundle' not found in /svr/www/drupal7/site003.loc/sites/all/modules/contrib/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.                                        [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in
/svr/www/drupal7/site003.loc/sites/all/modules/contrib/rules/modules/node.rules.inc, line
147

I can't get past this now.

Should I delete the module dir manually? Other?

orlitzky’s picture

I tested this on a low-traffic site of ours. First, this was failing,

$ drush up
...
Backups were saved into the directory                                [ok]
/home/mjo/.drush-backups/drupal_adsdrives/20130918164606/modules/rules.
Fatal error: Class 'RulesEventHandlerEntityBundle' not found in /var/www/adsdrives.com/www/public/sites/default/modules/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.   [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in
/var/www/adsdrives.com/www/public/sites/default/modules/rules/modules/node.rules.inc,
line 147
The external command could not be executed due to an application     [error]
error.
Backups were restored successfully.                                  [ok]

Now, downloading rules-2.4 manually and patching works:

$ rm -rf rules
$ wget -q http://ftp.drupal.org/files/projects/rules-7.x-2.4.tar.gz
$ tar -xf rules-7.x-2.4.tar.gz
$ rm rules-7.x-2.4.tar.gz
$ cd rules
$ wget -q https://drupal.org/files/d7_rules_registry.patch
$ patch -p1 < d7_rules_registry.patch
patching file rules.install
$ drush updatedb
The following updates are pending:

rules module :
  7210 -   Deletes the unused rules_empty_sets variable.
  7211 -   Creates the "owner" column.
  7212 -   Make sure registry gets rebuilt to avoid upgrade troubles.

Do you wish to run all pending updates? (y/n): y
Performed update: rules_update_7210                                  [ok]
Performed update: rules_update_7211                                  [ok]
Performed update: rules_update_7212                                  [ok]
Finished performing updates.

The site seems OK, but I haven't done a ton of testing.

ano.nimmus’s picture

That seems to work:

rm -rf rules
wget -q http://ftp.drupal.org/files/projects/rules-7.x-2.4.tar.gz
tar -xf rules-7.x-2.4.tar.gz
rm rules-7.x-2.4.tar.gz
cd rules
wget -q https://drupal.org/files/d7_rules_registry.patch
patch -p1 < d7_rules_registry.patch
patching file rules.install
drush updatedb
Rules  7212  Make sure registry gets rebuilt to avoid upgrade troubles.
Do you wish to run all pending updates? (y/n): y
Performed update: rules_update_7212       [ok]
'all' cache was cleared in site003        [success]
Finished performing updates.              [ok]
drush up
Update information last refreshed: Wed, 2013-09-18 01:38
No code updates available.                [ok]

at least as far as the update goes. Haven't done any further testing, yet.

Thanks!

torgosPizza’s picture

Patch in #47 worked perfectly for me. (Visited update.php manually, no drush this time.)

nicxvan’s picture

I too experienced this. I used drush up, but it refused to download the rules update.
Next I checked the module page and saw no notes regarding the update process (PLEASE note this on the module page)
Clicking the checkbox in the update manager didn't work either for downloading the code. (Note it did show up as needing updates in the update page)

Then I manually downloaded rules 2.4 and ran drush updb and it broke everything with the above error, rolling the code back fixed everything.

Patching 2.4 and upgrading worked flawlessly

nicxvan’s picture

In case I wasn't clear, I patched 2.4 with the patch in #47 and ran drush @sites updb.

Also I think it would be good to make a note on the project page that the upgrade path is broken in drush.

reallyordinary’s picture

I drush dl'd the latest version, ran drush updatedb, & it trashed my site in similar fashion to people above. I just tried doing the steps in #51 - I got this:

Performed update: rules_update_7212 [ok]
class_implements(): Class RulesEntityController does not exist and could not be loaded entity.module:673 [warning]
in_array() expects parameter 2 to be array, boolean given entity.module:673 [warning]
'all' cache was cleared in self

Site seems to be back up now but... I have no idea what condition the module itself is in.

fago’s picture

Status:Needs review» Fixed

Thanks for testing #47 - as it looks like it works I've committed it + tagged 2.5 to avoid more upgrade pain. Let's see whether this works out.

JamesOakley’s picture

Just by way of feeding back:

+1 from me.

I had rolled my code and database back to before I tried upgrading 7.x-2.3 -> 7.x-2.4.

I then ran

drush dl rules-7.x-2.5
drush updatedb
drush cc all

And all is working this time.

espurnes’s picture

Now Rules 7.x-2.5 is released to avoid these updating problems. But I tried to upload it via drush and it still brakes the update.

drush up

Name                                                     Installed Version  Proposed version                  
Rules (rules)                                            7.x-2.3               7.x-2.5          

PHP Fatal error:  Class 'RulesEventHandlerEntityBundle' not found in /var/home/timit/htdocs/mysite/sites/all/modules/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.                                                                                                [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in /var/home/timit/htdocs/mysite/sites/all/modules/rules/modules/node.rules.inc, line 147
The external command could not be executed due to an application error.

JamesOakley’s picture

Does anyone think there's an issue here for the core issue queue? Should all calls to updatedb automatically rebuild the registry in case there are inheritance issues? Or should it remain something that individual projects do as/when they change something that may break without it?

espurnes’s picture

#57 worked for me. :)

FreeFox’s picture

#57 is working but drush up rules does not:

[]# drush rr
The registry has been rebuilt in the pre-DRUPAL_BOOTSTRAP_FULL phase. [success]
The registry has been rebuilt in DRUPAL_BOOTSTRAP_FULL. [success]
'drush' cache was cleared [success]

[]# drush up rules
Name Installed Version Proposed version Message
Rules (rules) 7.x-2.3 7.x-2.5 Update available

Update information last refreshed: Thu, 09/19/2013 - 10:46
Code updates will be made to the following projects: Rules [rules-7.x-2.5]

Note: A backup of your project will be stored to backups directory if it is not managed by a supported version control system.
Note: If you have made any modifications to any file that belongs to one of these projects, you will have to migrate those modifications after updating.
Do you really want to continue with the update process? (y/n): y
Project rules was updated successfully. Installed version is now 7.x-2.5.
Backups were saved into the directory /root/drush-backups/d7_xyz/20130919084802/modules/rules. [ok]
PHP Fatal error: Class 'RulesEventHandlerEntityBundle' not found in /web/drupal7/xyz/sites/all/modules/contrib/rules/modules/node.rules.inc on line 147
PHP Stack trace:
PHP 1. {main}() /usr/share/pear/drush/drush.php:0
PHP 2. drush_main() /usr/share/pear/drush/drush.php:16
PHP 3. _drush_bootstrap_and_dispatch() /usr/share/pear/drush/drush.php:61
PHP 4. drush_bootstrap_to_phase() /usr/share/pear/drush/drush.php:81
PHP 5. drush_bootstrap() /usr/share/pear/drush/includes/bootstrap.inc:308
PHP 6. _drush_bootstrap_drupal_full() /usr/share/pear/drush/includes/bootstrap.inc:185
PHP 7. drupal_bootstrap() /usr/share/pear/drush/includes/bootstrap.inc:936
PHP 8. _drupal_bootstrap_full() /web/drupal7/xyz/includes/bootstrap.inc:2218
PHP 9. module_invoke_all() /web/drupal7/xyz/includes/common.inc:5141
PHP 10. call_user_func_array() /web/drupal7/xyz/includes/module.inc:895
PHP 11. rules_init() /web/drupal7/xyz/includes/module.inc:895
PHP 12. rules_invoke_event() /web/drupal7/xyz/sites/all/modules/contrib/rules/rules.module:12
PHP 13. rules_get_cache() /web/drupal7/xyz/sites/all/modules/contrib/rules/rules.module:969
PHP 14. RulesEventSet::rebuildEventCache() /web/drupal7/xyz/sites/all/modules/contrib/rules/rules.module:333
PHP 15. rules_fetch_data() /web/drupal7/xyz/sites/all/modules/contrib/rules/includes/rules.plugins.inc:761
PHP 16. module_implements() /web/drupal7/xyz/sites/all/modules/contrib/rules/rules.module:216
PHP 17. module_load_include() /web/drupal7/xyz/includes/module.inc:740
PHP 18. require_once() /web/drupal7/xyz/includes/module.inc:330
PHP 19. module_load_include() /web/drupal7/xyz/sites/all/modules/contrib/rules/rules.rules.inc:12
PHP 20. require_once() /web/drupal7/xyz/includes/module.inc:330
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Class 'RulesEventHandlerEntityBundle' not found in /web/drupal7/xyz/sites/all/modules/contrib/rules/modules/node.rules.inc, line 147
The external command could not be executed due to an application error. [error]
Backups were restored successfully.
[]#

fonant’s picture

Can confirm that "drush up" still broken with 7.x-2.5

Separating the task into download ("drush dl") and then database update ("drush updatedb") works here.

fago’s picture

Thanks for reporting! This seems to be a drush issue to me then - so I've opened one:

https://github.com/drush-ops/drush/issues/132

If you have the problem that "drush up" does not work while "drush dl + drush updatedb" does please provided drush version information to the drush issue and help troubleshooting it over there!

haegar der schreckliche’s picture

Status:Fixed» Needs review

For me, the update to rules 7.x-2.5 is not working using drush.
I get the same error like #58.

haegar der schreckliche’s picture

Status:Needs review» Fixed

Sorry

haegar der schreckliche’s picture

Issue summary:View changes

Updated issue summary.

fago’s picture

Issue summary:View changes

updated summary

fago’s picture

Issue summary:View changes

Updated issue summary.

lalweil’s picture

On update I was getting the RulesEventHandlerEntityBundle error, and #37 did resolve this. Then, on other sites that built over night, I started getting:

drupal Fatal error: Class 'RulesEventDefaultHandler' not found.

The patch in #47 and running update.php resolved that one for me.

busla’s picture

I´m using Aegir and Rules 2.4 threw the error when creating a platform. This solved it for me:

  • added the patch in my make file
  • created a new platform (success)
  • cloned my site from the earlier versioned platform to the new one
  • everything works as expected.
niki v’s picture

Version:7.x-2.4» 7.x-2.5
Status:Fixed» Active

I upgraded manually to 7.x-2.5 and broke my site with the above error but I also get:

Fatal error: Class 'RulesUIController' not found in /home/mysite/public_html/sites/all/modules/commerce/modules/checkout/commerce_checkout.module on line 60

The site is running Drupal Commerce

JamesOakley’s picture

Version:7.x-2.5» 7.x-2.4
Status:Active» Fixed

@niki v

Your issue does not sound like the same one as the issue being discussed in this thread.

I suggest either opening another issue in the Rules issue queue, or opening one in the Commerce queue. It sounds to me like it's an issue with Commerce rather than Rules, but I could be wrong about that

torstenzenk’s picture

doing it like described in #57 works!!!

niki v’s picture

@James
I'm running a production site fine on Rules 7.x2.3, no issues with commerce modules. I didn't update to 7.x2.4, but straight to 7.x2.5

On a manual update "Fatal error: Class 'RulesEventHandlerEntityBundle' not found" was the first error message shown, although if I navigate to the site, it appears to actually be working, until anything invoking rules is required, then I get the commerce-related fatal errors. I'm not sure if this is a commerce issue or not, but I can confirm that the "Fatal error: Class 'RulesEventHandlerEntityBundle' not found" still exists on a manual upgrade to 7.x2.5

I rolled the site back to 7.x2.3 and all is working as it should

JamesOakley’s picture

Part of that does sound the same as this issue.

However RulesUIController being missing sounds different. It may be that a change in the Rules module now causes problems for Commerce; I'm still not persuaded it's this issue.

IIWY, I'd open a new issue under Rules, explaining the error Commerce is throwing, but that it's the upgrade from 7.x-2.3 to 7.x-2.4/5 that is causing it. If the maintainers think it's the same as this issue, they'll close your new issue as a duplicate and re-open this one.

NancyDru’s picture

I guess there is an advantage to not using Drush. I just did update.php manually and the problem went away.

vegantriathlete’s picture

Version:7.x-2.4» 7.x-2.5
Status:Fixed» Needs work

I don't know if you want the title updated or not. It seems like you are marking #2090463: Update with drush not possible as a duplicate of this one.

This is still a problem in 7.x-2.5. Drush still can't do the update via drush up.

I am upgrading from 7.x-2.3 -> 7.x-2.5 (as it failed from 7.x-2.3 -> 7.x-2.4).

While I could follow the instructions to drush dl, drush updb and drush cc all I think that would just be sidestepping this issue. Since the site which is using Rules is not critical I am happy to wait for another attempt to fix this problem and see if it will work with the 7.x-2.6 version.

fago’s picture

Status:Needs work» Fixed

While I could follow the instructions to drush dl, drush updb and drush cc all I think that would just be sidestepping this issue.

The issue has been reported to the drush queue and is dealt with over there - the Rules problem is fixed.

steinmb’s picture

Drush is now on github. Had a quick look through the issue q but was unable to find the followup issue. Anyone got a link to it?

brunorios1’s picture

auntvanilla’s picture

I'm having the same problem. I had recently backed up my database and restored it. I made a few changes to the database and cleared the cache. Then I updated Rules using update from the Modules menu (which I assume uses update.php). I had Rules 7.x-2.3 installed and went directly to 7.x-2.5. I haven't used Drush at all.

I tried using registry-rebuild, and when I try to bring up a page, I get.... nothing - an empty page. I read somewhere that it doesn't work with Drupal 7.22. I can still run update.php, but I get the error. If I could figure out how to remove the Rules update from the pending updates would that help?

JamesOakley’s picture

@auntvanilla

Whilst that is a problem with the update from 7.x-2.3 to a later version, are you sure it is the same problem? It sounds very different from the rest of this thread. You may wish to open a new issue in the Rules queue for this one.

auntvanilla’s picture

I'm pretty sure it is the same error. Until I tried using registry-rebuild, I was getting "Fatal error: Class 'RulesEventHandlerEntityBundle' not found in..." on every page I tried to open, just like everyone else. I just very cleverly forgot to mention that part (face palm).

I think the registry-rebuild error is a red herring, maybe a separate issue, maybe caused in part by the RulesEventHandlerEntityBundle error. But it's a secondary problem.

alanpeart’s picture

Manual update to 7.x-2.5 broke my site with the following error:

Fatal error: Class 'RulesConditionHandlerBase' not found in /home/seustace/public_html/crc/sites/all/modules/rules/modules/node.eval.inc on line 14

I had put the site into maintenance mode before starting the update. Downgrading to 7.x-2.3 solved the problem (and also caused the remaining module updates to be processed, which they hadn't been before).

alayham’s picture

Had the same issue today, solved like this:

  1. Disabled Rules and all its dependent modules
  2. updated the entire site
  3. re-enabled the modules I disabled in the first step. Rules still not updated, but all other modules are updated.
jmussi’s picture

Status:Fixed» Active
StatusFileSize
new78.71 KB
new82.38 KB

I've had no shortage of headaches after updating the rules module yesterday.
used some of the suggestions above and ended up with the following situation:

a) site is asking me to rebuild access permissions but fails with the following message (see file 1)

b) if I try to see if updates were completed I get the following message (see file 2).

This is what I see in the log when trying to rebuild access permissions:

Notice: Undefined index: controller class in entity_get_controller() (line 7748 of /home/content/02/7225902/html/includes/common.inc)

Any suggestions?
My site is not showing many of the posts for anyone not signed in, and this is a problem for us.

Thank you

fago’s picture

Status:Active» Fixed

#83 does not seem to be related to the issue please open a separate one. Thanks.

alanpeart’s picture

Curious about the "fixed" status here. What's fixed?

fago’s picture

See #56. If you are not running into the error of the issue summary, please open your own issue instead of re-opening this one.

JamesOakley’s picture

Version:7.x-2.5» 7.x-2.4

What's fixed? This precise issue.

If you look at the issue summary at the top, there was an error being thrown by some sites that had updated from 7.x-2.3 to 7.x-2.4.

An update to the module was found, and committed, that solved this.

Once it was clear that the solution worked, 7.x-2.5 was released. People who had upgraded from 7.x-2.3 to 7.x-2.4 should be able to fix any issues by installing 7.x-2.5 and running update.php. Those who had not should be able to have all the benefits of 7.x-2.4 by installing 7.x-2.5 and running update.php, but without triggering this error.

There may well be other issues with the upgrade from 7.x-2.3 to 7.x-2.4 or 7.x-2.5. I see that you reported an error in #81 of this thread - a different error from the one being discussed here. If there are different issues, those can be discussed and eventually resolved in their own threads. This one is fixed, in that the tested solution has been committed to the repository.

alanpeart’s picture

Apologies. I followed the link on the module front page under "Update troubles?" which is how I ended up here - I assumed it was the same issue.

jmussi’s picture

I've opened a new issue relating to my post #83. Thanks and sorry for any confusion.

ardnet’s picture

Wow, this thread are very long to follow just to find out the answer :)

I finally just do the update Rules manually (without using "drush up"), then do "drush rr" afterward (which must download first from here: https://drupal.org/project/registry_rebuild), that's it.

G'luck.
Cheers

nicxvan’s picture

ardnet the solution is at the very top of the thread.

The following should solve any troubles using drush:

drush dl rules
drush updatedb

alayham’s picture

can anybody confirm a successful update from 2.3 to 2.5 or the latest dev even with drush rr?

nicxvan’s picture

alayaham
I can but you don't need drush rr you need:

drush dl rules
drush updb

NancyDru’s picture

I got by this problem with just an update.php. However, I have run into other issues with 2.4, so I've gone back to 2.3 and will wait for 2.6.

snowmountain’s picture

I just tried updating from 2.3 to 2.5, and got the same error

Fatal error: Class 'RulesEventHandlerEntityBundle' not found in ... sites/all/modules/rules/modules/node.rules.inc on line 147

I used drush to download the code, and then tried drush rr

$ drush rr
Drush command terminated abnormally due to an unrecoverable error.
Error: Class 'RulesEventHandlerEntityBundle' not found in /.../public_html/.../sites/all/modules/rules/modules/node.rules.inc, line 147

The site was already in maintenance mode before code downloading, and reverting to 2.3 got rid of the error.

snowmountain’s picture

More on #95: My drush version is 5.8

steinmb’s picture

@snowmountain should test this with latest dev. of drush.

jooblay.me’s picture

The only solutions we have been able to validate is to $drush pm-disable rules with results in rules being disabled.

Then running $drush pm-update -y finishing the 27 odd updates including rules.

Once rules has validated with the update. We then $drush pm-enable rules + all other disabled modules as a result of $drush pm-disable rules the first time.

While rules was disabled we also ran $drush updatedb and $drush pm-update -y Then $drush cache-clear all

At this time all sites seem stable with no errors on 75% page tests in the ui. Rules integrity checks showed no broken rules.

Important note on core update module: In order to update rules while it is disabled you must have the update module checking for updates of disabled modules. Then $drush pm-update -y should turn rules.

more here... https://drupal.org/node/2048003

zeyfah’s picture

How about when a site never uses the Rules module? there shouldn't be any Rules data on the database nor the site. Has these people encountered the same error?

How about NOT using Drush? Uninstalling the old Rules 2.3 manually from administrator page, then do the installation and do update.php manually.

Has anyone tried that?

astutonet’s picture

StatusFileSize
new39.01 KB

Hi

I also have these issue on a website. I'm not using Drush. Using Rules 7.x-2.5

At the production site, the error message is:

Fatal error: Class 'RulesEventHandlerEntityBundle' not found in /home/mysite/public_html/sites/all/modules/rules/modules/node.rules.inc on line 147

At the local site, the message is:

The patches do not solve the issue.

Revert to any previous version solves the issue?? Any idea?

Tks.

jooblay.me’s picture

We have not experienced this issue **WITHOUT** having the rules module enabled. We have about 19 sites I believe that generated this error. The only solution we found was via drush by disabling the rules module and then enabling rules and about 29 other modules in a set of drush commands as stated in #98

I would imagine this error is actually quite fatal if your not using drush.

If you do not have drush then you would need to disable rules but first disable all required modules via the user interface. Then perform the update and then enable all the modules again.

It would seem that is a huge process is your running commerce. :(

Mehrdad201’s picture

Same as you...

I upgraded from 2.3 to 2.5 directly and I faced the same error "Fatal error: Class 'RulesEventHandlerEntityBundle".

I had to return to 2.3 version.

Mehrdad201’s picture

Issue summary:View changes

Updated issue summary.

fago’s picture

Have you guys not using drush made sure all updates have run through by visiting update.php?
I added some instructions for non-drush users to the summary also.

NancyDru’s picture

Yes, I did. This error disappeared after update.php. But other issues showed up, especially in editing some of our rules.

Stephen Ollman’s picture

when I do a general 'drush up' I get the rules error.

But if I do

drush dl rules
drush updb

then drush up, it all works beautifully.

vegantriathlete’s picture

I can confirm that following the suggestions in the summary works. I happen to be using a mult-site install, so I need to use the -l option from drush. But, basically what I did was a drush dl rules which informed me that rules was already installed at that location and asked me if I wanted to overwrite it, to which I chose 'y'. Next, just for curiosity's sake I did a drush up which (not surprisingly) resulted in a fatal error. So, I did a drush updb which did, in fact, run a number of updates. Finally, I once again tested drush up which now ran without issue (although there was nothing to update at this time).

Thanks for your work and help on this!

Paul B’s picture

Running drush updatedb fixed the problem for me, but it came back after checking out an earlier version, clearing the cache and checking out the latest version. I had to fix it again by setting the schema_version for rules back to 7211 and running drush updatedb again.

codesmith’s picture

1) I needed to update from Rules 7.x-2.3 to 7.x-2.5

2) Using 'drush up' failed with

PHP Fatal error:  Class 'RulesEventHandlerEntityBundle' not found in /srv/www/societyforasianart.org/httpdocs/sites/all/modules/rules/modules/node.rules.inc on line 147

3) I upgraded to drush 6.1.0 and was able to update Rules with no errors using 'drush up'

Ryan Weal’s picture

Ugh, I went through this through each stage of deployment process at 1am, on three instances of the same site. I am going to be such a zombie tomorrow...

So here is how to fix:

drush dl rules-2.3
drush dl entity
drush cc all
drush dl rules
drush sql-cli
update system set schema_version=7211 where name='rules';
drush updatedb

You cannot use entity-1.x-dev at this time.

basvredeling’s picture

Darn, this is nasty. Running drush updb separately seems to work.

axel.rutz’s picture

Thanks so much for the fix #109. Minor typo with rules version:

drush dl rules-7.x-2.3
drush dl entity
drush cc all
drush updatedb
drush dl rules
drush sql-cli
update system set schema_version=7211 where name='rules';
drush updatedb

EDIT: don't miss the first updatedb.

NancyDru’s picture

And for people who don't Drush?

jooblay.me’s picture

The only way to fix this issue with or without drush at we have found is by disabling all modules that depend on rules. Then update all modules and tables in the database.

Once all modules have been updated enable all modules that once were enabled before disabling. The issue we found on a small install through the ui was errors can occur while updating. But then again I really can not imagine running a large site on drupal without drush.

This is a major issue:(

NancyDru’s picture

Well, believe it or not, some of us do maintain large Drupal sites without Drush.

Yes, this is major. I just looked and Rules is at least six levels down in the module dependency hierarchy, and some of the ones higher up are utterly critical to the site. I guess I'll be sitting on 7.x-2.3 for a while.

Ryan Weal’s picture

Version:7.x-2.4» 7.x-2.5
Status:Fixed» Active

Updating status to 7.x-2.5 active. Seems this is the same as the original error and is affecting the latest version also. The path way to get there seems to be in #111 and might be caused by different versions of entity module.

Thanks @axel.rutz for revising my drush commands.

@NancyDru maybe you can do maintenance mode manually like in #10 (if getting white screen of death), then download the stable version of entity module and rules version 2.3, run update.php, then get the latest rules (version 2.5), but before doing anything with it, go into phpmyadmin or however you access the db and run "update system set schema_version=7211 where name='rules';" THEN run update.php with rules 2.5.

johnv’s picture

Title:7.x-2.4 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found"» 7.x-2.4/2.5 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found"

FWIW, I encountered the WSOD on a 'new' Rules 2.5 install (so no update from previous version), and trying to maintain new rules actions & conditions. Reverting to 2.3 solved the issue, even without undoing the hook_update_N.

It seems like ATM we are trying to eliminate the symptom, instead of finding the root cause of the problem.
O ja, not using drush, either.

alanpeart’s picture

I tend to agree that a complicated and specific upgrade procedure is not a solution. For now would anyone agree that it should be made very clear to everyone who visits this thread NOT to attempt to upgrade past 7.x-2.3?

To be clear, I mean non-technical users who may lose a lot of time and/or hair if they try to upgrade.

jooblay.me’s picture

THESE INSTRUCTIONS AS A FIX COLLAPSED && FAILED.

jooblay.me’s picture

THESE INSTRUCTIONS AS A FIX COLLAPSED && FAILED.

jooblay.me’s picture

More on this issue,

Even after updating via drush and in the UI rules upgrades with no errors other then the listed one here. Now checking 75% of the site the commerce_paypal_ec payment method is missing from commerce payment methods. admin/commerce/config/payment-methods

We have ran this on multiple sites and it seems to be the rules-2.5 upgrade that is causing paypal payment method to fault. On top of that at checkout it seems the cart is not able to select a status, shopping cart, complete, so on...

More later...

yalis reaper’s picture

This is what happened to me. It seems that what ever sites I was logged into the update was okay, but the others gave me the fatal error.

jooblay.me’s picture

Totally agree, it is back to square one. We thought we had this with the disable. We rolled rules back to 2.4 on all sites. We have failed to fix this on all levels at this time.

Even though rules upgraded without errors commerce_paypal_ec and the shopping cart in commerce exploded and started freaking on a few levels.

Anyone trying to upgrade on this take note of the commerce and paypal modules rules.

:(

jooblay.me’s picture

On the most recent update of rules-2.5 the this issue seems fixed. But we are getting a new issue. The payment methods seems to break commerce_paypal_ec in the UI.

This also seems to be related to a broken cart status not being able to be set. Checkout in commerce operates as normal to the end user but once checkout is complete the status remains unset.

raveendrab’s picture

Problem still persists.
I am using debian wheezy php 5.4.x

jooblay.me’s picture

We are running to systems:
ubuntu 12.04 lts php5.3.17

centos 5.9 php5.3.17

For us the update now seems to work. But errors on the status setting of the cart on checkout and paypal as stated above.

Ryan Weal’s picture

Thought I was stable on 2.5 but I just went to the rules page to change something and WSOD...

Edit: it appears to have been an issue with commerce_coupon.

Ryan Weal’s picture

Re: #126 I was wrong. It was still having trouble caused by the upgrade.

While I was researching I found this similar issue: #2094879: Column owner not created in rules_config on update 2.3 to 2.5.

How did I get back after 1h of downtime to the live site in the middle of the day?

drush sql-cli
update system set schema_version=7200 where name='rules';
drush updatedb

then it failed on 7202, so I know it ran before... so...

drush sql-cli
update system set schema_version=7202 where name='rules';
drush updatedb

then it failed on 7209, so I know that one ran before...

drush sql-cli
update system set schema_version=7209 where name='rules';
drush updatedb

... then I was able to get back into the config area of my site!

Rules was still broken until I downloaded commerce_coupon-7.x-1.x-dev because the current branch of that module is missing a critical file.

... and now I can access config page AND rules pages.

basvredeling’s picture

Always with the same error Fatal error: Class 'RulesEventHandlerEntityBundle' not found???

why don't you use something like:

<?php
$info
= system_get_info('module', 'rules');
$versions = array('2.4', '2.5');
if (
in_array($info['version'], $versions)) {
// object instantation
}
?>

to escape node.rules.inc line 147

jerdiggity’s picture

The problem stems from the fact that core is not (yet) aware of where it can find certain classes/interfaces, such as RulesEventHandlerEntityBundle (in this case).

The reason core doesn't know where it can find these classes/interfaces is because it's depending on the registry table of the database to tell it in which file(s) these classes/interfaces exist.

While manual database manipulations are highly discouraged (even for the most experienced developers) at this point it seems like that might be the only option some people have. Further, if any part of this comment is unclear to you, do not attempt this. With that being said:

The following database queries assume

  • Your database does not use prefixes for the table names
  • The location of the directory for the Rules module as installed on your site is sites/all/modules/rules
  • The code that lives inside the directory sites/all/modules/rules is for Rules version 7.x-2.5
  • When you attempt to view your site, you see this message: Fatal error: Class 'RulesEventHandlerEntityBundle' not found

If any part of that made you feel doubtful at all, stop now.

The queries below should be done one at a time, because there's a chance that some of the values already exist in your database and if they do exist, your database will not go any further than the last error it encountered, which means the rest of the queries will not be performed. By doing them one at a time, even if one of them fails ("duplicate entry") you can just move on to the next one until all the entries exist in your database.

If any part of that made you feel doubtful at all, stop now.

Here are the queries that I used to fix the fatal error:

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesActionHandlerBase', 'class', 'sites/all/modules/rules/includes/rules.core.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesActionHandlerInterface', 'interface', 'sites/all/modules/rules/includes/rules.core.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesConditionHandlerBase', 'class', 'sites/all/modules/rules/includes/rules.core.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesConditionHandlerInterface', 'interface', 'sites/all/modules/rules/includes/rules.core.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesDataInputOptionsListInterface', 'interface', 'sites/all/modules/rules/ui/ui.data.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesDataUIBundleEntity', 'class', 'sites/all/modules/rules/ui/ui.data.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesEventDefaultHandler', 'class', 'sites/all/modules/rules/includes/rules.event.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesEventDispatcherInterface', 'interface', 'sites/all/modules/rules/includes/rules.event.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesEventDispatcherTestCase', 'class', 'sites/all/modules/rules/tests/rules.test', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesEventHandlerBase', 'class', 'sites/all/modules/rules/includes/rules.event.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesEventHandlerEntityBundle', 'class', 'sites/all/modules/rules/includes/rules.event.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesEventHandlerInterface', 'interface', 'sites/all/modules/rules/includes/rules.event.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesNodeConditionBase', 'class', 'sites/all/modules/rules/modules/node.eval.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesNodeConditionPromoted', 'class', 'sites/all/modules/rules/modules/node.eval.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesNodeConditionPublished', 'class', 'sites/all/modules/rules/modules/node.eval.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesNodeConditionSticky', 'class', 'sites/all/modules/rules/modules/node.eval.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesNodeConditionType', 'class', 'sites/all/modules/rules/modules/node.eval.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesPluginHandlerBase', 'class', 'sites/all/modules/rules/includes/rules.core.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesPluginHandlerInterface', 'interface', 'sites/all/modules/rules/includes/rules.core.inc', 'rules', 20);

INSERT INTO `registry` (`name`, `type`, `filename`, `module`, `weight`) VALUES ('RulesUICategory', 'class', 'sites/all/modules/rules/ui/ui.core.inc', 'rules', 20);

girishmuraly’s picture

I am a maintainer of a distro profile with many contrib modules, one of which is Rules. There are more than a dozen live sites using this distro. I wanted to upgrade Rules along with a few other modules and release a new distro version which could be used by these sites. The sites get the distro by issuing a 'drush make mydistro.make'. So we do not have the luxury of injecting manual sql/workarounds between the updates. Therefore this and issue #2094879: Column owner not created in rules_config on update 2.3 to 2.5 have been both affecting Rules upgrade and hence I had to downgrade to 2.3 version for the distro. I hope this module will be able to fix the issues within the module itself without having to do manual workarounds. Cheers.

absoludo’s picture

This comment on another thread worked for me for updating without disabling rules.

reddeer’s picture

New to Drupal using a distro with Acquia on a local Windows installation and on step 1: enable Chaos tools, got:

Fatal error: Class 'RulesEventHandlerEntityBundle' not found in ... on line 147

Have not installed drush yet and #113 looks like it might not help as I received the error with http://mysite.
localhost:8082/#overlay=admin/modules link after having only just created the database and added a few modules.

Please advise first time user (so close, yet so far) whether to try #113, install drush and try another post instruction, try to roll back to previous Drupal version, or sit tight and wait for a new distro. Happy to test a patch too.

steinmb’s picture

Everyone seeing this, make sure you are using the very very latest version of Drush. NO, not the latest version bundled with your favorite Linux distro or packages built on other places. The changes that address this made it into Drush 4 weeks ago - https://github.com/drush-ops/drush Retest with a git clone xxx.

JamesOakley’s picture

That may be the case.

But until that patch makes it into the majority of Drush installations, it's still critical to have a Rules release that white-screens a site with older versions of Drush.

alanpeart’s picture

...and I know this is redundant, but the WSOD is also affecting users who have never touched drush for their site, like me.

girishmuraly’s picture

+1 for finding a non drush dependent solution

fago’s picture

Status:Active» Fixed

Guys - this issue is about the upgrade problems related to "RulesEventHandlerEntityBundle." If that's not the issue you are experiencing, well then nots your issue. Post to another one (maybe #2094879: Column owner not created in rules_config on update 2.3 to 2.5), or open a new one if you are really running into a new problem.

If you followed instructions (see issue summary) and you are still experiencing problems, please post details. A "it does not work" does not help anyone. Read the issue summary before posting, and if troubles persist provide information on how the instructions did not work.

As I've not seen any comments showing that the instructions still have troubles, I keep calling this fixed.

alanpeart’s picture

I think this extends the definition of "fixed" quite far beyond where most people would agree it should be. Sorry that I can't contribute in any better way (e.g. working code) but I was hoping to stay abreast of developments, and a fix, on this thread. If it's going to be closed, can I suggest that a single thread be opened to deal with the general "Rules upgrade breaks sites" issue?

fago’s picture

I think this extends the definition of "fixed" quite far beyond where most people would agree it should be.

If no one can provide details on any problems with the outlined solution, I don't see what I should do about that, nor do I see why I should care if people don't care to provide any details.

If it's going to be closed, can I suggest that a single thread be opened to deal with the general "Rules upgrade breaks sites" issue?

I'm fine with re-opening this issue when people can provide details what the problems with the solution are. But with the comments so far I cannot even tell whether people have read the suggestions. But please go ahead and open a general "Rules upgrade breaks sites" support issue if you think that helps!

But until that patch makes it into the majority of Drush installations, it's still critical to have a Rules release that white-screens a site with older versions of Drush.

That should be already the case for a straight 2.3 - 2.5 upgrade - from a working 2.3. If not please report yours steps and errors you got.

jooblay.me’s picture

Agree with fago we are not getting this error any more. Big thanks fago for your huge contribution to drupal:)

Ryan Weal’s picture

Agreed with #140! Thanks for all your work on this module @fago. It is a really critical component for my sites.

fago’s picture

You are welcome - thanks for using it and sharing your experiences!

fago’s picture

Issue summary:View changes

added non-drush updates

jooblay.me’s picture

We maybe able to close this issue? Rules is one of the greatest modules ever!

tuccio’s picture

Hello sorry for resuming this thread, but I experienced this issue and then re-downloaded the 2.3 version and tried drush dl rules / drush updb, but then I receive the following and a wsod, so I wonder if there is a relation to the present issue:

Do you wish to run all pending updates? (y/n): y
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to undefined function drush_get_user_id() in .../drush/includes/batch.inc, line 72

PS I was able to perform the update from the admin menu, so probably my drush issue is unrelated.

alanpeart’s picture

After downloading 2.6 and running manual update I did not experience any more problems. Thanks fago.

Nodin’s picture

This is still a problem, I just ran drush to update rules and now my site is white screened. Nothing I have tried so far from the suggestions above will bring it back. I am running Drush 6.

Status:Fixed» Closed (fixed)

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

vparfaniuc’s picture

since the error is the Fatal one drush will not run. The solution which worked for me was to disable the Rules and Rules UI module first (because the whole site is down and drush is not working I had to disable it manually in the DB (system table). Empty all the cache related table in the DB so you can get drush back to work, then run drush dl rules and drush updatedb.
I worked for me just fine.

hansrossel’s picture

In my case the APC cache was locking the error, so restarting the Apache server in between the clearing of cache and rebuilding the registry worked.

decibel.places’s picture

Title:7.x-2.4/2.5 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found"» 7.x-2.4/2.5/2.6 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found"
Version:7.x-2.5» 7.x-2.6
Issue summary:View changes

This is still an issue upgrading from 7.x-2.3 to 7.x-2.6

decibel.places’s picture

I had this error upgrading from rules 7.x-2.3 to 2.4 and figured the next release should fix the upgrade path issue.

By now, two releases behind, I decided to sort out the upgrade.

It's not as simple as disabling the module, clearing cache, downloading the new code, and enabling the new version; drush complained about the table(s) already existing, and choked itself to death.

drush en rules -y
WD php: DatabaseSchemaObjectExistsException: Table rules_config      [error]
already exists. in DatabaseSchema->createTable() (line 657 of
/var/www/xxx/includes/database/schema.inc).
Cannot modify header information - headers already sent by (output   [warning]
started at /usr/share/php/drush/includes/output.inc:38)
bootstrap.inc:1216
DatabaseSchemaObjectExistsException: Table <em class="placeholder">rules_config</em> already exists. in DatabaseSchema->createTable() (line 657 of /var/www/xxx/includes/database/schema.inc).
Drush command terminated abnormally due to an unrecoverable error.   [error]

Even when I disabled AND uninstalled the module(s), the rules tables remained in the database.

Here is how I fixed it:

  1. Export the rules_config table to stash the configured rules
  2. Disable rules, rules_admin (in case you can't find Rules UI, it's machine name is rules_admin)
  3. Uninstall rules_admin, rules
  4. Delete the rules_* tables AND cache_rules table
  5. Download the new version of rules (for good measure, delete the old version of the module code first)
  6. Enable the new version of the rules and rules_admin modules
  7. Import the stashed rules with the rules_config.sql that was stashed
decibel.places’s picture

re #133 Posted by steinmb on October 25, 2013

The changes that address this made it into Drush 4 weeks ago - https://github.com/drush-ops/drush Retest with a git clone xxx

I just checked my drush version dates to 10/19/2013 so should be within the window mentioned- I have since upgraded anyway.

My main problem was the errors about the existing tables, thrown by Drupal core includes/database/schema.inc (yes, I'm using Drupal 7.24)

RaulMuroc’s picture

Agree to #150, upgrading from 2.3 to 2.6 breaks with the same error. And I have uploaded manually, not through Drush.

llepere’s picture

As with #150 and #153 I also got this error when updating from 2.3 to 2.6. I first encountered the error trying to update with drush. After rolling back, I tried using the solution for drush presented in the summary here. After rolling back again, I updated manually by just replacing the old rules files with the new ones. I got the error in all three cases.

I then followed the steps in #151 and was eventually successful with the following modifications.

I didn't need to "Delete the rules_* tables AND cache_rules table". When I looked for the tables in PHPMyAdmin, they were already gone after uninstalling.

I was not able to import the rules using the backed up rules_config table. The import using PHPMyAdmin was successful but I got this error when viewing the status report (and some other admin pages):

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'base.owner' in 'field list': SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS status, base.dirty AS dirty, base.module AS module, base.owner AS owner, base.access_exposed AS access_exposed, base.data AS data FROM {rules_config} base WHERE (base.status IN (:db_condition_placeholder_0, :db_condition_placeholder_1, :db_condition_placeholder_2)) ; Array ( [:db_condition_placeholder_0] => 3 [:db_condition_placeholder_1] => 2 [:db_condition_placeholder_2] => 6 ) in EntityAPIController->query() (line 187 of /xxx/xxx/public_html/sites/all/modules/entity/includes/entity.controller.inc).

I rolled back one more time and followed these steps (using the admin interface, not drush):

  1. Disable Rules UI & Rules
  2. Uninstall Rules UI & Rules
  3. Delete the old rules folder from /sites/all/modules/
  4. Copy the new rules folder to /sites/all/modules/
  5. Enable the new version of Rules & Rules UI
  6. Export rules from production site and import to dev site one by one
greatmatter’s picture

#129 was perfect--thank you.

I ran it line by line, ignoring the "duplicate" errors.

Lifesaver!

dunwich42’s picture

Ahh, finally.
#129 worked, keeping in mind that my rules are in a different location because my install was from a profile.
Then I just had to set the settings.php flag for doing an update, and run the updates.

Thanks to all those that went before...

RaulMuroc’s picture

And how is this supposed to be solved if #129 is for advanced users? I mean, I could solve following that step (thank you for that) but what if there comes a non-experienced Drupal user? Drupal should be available for everybody (also update of modules without worrying to modify code or DB manually).

I would not close this issue until it is fixed just updating module or at least I would open new issue for that.

LizD’s picture

After upgrading from 7.x-2.5 to 7.x-2.6 I egt the following error:

Error message
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table '[site].cache_rules' doesn't exist: TRUNCATE {cache_rules} ; Array ( ) in cache_clear_all() (line 163 of /var/www/vhosts/[site]/httpdocs/drupal/includes/cache.inc).

To be safe, before running drush pm-update I ran drush dl rules and drush updatedb. Everything seemed to go fine and rules 2.6 was installed. Then I ran drush pm-update to update the rest of the site and got the error.

RaulMuroc’s picture

Status:Closed (fixed)» Active

This is not fixed. People continue experiencing errors and besides is too hard and lot of manually modifying code for no-experienced users.

alanpeart’s picture

Raul - I sympathise but as far as I can see nothing further is going to be done and this will get marked as fixed again by someone. My solution has simply been not to upgrade Rules on my sites. Version 7.x.2.3 is the most recent one that doesn't cause this issue (in case anyone else Googling this problem comes across this thread).

torgosPizza’s picture

The error presented in #158 is not related at all to the error discussed in this issue.

If your cache_rules table doesn't exist, you probably need to run (or re-run) the update hooks for the Rules module, as cache_rules was updated in update 7200.

LizD’s picture

I have reinstalled and rerun updatedb (and update.php) several times with the same result. I can't rollback to 7.23 because of this error. I don't know whether this is an entirely different issue or not as although it is a different error, it only happened after installing rules 2.5 and attempting to update. It, too prevents me from updating the site so it seems related to me. I'm not a php programmer. I'm a themer and site builder and maintainer. If I go find the schema for the rules_cache table and add it manually to the database will I harm anything?

dave bruns’s picture

With drush 6.0-dev and rules 2.3 > rules 2.6

I ran into this problem today running a bunch of updates. Drush up failed several times (without updating anything - one of the great things about drush) and when I did a manual update of rules, I got a wsod before I could run database updates.

Finally I did:

drush up --lock=rules

Then (after confirming that other updates looked good):

drush dl rules // ok
drush updatedb // failed

Since drush updatedb failed, I visited update.php directly and ran pending updates. The site seems OK now with no errors.

Edit: I followed the same process with a 2nd site today: I ran all updates excluding rules. Then, I updated rules to 2.6, and visited update.php immediately after to run database updates. So, basically, I used drush to update everything but rules. I didn't have any trouble. Make sure you run a backup of the database first in case things don't work out.

MXT’s picture

Guys, at this point, reading all of these bad and different experiences, some of these happened in spite of all the "official" recommended precautions in the opening post, I'm really worried on my upcoming rules update from 7.x-2.3 to 7.x-2.6 in my website...

You guys are all experienced Drupal developer, but what I'll can do if something will going wrong!??!? I don't know if my skills are enough to eventually find a solution to adjust everything... (Fortunately I'm able to restore a db backup, but In this case I will never be allowed to upgrade rules to latest version...)

Just my 2 cents...

havran’s picture

Thanx to #42. Fix for me - i simple disable APC (and restart php-fpm (apache for people with mod_php)), open page (all works now) and then i enable apc back. Site is now work without problem.

Seems APC cached code go bad some way...

j.johnson.bbt’s picture

Getting the same error.

I used Shell and ran:

drush dl kickstart
drush updatedb

Then I got back:

Fatal error: Class 'RulesEventHandlerEntityBundle' not found in public_html/profiles/commerce_kickstart/modules/contrib/rules/modules/node.rules.inc on line 147
Drush command terminated abnormally due to an unrecoverable error.   [error]

I'm using Drupal 7 Commerce Kickstart Dist.

I get the same error every I try to update rules. I also get the same error when I run drush cc. I also get the same error when I run update.php.

I've tried with the latest drush 6.x as of 2/1/2014 and the latest drush 7 master version. Any help would be greatly appreciated! :-)

alanpeart’s picture

Just an update for those affected by this or similar problems. The old version of Rules that I had been relying on (7.x.2.3) finally went out of sync with Drupal core and so I had to upgrade. I chose the latest dev version at the time of writing, crossed my fingers, and updated a local development site. Apart from a few PHP warnings, everything went fine - no WSOD, no fatal errors.

RaulMuroc’s picture

If people is forced to move to latest Rules we really should try this works always and 100%.

jerdiggity’s picture

StatusFileSize
new7.81 KB

NOTE: while several members claim to have had success in using the methods below, please be advised that said methods have not been tested against any version of Rules other than 7.24, 7.25, and/or 7.26.

This issue is obviously still an issue to at least some people, so I wrote a php script that essentially performs the same tasks as found in one of my previous comments... I've tested it and it works for me, but if you try it and it works for you please add an additional comment stating so (so that we can hopefully close this issue and fix as many problems as possible). I'm attaching a file with the same code as below so if you want to download that file and rename it to fix_rules.php then that should work too.

<?php
/**
 * @file
 *   Attempts to fix issues with the latest release of Rules, for those
 *   who are receiving errors due to missing registry values.
 *
 * @usage
 *  - Create a file named fix_rules.php and place it in your Drupal root directory
 *    - So if your site's URL is http://www.example.com, you should be able to view
 *      the new file you created by visiting http://www.example.com/fix_rules.php
 *  - Copy this entire text and paste it into your new fix_rules.php file
 *  - Save your new fix_rules.php file
 *  - Visit http://www.example.com/fix_rules.php from your web browser
 *  - If you see 3 rows, and if all the values in the bottom row say "Fixed",
 *    try your site again.
 *  - If your site is now working, delete the fix_rules.php file you just created and then
 *    proceed with updating your site at http://www.example.com/update.php
 *
 * @notes
 *   Although it should be obvious, neither myself nor drupal.org nor anyone else but
 *   you personally may be held accountable for using this code.
 */

// Load Drupal
if (!defined('DRUPAL_ROOT')) {
 
define('DRUPAL_ROOT', getcwd());
}
chdir(DRUPAL_ROOT);
require(
'./includes/bootstrap.inc');
// We can't bootstrap to DRUPAL_BOOTSTRAP_FULL or everything will still be broken
drupal_bootstrap(DRUPAL_BOOTSTRAP_DATABASE);

// Values for display text
$output = array();

// Make sure the Rules module exists, and if it does, fetch its location (since we're
// not fully bootstrapped, drupal_get_path('module', 'rules') won't work)
$path_to_rules_query = db_query("SELECT s.filename FROM {system} s WHERE s.name = 'rules' AND s.type = 'module'")->fetchField();
if (!
$path_to_rules_query) {
  print
'Rules module not found in the database.';
  exit();
}

// Strip the filename off the end so we have the actual path
$path_to_rules = str_replace('/rules.module', '', $path_to_rules_query);

// Actual display text
$disp = '<table><tbody>';

// Values that should be there but might not be
$rules_info = array(
 
'RulesActionHandlerBase' => array('name' => 'RulesActionHandlerBase', 'type' => 'class', 'filename' => $path_to_rules . '/includes/rules.core.inc'),
 
'RulesActionHandlerInterface' => array('name' => 'RulesActionHandlerInterface', 'type' => 'interface', 'filename' => $path_to_rules . '/includes/rules.core.inc'),
 
'RulesConditionHandlerBase' => array('name' => 'RulesConditionHandlerBase', 'type' => 'class', 'filename' => $path_to_rules . '/includes/rules.core.inc'),
 
'RulesConditionHandlerInterface' => array('name' => 'RulesConditionHandlerInterface', 'type' => 'interface', 'filename' => $path_to_rules . '/includes/rules.core.inc'),
 
'RulesDataInputOptionsListInterface' => array('name' => 'RulesDataInputOptionsListInterface', 'type' => 'interface', 'filename' => $path_to_rules . '/ui/ui.data.inc'),
 
'RulesDataUIBundleEntity' => array('name' => 'RulesDataUIBundleEntity', 'type' => 'class', 'filename' => $path_to_rules . '/ui/ui.data.inc'),
 
'RulesEventDefaultHandler' => array('name' => 'RulesEventDefaultHandler', 'type' => 'class', 'filename' => $path_to_rules . '/includes/rules.event.inc'),
 
'RulesEventDispatcherInterface' => array('name' => 'RulesEventDispatcherInterface', 'type' => 'interface', 'filename' => $path_to_rules . '/includes/rules.event.inc'),
 
'RulesEventDispatcherTestCase' => array('name' => 'RulesEventDispatcherTestCase', 'type' => 'class', 'filename' => $path_to_rules . '/tests/rules.test'),
 
'RulesEventHandlerBase' => array('name' => 'RulesEventHandlerBase', 'type' => 'class', 'filename' => $path_to_rules . '/includes/rules.event.inc'),
 
'RulesEventHandlerEntityBundle' => array('name' => 'RulesEventHandlerEntityBundle', 'type' => 'class', 'filename' => $path_to_rules . '/includes/rules.event.inc'),
 
'RulesEventHandlerInterface' => array('name' => 'RulesEventHandlerInterface', 'type' => 'interface', 'filename' => $path_to_rules . '/includes/rules.event.inc'),
 
'RulesNodeConditionBase' => array('name' => 'RulesNodeConditionBase', 'type' => 'class', 'filename' => $path_to_rules . '/modules/node.eval.inc'),
 
'RulesNodeConditionPromoted' => array('name' => 'RulesNodeConditionPromoted', 'type' => 'class', 'filename' => $path_to_rules . '/modules/node.eval.inc'),
 
'RulesNodeConditionPublished' => array('name' => 'RulesNodeConditionPublished', 'type' => 'class', 'filename' => $path_to_rules . '/modules/node.eval.inc'),
 
'RulesNodeConditionSticky' => array('name' => 'RulesNodeConditionSticky', 'type' => 'class', 'filename' => $path_to_rules . '/modules/node.eval.inc'),
 
'RulesNodeConditionType' => array('name' => 'RulesNodeConditionType', 'type' => 'class', 'filename' => $path_to_rules . '/modules/node.eval.inc'),
 
'RulesPluginHandlerBase' => array('name' => 'RulesPluginHandlerBase', 'type' => 'class', 'filename' => $path_to_rules . '/includes/rules.core.inc'),
 
'RulesPluginHandlerInterface' => array('name' => 'RulesPluginHandlerInterface', 'type' => 'interface', 'filename' => $path_to_rules . '/includes/rules.core.inc'),
 
'RulesUICategory' => array('name' => 'RulesUICategory', 'type' => 'class', 'filename' => $path_to_rules . '/ui/ui.core.inc'),
);

// Just the names of the missing classes / interfaces
$values_needed = array_keys($rules_info);

// Find out which values currently do exist in the database
$values_existing = db_query("SELECT r.name FROM {registry} r WHERE r.module = 'rules'")->fetchAll();

// Save values from $values_existing for later comparison
if ($values_existing) {
  foreach (
$values_existing as $value_existing) {
   
$values_compare[] = $value_existing->name;
  }
}

// Find the difference between what we need and what already exists
$values_diff = array_diff($values_needed, $values_compare);

// Assign info from $rules_info to $values_insert if we have a match
$values_insert = array();
if (!empty(
$values_diff)) {
  foreach (
$values_needed as $value_needed) {
    if (
in_array($value_needed, $values_diff)) {
     
$values_insert[] = $rules_info[$value_needed];
     
$output[0][] = $rules_info["{$value_needed}"];
    }
  }
}

// First row of output
$disp .= '<tr>';
for (
$i = 0; $i < count($output[0]); $i++) {
 
$disp .= '<td>' . $output[0][$i]['name'] . '</td>';
}
$disp .= '</tr>';

// Assign values to compare against later on to see if any changes were made, and then
// make the changes
$values_verify = array();
if (!empty(
$values_insert)) {
  foreach (
$values_insert as $value_insert) {
   
$values_verify[] = $value_insert['name'];
   
$output[1][] = 'Missing';
   
db_insert('registry')
      ->
fields(array(
       
'name' => $value_insert['name'],
       
'type' => $value_insert['type'],
       
'filename' => $value_insert['filename'],
       
'module' => 'rules',
       
'weight' => 20,
      ))
    ->
execute();
  }
}

// Second row of output
$disp .= '<tr>';
for (
$j = 0; $j < count($output[1]); $j++) {
 
$disp .= '<td>' . $output[1][$j] . '</td>';
}
$disp .= '</tr>';

// Perform the query again to see if our values were inserted correctly
$values_existing_fetch_new = db_query("SELECT r.name FROM {registry} r WHERE r.module = 'rules'")->fetchAll();
$values_existing_new = array();
if (
$values_existing_fetch_new && !empty($values_existing_fetch_new)) {
  foreach (
$values_existing_fetch_new as $value_existing_fetch_new) {
   
$values_existing_new[] = $value_existing_fetch_new->name;
  }
}

// If everything went well, create the third row of the output
if (!empty($values_existing_new) && !empty($values_verify)) {
  foreach (
$values_verify as $value_verify) {
    if (
in_array($value_verify, $values_existing_new)) {
     
$output[2][] = 'Fixed';
    }
  }
}
$disp .= '<tr>';
for (
$k = 0; $k < count($output[2]); $k++) {
 
$disp .= '<td>' . $output[2][$k] . '</td>';
}
$disp .= '</tr>';

// Last parts of the output text
$disp .= '</tbody></table>';
$disp .= '<h4 style="text-align: center;">IF EACH COLUMN SAYS <em>FIXED</em> IN THE BOTTOM ROW, PLEASE TRY YOUR SITE AGAIN AND IF IT IS WORKING NOW, DELETE THIS FILE FROM YOUR SERVER.</h4>';

print
$disp;
?>
niki v’s picture

I would have tried the above if it had been posted 24 hours earlier ;)

For Commerce sites, manual updating of only the Rules module from 7.23 to 7.26 wasn't a problem although when I tried updating a site built with a Commerce Kickstart profile, I got the WSOD with the RulesEventHandlerEntityBundle error.

Since rolling back wasn't an option, I used Registry Rebuild https://drupal.org/project/registry_rebuild which then created the PDO-error described here: https://drupal.org/node/2094879. Manually creating the 'owner' table in rules_config in the database got the site back up so that I could run my updates. All well after that

dandaman’s picture

I'll just throw in my two cents of what I just experienced. I don't think it's the same issue as above, but you get many of the same errors so it might help someone get to the bottom of their issue.

I was running Rules 7.x-2.2 on my site before upgrades. But when I updated Rules to 7.x-2.6, it would be updated and then Rules wouldn't do any database updates. After that, you get the class not found error and then on other pages on the site get a nasty database error.

To investigate this, I looked at my system table. To my surprise, for some reason the schema_version column of many modules, including Rules, was -1. It seems that if it's -1 then Drupal's not going to do any updates. (I don't know how it got set to -1.)

Once I set the schema_version to 7209 (the last update included in 2.2), then running Drupal's DB update worked great and the problem was solved.

Hope this helps!

jggarley’s picture

It Fixed my problem 100%

jyee’s picture

#171 also resolved my issue (updating from 7.x-2.3 to 7.x-2.6, last update was 7209).

curiosity26’s picture

subscribing. Same issue.

caseyb’s picture

The fix_rules script at #169 worked for me. Very quick and easy to implement.

Many thanks jerdiggity!!

CKIDOW’s picture

#171 fixed it! Thx a lot!

thomsonj’s picture

I had to install the 7.x-2.x-dev instance, then applied the fix from #169 and I am back in business! Thank you very much!!

RaulMuroc’s picture

Ok, is looking that the solution is by using latest -dev and apply either solution from #169 or #171. So is looking we have to develop a patch using both ideas, apply to -dev, review it and commit if solves the problem!

Going on nice way!

nostradamus1935’s picture

I had a similar problem related to the class RulesTokenEvaluator, with an error message like Class 'RulesTokenEvaluator' not found...

Comment #171 did the job : I just changed the schema_version to 7209 and run the update.php script. I started from version 2.6, no update involved. It just stopped working at some point.

echataig’s picture

#169 did it. Thank you so much !

golchi’s picture

I have used the dev version and applied #169. Great job thanks !

SocialNicheGuru’s picture

has anyone tried http://drupal.org/project/registry_rebuild

I would try 'drush rr --fire-bazooka'
It blows away all registry items and allows for a rebuild. just a thought.

Glenys’s picture

The fix_rules script at #169 worked for me also. Absolutely easy to implement.

This was a life saver for me, thanks jerdiggity!!

RaulMuroc’s picture

The script in #169 is not printing any 3 rows below saying FIXED :S so what does it mean? What should I do next?

about #171 it is said to set 7129 to column schema_version... but just to "rules" row or to every row of system table with -1 value?

dandaman’s picture

RaulMuroc,

7129 is a number that represents what database schema my Rules module had been updated to, so it does only apply to the Rules module, not all modules with a -1 value.

If you look at the version of Rules that you are updating from, in the rules.install file, there are a bunch of rules_update_N() functions, where N is a number. It may be possible to guess that your database schema had been updated in the past to include all of these, so set the number to the latest one. (Well, this may not be a safe assumption, it really depends on when the "-1" was set.) You can do the same thing for the other modules included in the rules package.

Hope that helps clear things up!

RaulMuroc’s picture

@dandaman! Thank you very much :-)!

Basically I applied both #169 and #171 to the latest stable version (7.x-2.7) and now it works like a charm!

See you!

techman’s picture

I have the same issue and I want to be sure I fix it correctly rather than make my situation worse.

Tonight is the first time I've updated my Drupal site since August of last year. I reviewed all the updates available for all of my modules
and proceeded with the update from the Configuration panel. I took my site offline, did the updates and Drupal showed me that all the updates
were successfully performed. When I clicked to bring my site back online (from maintenance mode) my Drupal site was broken.

To find the error I added the following code to index.php to show me the specific error that is crashing my site.
error_reporting(E_ALL);
ini_set('display_errors', 1);

Accessing my drupal site then shows me the following error message in my browser
Fatal error: Class 'RulesEventHandlerEntityBundle' not found in /home/domain/public_html/sites/all/modules/rules/modules/node.rules.inc on line 147

I've read the summary of this fix. and I've read alot of comments that appear to have different approaches since the issue appeared.
At this point in time, Is a fix that simple? Just go into Drush
add execute these concurrent statements? Or is there something else I need to do first or after.
drush dl rules
drush updatedb

What is now the best approach for fixing this issue.

aaronbauman’s picture

Version:7.x-2.6» 7.x-2.x-dev

This issue persists to 7.x-2.x-dev
updating to 7.x-2.7 does not resolve
updating to 7.x-2.7+5-dev does not resolve

stuck on schema version 7210 when trying to run db update

Cracu’s picture

StatusFileSize
new739 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch fix_errors_on_update-2090511-189.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I was able to avoid errors and notices by including /includes/rules.event.inc in rules.module, similar to /modules/events.inc

The way the file is included, via .info file, is causing troubles before updates.
I used this patch for 7.x-2.7.

darkodev’s picture

+1 for #189

Thanks much for the patch, Cracu!

Cracu’s picture

Just a quick notice for those that are using my patch, posted at #189:
If you are running multiple updates (together with rules updates) in the same update session, make sure that updates that are processing entities have a dependency on rules_update_7211, otherwise some mysql exceptions will be thrown, because there is a new column to be added in rules_config table. That column is added in update rules_update_7211().

That can be made easily by implementing hook_update_dependencies() in some custom module.

e.g.

/**
* Implements hook_update_dependencies().
*
* Force to run rules_update_7211() before
* another_custom_module_update_7002().
*/
function custom_module_update_dependencies() {
  $dependencies['another_custom_module'][7002] = array(
     'rules' => 7211,
  );
  return $dependencies;
}

This is needed only in the case you have some entities processed in update hooks.
By simply adding that dependency I observed that rules updates were executed first, no matter the other weights of the modules. Which is exactly what we need.

agerson’s picture

+1 for #189

toiletfinder.com’s picture

+1 for #189

muschpusch’s picture

#30 and #189 are not fixing this problem updating from rules 2.3 to 2.7

joelstein’s picture

#189 made it possible for me to upgrade from Rules 7.x-2.0 to 7.x-2.7. Thanks!

marcelovani’s picture

Status:Active» Reviewed & tested by the community

#189 fixes the problem, I think this patch should be committed as soon as possible.

btopro’s picture

Confirming 189 fixes as well (wow I was able to install Rules again, weird!)

johnv’s picture

#189 includes a file in the rules.module files. Meaning: always. It should be sufficient to add this line in the install-file.

fago’s picture

Status:Reviewed & tested by the community» Needs work

Yeah, I'm not so happy with having the file included always when this isn't necessary else. Let's do it from the install file and comment why this is needed (looks like it still is in some scenarious :-()

fago’s picture

Status:Needs work» Postponed (maintainer needs more info)

Rules 2.8 received some improvements which make it not run when drupal is not boostrapped. Please, verify the issue is there with 2.8 or later as well.

fonant’s picture

Unfortunately the changes in Rules 2.8 break Drupal Commerce fatally... #2403851: Drupal Commerce is broken with Rules 7.x-2.8

marcelovani’s picture

Broken.
It works with the patch.

ybabel’s picture

Using Rules 7.2.8
mysteriously it stopped to work all of a sudden.

I tried #169, #171, #189
drush dl rules
drush updatedb
reinstall from scratch

and many many combinations.
nothing works.
drush updatedb corrected everything once, but I was not able to create rules (empty page in the admin ui).

Only thing that worked : install the dev version (updatedb 7214)

joostpluijmers’s picture

Without looking on Drupal.org I wrote a similar patch to #189. I confirm that this also fixes the issue of the missing dependency. Please commit this!

cllamas’s picture

Same issue here, Impossible to use drush because of the error

PHP Fatal error: Class 'RulesEventHandlerEntityBundle' not found in ...../profiles/commons/modules/contrib/rules/modules/node.rules.inc on line 147

Any solution?

hbiggs’s picture

Not sure if this has been mentioned already.
I've found the quickest solution is to update your settings.php file and set $update_free_access = TRUE;
Then run update.php as anonymous user
Update your settings.php file and set $update_free_access = FALSE;

agileadam’s picture

Thanks hbiggs, this worked perfectly.

webdrips’s picture

Note for #206, entity must be enabled for the last db update to take. If you're like me, you tried a bunch of stuff to get this working, including disabling/removing entity.

likewhoa’s picture

#189 worked but got this during the drush updb

$ drush updb
Rules 7210 Deletes the unused rules_empty_sets variable.
Rules 7211 Creates the "owner" column.
Rules 7212 Make sure registry gets rebuilt to avoid upgrade troubles.
Rules 7213 Recover the "owner" property for broken configurations.
Rules 7214 Switch out the rules_event_whitelist variable for a cache equivalent.
Rules_scheduler 7203 Add a database column for specifying a queue item handler.
Rules_scheduler 7204 Rename rules_scheduler.state into rules_scheduler.data.
Do you wish to run all pending updates? (y/n): y
call_user_func_array() expects parameter 1 to be a valid callback, function 'rules_condition_node_is_of_type_assertions' not found or invalid function name faces.inc:123 [warning]
call_user_func_array() expects parameter 1 to be a valid callback, function 'rules_condition_node_is_of_type_assertions' not found or invalid function name faces.inc:123 [warning]
call_user_func_array() expects parameter 1 to be a valid callback, function 'rules_condition_node_is_of_type_assertions' not found or invalid function name faces.inc:123 [warning]
call_user_func_array() expects parameter 1 to be a valid callback, function 'rules_condition_node_is_of_type_assertions' not found or invalid function name faces.inc:123 [warning]
call_user_func_array() expects parameter 1 to be a valid callback, function 'rules_condition_node_is_of_type_assertions' not found or invalid function name faces.inc:123 [warning]
call_user_func_array() expects parameter 1 to be a valid callback, function 'rules_condition_node_is_of_type_assertions' not found or invalid function name faces.inc:123 [warning]
Performed update: rules_update_7210 [ok]
Performed update: rules_update_7211 [ok]
Performed update: rules_update_7212 [ok]
Performed update: rules_scheduler_update_7203 [ok]
Performed update: rules_update_7213 [ok]
Performed update: rules_scheduler_update_7204 [ok]
Performed update: rules_update_7214 [ok]
'all' cache was cleared. [success]
Finished performing updates. [ok]

Status:Postponed (maintainer needs more info)» Needs review

Status:Needs review» Needs work

The last submitted patch, 189: fix_errors_on_update-2090511-189.patch, failed testing.

likewhoa’s picture

Status:Needs work» Needs review
StatusFileSize
new396 bytes
FAILED: [[SimpleTest]]: [MySQL] 353 pass(es), 2 fail(s), and 0 exception(s).
[ View ]

re-rolling patch

Status:Needs review» Needs work

The last submitted patch, 212: fix_errors_on_update-2090511-212.patch, failed testing.

likewhoa’s picture

Status:Needs work» Needs review
StatusFileSize
new779 bytes
PASSED: [[SimpleTest]]: [MySQL] 355 pass(es).
[ View ]

Looks like we actually introduced one bug by replacing the "modules/events.inc" with "includes/rules.event.inc" as this method actually prevents any rules from working, so instead of always including this rules.event.inc we just include it for rules version <2.4.

As #199 mentioned about putting this in .install file, I tried but that didn't work out as expected. I hope this actually passes testing as I suspect the previous ones failed because "modules/events.inc" was missing.

marcelovani’s picture

Not sure it's the best approach to have this query running all the time.
I bet it would be still be better just to do the include. After all the included file contains only classes. Why don't we put the include there we instantiate the class, then?

likewhoa’s picture

Title:7.x-2.4/2.5/2.6 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found"» <7.x-2.4 breaks site with "Fatal error: Class 'RulesEventHandlerEntityBundle' not found"
Status:Needs review» Needs work

@marcelovani I agree this is not the best approach but out the box >=2.4 works without the propose include and the reason we need it included is for <2.4. Until someone comes out with a better approach that will allow <2.4 to upgrade then the include is needed and I was not able to get this to work inside the .install because the missing class is called before hand.