Fatal error: Class 'FacesExtendable' not found in /sites/all/modules/rules/includes/rules.core.inc on line 101

I'm able to reproduce this in my testing environment when I use the testing mail class for rerouting emails (to avoid sending unwanted notifications emails). To reproduce:
- install latest dev versions of rules and entity
- create a node
- create a rule that sends an email every time a node content is viewed
- visit the node and note that the email is sent (check the logs or visit your mailbox)
- add this to your settings.php:

$conf['mail_system'] = array('default-system' => 'TestingMailSystem');

- visit the node one time
- reload the load, your site just broke. No page will load from now on, and fails with Fatal error: Class 'FacesExtendable' not found in /sites/all/modules/rules/includes/rules.core.inc on line 101

the class is loaded via the class autoloader of rules, see rules_autoload(). I've no idea why this shouldn't work in this case.

I can confirm this too. After running drush commnad "drush fu my_feature_x" I started to get this error in browser and also in drush command "drush cc all". The code change suggested in the issue description does not help in my case.

My feature didn't have any rules included.

I've been using features with and without rules on sites where rules is installed without any problems. So please try to reproduce this with latest module versions.

I'm seeing this as well - WSOD on the site, and drush cc all reports:

PHP Fatal error: Class 'FacesExtendable' not found in /var/www/xmike/XPortal/sites/all/modules/contrib/rules/includes/rules.core.inc on line 101

I tried added includes/faces.inc to the .info, for the autoloader to find, but no luck (I'm guessing because the definitions are conditional - is that why rules is rolling its own autoload?). As near as I can tell, rules_autoload() is never getting called. I wonder if there's an interaction with the core autoloader - the core autoloader gets called before rules_autoload(), includes rules.core.inc, and dies because it hasn't seen faces.inc yet. But, I tried

spl_autoload_register('rules_autoload', TRUE, TRUE);

(third argument says to prepend the new autoloader), it still doesn't seem to be calling rules_autoload(). Could the core autoloader be including rules.core.inc before rules.module is pulled in?

This is with PHP 5.3, features is in there along with a ton of other contrib and custom modules...

One more thing - if I start the site over with drush site-install (which enables all the same modules, including features and rules), all is well. This all happened after pulling changes to a couple of features and reverting them.

And, without touching features, it's broken again. I was running a migration, I imported 193 of 240 incoming records (193 node_save() calls) when it died.

This continues to be an impediment. Some new information - when I rebuild my site with drush site-install, I get the FacesExtendable problem, but going through install.php there's no problem. Unfortunately, we really need to have drush site-install working (to automatically rebuild a staging server).

I would guess that there's some issue with order of module enablement, or cache clearing, or both at install time that leaves Drupal in an unbootable state. Still trying to understand it, but in the meantime - why exactly does faces.inc have its own special autoloader? To accomodate anyone who might be using the Faces module?

One more thing, I did try to change rules to load faces.inc in the normal fashion, but that generated the problem seen in #1049104: Fatal error: Call to undefined function entity_get_property_info().

>why exactly does faces.inc have its own special autoloader?
The idea is that one can install the faces module, and then the version of the faces module gets used via the core-autoloader. The fallback is the rules autoloader + the faces version rules ships.

>Unfortunately, we really need to have drush site-install working (to automatically rebuild a staging server).
That works for me too, so there must be something (a module?) on your installation causing this.

>Could the core autoloader be including rules.core.inc before rules.module is pulled in?
Sounds logical to me. Maybe the problem is a registry_rebuild() call without all modules loaded? Thus, it could be related to #1170312-40: After updating to Drupal 7.2 Fatal error: Class 'ctools_export_ui' not found

Oy! What a mess... OK, so I'm working on migration from a system with a lot of user accounts, into a Drupal install with forum notifications established. To prevent accidentally spamming real users while testing migration, I have this in my settings.php:

$conf['mail_system'] = array(
  'default-system' => 'TestingMailSystem',
  'htmlmail' => 'TestingMailSystem',
);

I should've read the existing thread more closely, @scor did the same thing... Anyway, without looking too closely, I had assumed TestingMailSystem would direct attempted emails to the dblog (as devel used to do), or basically /dev/null. No - it puts the message in variable drupal_test_email_collector. So, the sequence of events is:

1. I run drush site-install.
2. We have features that create sample content at install time, including a couple of OG-based forums. Notifications are enabled, so this tries to send emails to the forum owner (admin account).
3. The emails it attempts to send end up in the drupal_test_email_collector variable. They aren't plain text - the $message saved is an array containing objects (including rules objects).
4. After the install is done, we're left with no variables cached. So, the first time I attempt anything the bootstrap process reads the variables table and unserializes the values.
5. Unserializing drupal_test_email_collector attempts to instantiate the embedded objects, including Rules objects derived from FacesExtendable.
6. But uh-oh! We're doing this before the modules are loaded, so the rules autoloader isn't in play yet and there's no way to load faces.inc.

So, there are a few things we can do to avoid this - I'm leaning towards implementing (or seeing if anyone has already done so) a MailSystem class that dumps messages into the log, which will be easier for us to review for testing anyway. I'm guessing TestingMailSystem is just meant to support simpletests of the mail system.

I don't think there's anything Rules can do about this - as I said, even if I change faces.inc to be autoloaded the normal way I hit #1049104: Fatal error: Call to undefined function entity_get_property_info() - it's a fundamental core restriction/quirk/bug that storing objects as variables carries the risk that the necessary pieces won't be in place when the variables need to be unserialized. I'll leave open for now and let others experiencing this problem confirm that their issues are due to objects stored in variables.

I was taking a site live (reindexing site, setting up xml sitemap, css tweeks, I can't find any changes that seems to apply here), when this error appeared - nothing to do with mail. I added "include_once 'faces.inc';" to the top of rules.core.inc and that seemed to help. Although it is a site with not much content, so maybe all the content had already been rendered when I was testing this error and so the error didn't come up again.

I also got this error and adding "include_once 'faces.inc';" to rules.core.inc got me past the white screen of death but then it brought up the following error.
Warning: require_once(/sites/all/modules/rules/includes/rules.core.inc): failed to open stream: No such file or directory in _registry_check_code() (line 2723 of /includes/bootstrap.inc).
This error went away after navigating to another page. However, the next time I tried to enable rules it completely killed my site giving me "The website encountered an unexpected error. Please try again later." I removed the rules directory from my modules folder and my site worked again.

Hopefully that helps somebody. I don't really understand much of this so I'm not of much use other than error reporting.

get also this error on any version higher then 7.x-2.0-beta2, as son as i clear the cache or run update.php

also there is some times this warning
Warning: Parameter 1 to upload_replace_file_update() expected to be a reference, value given in module_invoke_all() (in /includes/module.inc on line 819).

The same error. Subscribe.

sub

The same error here. It happens even when searching. However, no rule is set for the search action.
Error is on line 231.

Sub.

Using the latest dev version of every module.

Fatal error: Class 'FacesExtendable' not found in /sites/all/modules/rules/includes/rules.core.inc on line 231

duplicate of #1257580: Fatal error: Class 'FacesExtendable' not found line 231 on every page after </html> tag

Wow, that's weird. I get this error shown on page when I visit the site with a Lenovo TouchPad (Mozilla/5.0 (Windows; U; Windows NT 5.1 ; en-us; ThinkPad Tablet Build/ThinkPadTablet_A310_02) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13), but not with an android phone, an IPad or any desktop browser.

Fatal error: Class 'FacesExtendable' not found in /mydomain/drupal-7.8/sites/all/modules/rules/includes/rules.core.inc on line 231

If it helps anyone, I had this problem too and it appears to me to be a simple class registry problem. Drupal maintains a registry of classes that it will attempt to autoload if they are called and if they have not already been loaded. However, from time to time, for a number of reasons, this registry falls out of sync and needs to be rebuilt.

The best way at present is to use drush's registry rebuild function, eg. "drush rr". This will attempt to rebuild the registry for you. Google this for more info.

It appears to have fixed this error for us, and in the process it picked up 2 files that were missing from the registry.

Note that you will need the Registry rebuild module to run drush rr, see instructions at http://drupal.org/project/registry_rebuild

The browser is irrelevant. It happens for new visitors. If you open the page in a new incognito mode you'll see it once. Refresh it and it's gone (if the page isn't cached).

drush rr didn't do anything for me.