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.
Comment | File | Size | Author |
---|---|---|---|
#224 | fix_errors_on_update-2090511-224.patch | 529 bytes | cspiker |
#214 | fix_errors_on_update-2090511-214.patch | 779 bytes | likewhoa |
#169 | fix_rules.txt | 7.81 KB | jerdiggity |
#100 | rules.png | 39.01 KB | astutonet |
#83 | drupal error 28-9-2013.jpg | 82.38 KB | jmussi |
Comments
Comment #1
lennart.maschmeyer CreditAttribution: lennart.maschmeyer commentedexactly the same here
Comment #2
GemQueen CreditAttribution: GemQueen commentedexact same issue. I tried rebuilding registry, but finally had to roll back to 2.3 to get my site back up
Comment #3
Jednorozec CreditAttribution: Jednorozec commentedI'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.
Comment #4
DavidoffC CreditAttribution: DavidoffC commentedHad the same issue with several sites with different hosts, rolled back to 7.x-2.3 and everything's fine.
Comment #5
fagoThat'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?
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?
Comment #6
jerdiggity CreditAttribution: jerdiggity commented@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:
admin/reports/updates/update
(no problems)update.php
(still no problems)So for me, Drush was not used (in this particular case). All browser.
EDIT: see this video to see the problem in action.
Comment #7
Arnoldski CreditAttribution: Arnoldski commentedExact same problem here, did update with Drush.
Comment #8
fagoThanks 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?
Comment #9
jerdiggity CreditAttribution: jerdiggity commentedFollow-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.Comment #10
fagoOR - just put the site manually into maintenance mode by putting the following in your settings.php
Comment #11
jerdiggity CreditAttribution: jerdiggity commentedLooks like you beat me to it... See above. ;)
(Yes -- that route works.)
Comment #12
fagoAs 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.
Comment #13
fago@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.
Comment #14
fonant CreditAttribution: fonant commentedDrush fails whether maintenance_mode is 0 or 1, and whether the caches are cleared in advance or not.
Comment #15
z.stolar CreditAttribution: z.stolar commentedIs 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.
Comment #16
REo CreditAttribution: REo commentedSame 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.
Comment #17
fagoTwo questions for the folks having drush issues:
* Does "drush updatedb" solve it?
* Does manually running "update.php" solve it once you had the error?
Comment #18
fonant CreditAttribution: fonant commented* 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.
Comment #19
REo CreditAttribution: REo commentedWell, 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
Comment #20
JamesOakleyDitto 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?
Comment #21
RaulMuroc CreditAttribution: RaulMuroc commentedI 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.
Comment #22
JamesOakleyI 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.
Comment #23
fagoIt 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.
Comment #24
REo CreditAttribution: REo commentedMy test has been done with drush 6.0 (and the error occurred).
Comment #25
haegar der schreckliche CreditAttribution: haegar der schreckliche commentedI triggered the error with drush version 5.9.
Comment #26
fredcy CreditAttribution: fredcy commentedI 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.
Comment #27
olak CreditAttribution: olak commentedsame 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
Comment #28
fonant CreditAttribution: fonant commentedDrush 5.7 here.
Comment #29
z.stolar CreditAttribution: z.stolar commentedIs there any coordination regarding the solution of this problem in IRC/IM somewhere?
Comment #30
StuddMan CreditAttribution: StuddMan commentedRunning Drush 4.5
Ran drush cc all did not work
Ran drush updatedb did not work
Ran drush rr, FIXED!
Comment #31
z.stolar CreditAttribution: z.stolar commented#30 Did not work for me.
Comment #32
chicagomom CreditAttribution: chicagomom commentedDrush 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.
Comment #33
z.stolar CreditAttribution: z.stolar commentedTo bypass the problem in the meantime:
drush up --lock=rules rules-7.x-2.3
drush up --lock=rules
Comment #34
Jednorozec CreditAttribution: Jednorozec commentedI 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.
Comment #35
rkneale CreditAttribution: rkneale commentedAdd 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...
Comment #36
torgosPizzaThe 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.
Comment #37
jerdiggity CreditAttribution: jerdiggity commented@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.
Comment #38
Sam MoorePatch in #37 works for me.
Thank you sir.
Comment #39
nwehner CreditAttribution: nwehner commentedI 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!
Comment #40
roman_pro CreditAttribution: roman_pro commenteddrush rr worked for me.
make sure you have the latest version of registry_rebuild though
Comment #41
c.breschkow CreditAttribution: c.breschkow commentedupdate to latest dev version worked for me
Comment #42
orlitzky CreditAttribution: orlitzky commentedThere'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):
Comment #43
JamesOakleyRe: #41
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.
Comment #44
ben_chad CreditAttribution: ben_chad commentedSubscribing.
Comment #45
dema501 CreditAttribution: dema501 commentedI've updated rules on my env
All works fine!
I did:
Comment #46
FreeFox CreditAttribution: FreeFox commentedIndeed, 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
Comment #47
fagoThanks 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.
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.
Comment #48
FreeFox CreditAttribution: FreeFox commentedEdit: I added the line "If error => drush rr => drush cc again" in my post #46.
Comment #49
ano.nimmus CreditAttribution: ano.nimmus commentedWhile this is being worked on, how do we get out of the failure mode?
I can't get past this now.
Should I delete the module dir manually? Other?
Comment #50
orlitzky CreditAttribution: orlitzky commentedI tested this on a low-traffic site of ours. First, this was failing,
Now, downloading rules-2.4 manually and patching works:
The site seems OK, but I haven't done a ton of testing.
Comment #51
ano.nimmus CreditAttribution: ano.nimmus commentedThat seems to work:
at least as far as the update goes. Haven't done any further testing, yet.
Thanks!
Comment #52
torgosPizzaPatch in #47 worked perfectly for me. (Visited update.php manually, no drush this time.)
Comment #53
nicxvan CreditAttribution: nicxvan commentedI 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
Comment #54
nicxvan CreditAttribution: nicxvan commentedIn 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.
Comment #55
reallyordinary CreditAttribution: reallyordinary commentedI 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.
Comment #56
fagoThanks 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.
Comment #57
JamesOakleyJust 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.
Comment #58
espurnesNow 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.
Comment #59
JamesOakleyDoes 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?
Comment #60
espurnes#57 worked for me. :)
Comment #61
FreeFox CreditAttribution: FreeFox commented#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.
[]#
Comment #62
fonant CreditAttribution: fonant commentedCan 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.
Comment #63
fagoThanks 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!
Comment #64
haegar der schreckliche CreditAttribution: haegar der schreckliche commentedFor me, the update to rules 7.x-2.5 is not working using drush.
I get the same error like #58.
Comment #65
haegar der schreckliche CreditAttribution: haegar der schreckliche commentedSorry
Comment #65.0
haegar der schreckliche CreditAttribution: haegar der schreckliche commentedUpdated issue summary.
Comment #65.1
fagoupdated summary
Comment #65.2
fagoUpdated issue summary.
Comment #66
mikemadison CreditAttribution: mikemadison commentedOn 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.
Comment #67
busla CreditAttribution: busla commentedI´m using Aegir and Rules 2.4 threw the error when creating a platform. This solved it for me:
Comment #68
niki v CreditAttribution: niki v commentedI 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
Comment #69
JamesOakley@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
Comment #70
pimok3000 CreditAttribution: pimok3000 commenteddoing it like described in #57 works!!!
Comment #71
niki v CreditAttribution: niki v commented@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
Comment #72
JamesOakleyPart 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.
Comment #73
NancyDruI guess there is an advantage to not using Drush. I just did update.php manually and the problem went away.
Comment #74
vegantriathleteI 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.
Comment #75
fagoThe issue has been reported to the drush queue and is dealt with over there - the Rules problem is fixed.
Comment #76
steinmb CreditAttribution: steinmb commentedDrush 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?
Comment #77
brunorios1 CreditAttribution: brunorios1 commented@steinmb: https://drupal.org/node/2090511#comment-7877033
Comment #78
auntvanilla CreditAttribution: auntvanilla commentedI'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?
Comment #79
JamesOakley@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.
Comment #80
auntvanilla CreditAttribution: auntvanilla commentedI'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.
Comment #81
alanpeart CreditAttribution: alanpeart commentedManual 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).
Comment #82
alayham CreditAttribution: alayham commentedHad the same issue today, solved like this:
Comment #83
jmussi CreditAttribution: jmussi commentedI'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
Comment #84
fago#83 does not seem to be related to the issue please open a separate one. Thanks.
Comment #85
alanpeart CreditAttribution: alanpeart commentedCurious about the "fixed" status here. What's fixed?
Comment #86
fagoSee #56. If you are not running into the error of the issue summary, please open your own issue instead of re-opening this one.
Comment #87
JamesOakleyWhat'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.
Comment #88
alanpeart CreditAttribution: alanpeart commentedApologies. 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.
Comment #89
jmussi CreditAttribution: jmussi commentedI've opened a new issue relating to my post #83. Thanks and sorry for any confusion.
Comment #90
ardnet CreditAttribution: ardnet commentedWow, 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
Comment #91
nicxvan CreditAttribution: nicxvan commentedardnet the solution is at the very top of the thread.
The following should solve any troubles using drush:
drush dl rules
drush updatedb
Comment #92
alayham CreditAttribution: alayham commentedcan anybody confirm a successful update from 2.3 to 2.5 or the latest dev even with drush rr?
Comment #93
nicxvan CreditAttribution: nicxvan commentedalayaham
I can but you don't need drush rr you need:
drush dl rules
drush updb
Comment #94
NancyDruI 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.
Comment #95
snowmountain CreditAttribution: snowmountain commentedI 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.
Comment #96
snowmountain CreditAttribution: snowmountain commentedMore on #95: My drush version is 5.8
Comment #97
steinmb CreditAttribution: steinmb commented@snowmountain should test this with latest dev. of drush.
Comment #98
Jooblay.net CreditAttribution: Jooblay.net commentedThe 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
Comment #99
zeyfah CreditAttribution: zeyfah commentedHow 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?
Comment #100
astutonetHi
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:
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.
Comment #101
Jooblay.net CreditAttribution: Jooblay.net commentedWe 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. :(
Comment #102
Mehrdad201 CreditAttribution: Mehrdad201 commentedSame 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.
Comment #102.0
Mehrdad201 CreditAttribution: Mehrdad201 commentedUpdated issue summary.
Comment #103
fagoHave 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.
Comment #104
NancyDruYes, I did. This error disappeared after update.php. But other issues showed up, especially in editing some of our rules.
Comment #105
Stephen Ollmanwhen 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.
Comment #106
vegantriathleteI 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 adrush up
which (not surprisingly) resulted in a fatal error. So, I did adrush updb
which did, in fact, run a number of updates. Finally, I once again testeddrush up
which now ran without issue (although there was nothing to update at this time).Thanks for your work and help on this!
Comment #107
Paul B CreditAttribution: Paul B commentedRunning 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.
Comment #108
codesmith1) I needed to update from Rules 7.x-2.3 to 7.x-2.5
2) Using 'drush up' failed with
3) I upgraded to drush 6.1.0 and was able to update Rules with no errors using 'drush up'
Comment #109
Anonymous (not verified) CreditAttribution: Anonymous commentedUgh, 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:
You cannot use entity-1.x-dev at this time.
Comment #110
basvredelingDarn, this is nasty. Running drush updb separately seems to work.
Comment #111
geek-merlinThanks so much for the fix #109. Minor typo with rules version:
EDIT: don't miss the first updatedb.
Comment #112
NancyDruAnd for people who don't Drush?
Comment #113
Jooblay.net CreditAttribution: Jooblay.net commentedThe 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:(
Comment #114
NancyDruWell, 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.
Comment #115
Anonymous (not verified) CreditAttribution: Anonymous commentedUpdating 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.
Comment #116
johnvFWIW, 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.
Comment #117
alanpeart CreditAttribution: alanpeart commentedI 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.
Comment #118
Jooblay.net CreditAttribution: Jooblay.net commentedTHESE INSTRUCTIONS AS A FIX COLLAPSED && FAILED.
Comment #119
Jooblay.net CreditAttribution: Jooblay.net commentedTHESE INSTRUCTIONS AS A FIX COLLAPSED && FAILED.
Comment #120
Jooblay.net CreditAttribution: Jooblay.net commentedMore 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...
Comment #121
yalis reaper CreditAttribution: yalis reaper commentedThis 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.
Comment #122
Jooblay.net CreditAttribution: Jooblay.net commentedTotally 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.
:(
Comment #123
Jooblay.net CreditAttribution: Jooblay.net commentedOn 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.
Comment #124
raveendrab CreditAttribution: raveendrab commentedProblem still persists.
I am using debian wheezy php 5.4.x
Comment #125
Jooblay.net CreditAttribution: Jooblay.net commentedWe 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.
Comment #126
Anonymous (not verified) CreditAttribution: Anonymous commentedThought 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.
Comment #127
Anonymous (not verified) CreditAttribution: Anonymous commentedRe: #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?
then it failed on 7202, so I know it ran before... so...
then it failed on 7209, so I know that one ran before...
... 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.
Comment #128
basvredelingAlways with the same error
Fatal error: Class 'RulesEventHandlerEntityBundle' not found
???why don't you use something like:
to escape node.rules.inc line 147
Comment #129
jerdiggity CreditAttribution: jerdiggity commentedThe 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
sites/all/modules/rules
sites/all/modules/rules
is for Rules version 7.x-2.5If 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:
Comment #130
girishmuraly CreditAttribution: girishmuraly commentedI 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.
Comment #131
absoludo CreditAttribution: absoludo commentedThis comment on another thread worked for me for updating without disabling rules.
Comment #132
reddeer CreditAttribution: reddeer commentedNew 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.
Comment #133
steinmb CreditAttribution: steinmb commentedEveryone 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.
Comment #134
JamesOakleyThat 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.
Comment #135
alanpeart CreditAttribution: alanpeart commented...and I know this is redundant, but the WSOD is also affecting users who have never touched drush for their site, like me.
Comment #136
girishmuraly CreditAttribution: girishmuraly commented+1 for finding a non drush dependent solution
Comment #137
fagoGuys - 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.
Comment #138
alanpeart CreditAttribution: alanpeart commentedI 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?
Comment #139
fagoIf 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.
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!
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.
Comment #140
Jooblay.net CreditAttribution: Jooblay.net commentedAgree with fago we are not getting this error any more. Big thanks fago for your huge contribution to drupal:)
Comment #141
Anonymous (not verified) CreditAttribution: Anonymous commentedAgreed with #140! Thanks for all your work on this module @fago. It is a really critical component for my sites.
Comment #142
fagoYou are welcome - thanks for using it and sharing your experiences!
Comment #142.0
fagoadded non-drush updates
Comment #143
Jooblay.net CreditAttribution: Jooblay.net commentedWe maybe able to close this issue? Rules is one of the greatest modules ever!
Comment #144
tuccio CreditAttribution: tuccio commentedHello 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:
PS I was able to perform the update from the admin menu, so probably my drush issue is unrelated.
Comment #145
alanpeart CreditAttribution: alanpeart commentedAfter downloading 2.6 and running manual update I did not experience any more problems. Thanks fago.
Comment #146
Nodin CreditAttribution: Nodin commentedThis 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.
Comment #148
vparfaniuc CreditAttribution: vparfaniuc commentedsince 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.
Comment #149
hansrossel CreditAttribution: hansrossel commentedIn 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.
Comment #150
decibel.places CreditAttribution: decibel.places commentedThis is still an issue upgrading from 7.x-2.3 to 7.x-2.6
Comment #151
decibel.places CreditAttribution: decibel.places commentedI 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.
Even when I disabled AND uninstalled the module(s), the rules tables remained in the database.
Here is how I fixed it:
Comment #152
decibel.places CreditAttribution: decibel.places commentedre #133 Posted by steinmb on October 25, 2013
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)
Comment #153
RaulMuroc CreditAttribution: RaulMuroc commentedAgree to #150, upgrading from 2.3 to 2.6 breaks with the same error. And I have uploaded manually, not through Drush.
Comment #154
llepere CreditAttribution: llepere commentedAs 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):
I rolled back one more time and followed these steps (using the admin interface, not drush):
Comment #155
greatmatter CreditAttribution: greatmatter commented#129 was perfect--thank you.
I ran it line by line, ignoring the "duplicate" errors.
Lifesaver!
Comment #156
dunwich42 CreditAttribution: dunwich42 commentedAhh, 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...
Comment #157
RaulMuroc CreditAttribution: RaulMuroc commentedAnd 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.
Comment #158
LizD CreditAttribution: LizD commentedAfter upgrading from 7.x-2.5 to 7.x-2.6 I egt the following error:
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.
Comment #159
RaulMuroc CreditAttribution: RaulMuroc commentedThis is not fixed. People continue experiencing errors and besides is too hard and lot of manually modifying code for no-experienced users.
Comment #160
alanpeart CreditAttribution: alanpeart commentedRaul - 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).
Comment #161
torgosPizzaThe 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.
Comment #162
LizD CreditAttribution: LizD commentedI 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?
Comment #163
dave bruns CreditAttribution: dave bruns commentedWith 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):
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.
Comment #164
MXTGuys, 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...
Comment #165
havran CreditAttribution: havran commentedThanx 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...
Comment #166
j.johnson.bbt CreditAttribution: j.johnson.bbt commentedGetting the same error.
I used Shell and ran:
Then I got back:
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! :-)
Comment #167
alanpeart CreditAttribution: alanpeart commentedJust 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.
Comment #168
RaulMuroc CreditAttribution: RaulMuroc commentedIf people is forced to move to latest Rules we really should try this works always and 100%.
Comment #169
jerdiggity CreditAttribution: jerdiggity commentedNOTE: 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.Comment #170
niki v CreditAttribution: niki v commentedI 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
Comment #171
dandaman CreditAttribution: dandaman commentedI'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 theschema_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
to7209
(the last update included in 2.2), then running Drupal's DB update worked great and the problem was solved.Hope this helps!
Comment #172
jggarley CreditAttribution: jggarley commentedIt Fixed my problem 100%
Comment #173
jyee CreditAttribution: jyee commented#171 also resolved my issue (updating from 7.x-2.3 to 7.x-2.6, last update was 7209).
Comment #174
curiosity26 CreditAttribution: curiosity26 commentedsubscribing. Same issue.
Comment #175
caseyb CreditAttribution: caseyb commentedThe fix_rules script at #169 worked for me. Very quick and easy to implement.
Many thanks jerdiggity!!
Comment #176
CKIDOW#171 fixed it! Thx a lot!
Comment #177
thomsonj CreditAttribution: thomsonj commentedI 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!!
Comment #178
RaulMuroc CreditAttribution: RaulMuroc commentedOk, 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!
Comment #179
nostradamus1935 CreditAttribution: nostradamus1935 commentedI 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.
Comment #180
etiennechataignier CreditAttribution: etiennechataignier commented#169 did it. Thank you so much !
Comment #181
golchi CreditAttribution: golchi commentedI have used the dev version and applied #169. Great job thanks !
Comment #182
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedhas 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.
Comment #183
Glenys CreditAttribution: Glenys commentedThe fix_rules script at #169 worked for me also. Absolutely easy to implement.
This was a life saver for me, thanks jerdiggity!!
Comment #184
RaulMuroc CreditAttribution: RaulMuroc commentedThe 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?
Comment #185
dandaman CreditAttribution: dandaman commentedRaulMuroc,
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 ofrules_update_N()
functions, whereN
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 therules
package.Hope that helps clear things up!
Comment #186
RaulMuroc CreditAttribution: RaulMuroc commented@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!
Comment #187
techman-1 CreditAttribution: techman-1 commentedI 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.
Comment #188
AaronBaumanThis 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
Comment #189
Cracu CreditAttribution: Cracu commentedI 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.
Comment #190
darkodev CreditAttribution: darkodev commented+1 for #189
Thanks much for the patch, Cracu!
Comment #191
Cracu CreditAttribution: Cracu commentedJust 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.
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.
Comment #192
agerson CreditAttribution: agerson commented+1 for #189
Comment #193
toiletfinder.com CreditAttribution: toiletfinder.com commented+1 for #189
Comment #194
muschpusch CreditAttribution: muschpusch commented#30 and #189 are not fixing this problem updating from rules 2.3 to 2.7
Comment #195
joelstein CreditAttribution: joelstein commented#189 made it possible for me to upgrade from Rules 7.x-2.0 to 7.x-2.7. Thanks!
Comment #196
marcelovani#189 fixes the problem, I think this patch should be committed as soon as possible.
Comment #197
btopro CreditAttribution: btopro commentedConfirming 189 fixes as well (wow I was able to install Rules again, weird!)
Comment #198
johnv#189 includes a file in the rules.module files. Meaning: always. It should be sufficient to add this line in the install-file.
Comment #199
fagoYeah, 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 :-()
Comment #200
fagoRules 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.
Comment #201
fonant CreditAttribution: fonant commentedUnfortunately the changes in Rules 2.8 break Drupal Commerce fatally... #2403851: Drupal Commerce is broken with Rules 7.x-2.8
Comment #202
marcelovaniBroken.
It works with the patch.
Comment #203
ybabel CreditAttribution: ybabel commentedUsing 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)
Comment #204
joostpluijmers CreditAttribution: joostpluijmers commentedWithout 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!
Comment #205
cllamas CreditAttribution: cllamas commentedSame 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?
Comment #206
hbiggs CreditAttribution: hbiggs commentedNot 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;
Comment #207
agileadamThanks hbiggs, this worked perfectly.
Comment #208
webdrips CreditAttribution: webdrips commentedNote 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.
Comment #209
likewhoa CreditAttribution: likewhoa commented#189 worked but got this during the drush updb
Comment #212
likewhoa CreditAttribution: likewhoa commentedre-rolling patch
Comment #214
likewhoa CreditAttribution: likewhoa commentedLooks 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.
Comment #215
marcelovaniNot 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?
Comment #216
likewhoa CreditAttribution: likewhoa commented@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.
Comment #217
citricguy CreditAttribution: citricguy commentedI just updated from Rules 2.3 to Rules 2.9 and not without issue. Here is the process I used to finally update Rules successfully.
Comment #218
grincon CreditAttribution: grincon commented#217 worked great for me, Thanks!!
Comment #219
cspiker CreditAttribution: cspiker commented@marcelovani, @likewhoa: Instead of a db query a la #214, we can simply use
drupal_autoload_class()
to check if the new class is recognized. If not, trigger a rescan of module .info files and rebuild the system registry. Once the registry has been rebuilt, there will be no performance issue with this check (provided theRulesEventHandlerEntityBundle
class is not later removed while this check remains), sincedrupal_autoload_class()
simply wrapsclass_exists()
, with a fallback check of the lookup_cache.The attached patch can be cleanly applied to both the current 7.x stable (2.9) and dev releases.
Comment #220
maxperience CreditAttribution: maxperience commented#217 worked for me too. Thank you very much
Comment #221
marcelovaniLook at this function from bootstrap.ini
If that call was in an install hook, that would probably be ok, but being placed directly on the php execution, would probably cause unexpected behaviour, since the rebuild code would get executed before other hooks, such as init, etc
Besides, calling registry_rebuild() is a very heavy process. I am still in favour of doing a simple include as in #189. We use this patch on production on about 20 sites and have not had any problems so far.
Comment #222
yamta.a CreditAttribution: yamta.a commentedi'm having the same problem here, can someone walk me through this please... step by step for a rookie administrator. thanks. ps i run drupal 7
fud.edu.ng
Comment #223
jawad.shah CreditAttribution: jawad.shah commentedThanks citricguy and likewhoa.
#217 and #214 are worked perfectly. Great work.
Comment #224
cspiker CreditAttribution: cspiker commentedAs suggested by @marcelovani (#221), doing a simple include. Rolling new patch.
Comment #225
jimkeller CreditAttribution: jimkeller commentedI'm working in an environment that I cannot patch (enterprise multisite). For those experiencing this problem in a similar situation, the following worked for me:
1. Temporarily disable the rules module directly in the db:
mysql> update system set status=0 where name in ('rules_admin', 'rules') limit 2;
2. Clear relevant cache tables manually (not sure specifically which ones were necessary here -- probably cache_rules -- but it didn't work until I ran these):
mysql> truncate table cache; truncate table cache_bootstrap; truncate table cache_path; truncate table cache_filter; truncate table cache_block; truncate table cache_rules;
3. Run drush rr
(if it can't find this command, run drush dl registry_rebuild)
4. Re-enable rules module:
mysql> update system set status=1 where name in ('rules_admin', 'rules') limit 2;
5. Clear caches: drush cc all
Comment #226
marcelovani@jimkeller if you have a multisite, you can add the module + patches at site level.
Comment #227
rwilson0429 CreditAttribution: rwilson0429 commentedJust applying the patch in #214 to the latest 7.x-2.x-dev fixed it for me.
Comment #228
jeff h CreditAttribution: jeff h commented@jimkeller Thanks for your comment above. Upgrading from 2.3 to 2.9. Your method was the easiest way for me to get my site back up and running, even without it being a multisite.
Comment #229
hargobindApplied patch from #224 fixed the issue for me in 2.9.
Comment #230
vinmassaro CreditAttribution: vinmassaro commented+1, patch in #224 works great when updating a site from 7.x-2.2 (old!)
Comment #232
fagook, I don't like patch from #224 really, but I see this workaround can help with sucking upgrade problems. Thus, I committed this.
Comment #234
GiorgosKonly solution that worked was
drush dl rules-7.x-2.3