Class [warning] RulesPluginFeaturesIntegrationInterface does not exist and could not be loaded faces.inc:233

I think this is caused by something that is cached.

I find that reverting to version 2.11, clearing caches, and only then updating to version 2.12 works.

I've yet to discover whether the site continues to work after rules have been triggered.

@ñull: Is this from 2.11 to 2.12? In issue #2297087: Typo in RulesPluginFeaturesIntegrationInterace, committed on 29 July 2018, the interface RulesPluginFeaturesIntegrationInterace (note the mis-spelling!) was renamed to RulesPluginFeaturesIntegrationInterface. A copy of the mis-spelled interface was retained in 7.x-2.12 for backwards compatibility with contributed modules which might have been using the interface with the wrong spelling.

Clearing your cache / rebuilding your registry should eliminate any reference to the old interface and allow Drupal to find the new interface, as @fonant said in #1.

I just hit this as well after upgrading from 2.11 to 2.12 about an hour ago.

Any ideas on how to clear the cache when I can't even run drush?

EDIT: Managed to fix this by rolling back to 2.11 (Been working on too many D8 sites, forgot modules were not in /modules), but clearing the cache (drush cc all) and then rolling forward to 2.12 did NOT fix the problem for me.

Sticking with 2.11 for now.

My specific error:

array_diff(): Argument #1 is not an array faces.inc:229                                   [warning]
class_implements(): Class RulesPluginFeaturesIntegrationInterface does not exist and could[warning]
not be loaded faces.inc:233
Drush command terminated abnormally due to an unrecoverable error.                        [error]
<h1>Additional uncaught exception thrown while handling exception.</h1><h2>Original</h2><p>Error: Unsupported operand types in FacesExtendable-&gt;extend() (line 233 of ...mydir.../sites/all/modules/rules/includes/faces.inc).</p><h2>Additional</h2><p>FacesExtendableException: There is no method process for this instance of the class RulesAction. in FacesExtendable-&gt;__call() (line 135 of ...mydir.../sites/all/modules/rules/includes/faces.inc).</p><hr />

("...mydir..." are edited in by me)

Did you rebuild your registry? This is a core problem that has always^(*) been present in Drupal 7 - the registry is a cache of class names/locations, and if a class name/location gets changed then the registry needs to be rebuilt. Core unfortunately does not manage the cache miss properly, and errors out instead of trying to refresh the cache. You can rebuild your registry with drush using https://www.drupal.org/project/registry_rebuild

^(*)Here's the still-open critical core meta issue created 9.5 years ago: #534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap. This is just one of the issues raised in core going back to the introduction of the registry in Drupal 7.

This just broke 5 of my sites as well.. I just reverted them to 2.11. Once I have some time, I will see if I triggering a registry rebuild works.

Rebuilding the registry does solve the problem.

Unfortunately, drush no longer works once cron runs and the site crashes.

So the following update sequence has to be completed between cron runs.

#between cron runs
drush @none dl registry_rebuild-7.x
drush cc drush
drush cc all
drush up
drush rr
drush cc all
#Test site after next cron run.

Including the "drush cc all" because some have reported that updating without clearing cache seems to crash the site too.

See how to rebuild the registry without drush.

Shouldn't rebuilding the registry be part of the update process?
Or at least triggered as part of the module update?

The problem is that once cron runs after the update and the site crashes, drush stops working too.
So reverting to the previous version has to be done manually.

Commands given below, in case it helps.

cd sites/all/modules/
wget https://ftp.drupal.org/files/projects/rules-7.x-2.11.tar.gz
tar -xizf rules-7.x-2.11.tar.gz

Shouldn't rebuilding the registry be part of the update process?

#534594: [meta] system info cache writing and registry rebuilding is broken without a full bootstrap does explain why this is difficult.

But would've be great if there were some way to warn site maintainers that updating the module without a registry rebuild will cause the site to crash.

#8 solved this successfully for me with updating to rules 7.x-2.12.

To summarize:

This is a problem that affects SOME sites that use Rules. Only 1/2 a week after the release of 7.x-2.12, there are already some 7,000 sites using 7.x-2.12, while there are only a handful (or two) of sites where this has caused a problem.

I'm not sure exactly what sort of configuration triggers the problem - I did not experience this on my test sites, for example, and I DID test the upgrade process before I made a new release. All the above posts seem to have a problem only after CRON runs, which is strange. That implies to me that there is something that happens during cron() that tries to use this new interface. The only things Rules does during cron() is to generate the "Cron maintenance tasks have been performed" event, and to check for tasks scheduled by the Rules Scheduler.

I suspect everyone who has experienced this problem has something in common - are you all using Rules Scheduler? Are you all reacting on the "Cron maintenance tasks have been performed" event? Do you all have the Features module installed and enabled? Are you all upgrading via drush?

Regardless, we have a workaround by rebuilding the Drupal registry, which in any event is an extremely important skill that all Drupal site maintainers should know how to do. The https://www.drupal.org/project/registry_rebuild project gives you a means of rebuilding the registry either through drush or through the command line. You should have this installed on your site even if you're not affected by this issue - I have had to use it hundreds of times in the 10 years since Drupal 7 started development; knowing how to rebuild the registry is almost as important a Drupal skill as being able to clear the cache.

My recommendation would be to consider this a documentation issue. May be the update code could return a warning with instructions or a link to instructions?

I plan to leave this issue open for a while, so it can be easily found. Perhaps put a note on the project page. Unfortunately a fixed-point release like 7.x-2.12 cannot be changed. While it is possible to show a message when update.php is run (this can be done in hook_requirements() during the 'update' phase), that can't be done with 7.x-2.12 because it cannot be changed, and even if we added a message I think a vast majority of people would ignore it (that's been my experience when I've done this previously). And we could only warn that this MIGHT be a problem, and that if you encounter it you will need to rebuild your registry. Most people will go ahead with the upgrade hoping it won't be a problem for them, and most people will be right. It's only for the sites that fail that this warning might be useful, and even then all we can tell them is to come here to this issue and learn how to rebuild the registry.

@TR Personally I manage the project through composer and update through Drush.
So my process would be

$ composer update
$ cd $web_root
$ ../vendor/bin/drush updb

No cron run in between. However, maybe I did try to access the UI before running the Drupal updates even though I do not think it mattered.

only a handful (or two) of sites

Many may not have updated yet.

only after CRON runs

True.

are you all using Rules Scheduler?

job_scheduler

Are you all reacting on the "Cron maintenance tasks have been performed" event?

Unsure.
An installed module might be.

Do you all have the Features module installed and enabled?

No.

Are you all upgrading via drush?

Yes.

Perhaps put a note on the project page.

Good idea. That might help.

Clearing all caches seems to fix the issue for me anyway.

Let’s keep this on the branch in case there is ever somehow a patch.

Just a note that after following the steps in #8 / #10, my site failed again during the next cron job. Running drush rr fixed the issue (hopefully for good).

I'd suggest trying to manually re-run cron manually just to be super sure the site isn't going to go offline on you again.

I updated the registry table directly and replaced "RulesPluginFeaturesIntegrationInterace" with the correctly spelled name "RulesPluginFeaturesIntegrationInterface" (with an 'f'). That fixed my issue.

I updated the registry table directly and replaced "RulesPluginFeaturesIntegrationInterace" with the correctly spelled name "RulesPluginFeaturesIntegrationInterface" (with an 'f'). That fixed my issue.

So theoretically speaking, the update could also alter the table directly? (I realize the risks.) But the problem seems to hit more and more people.

If you're stuck with a broken site and drush rr fails, you can execute:

drush sql-query "UPDATE registry SET name = 'RulesPluginFeaturesIntegrationInterface' where name = 'RulesPluginFeaturesIntegrationInterace'"

As I said in #12,

The https://www.drupal.org/project/registry_rebuild project gives you a means of rebuilding the registry either through drush or through the command line.

This is the safest and best way to rebuild your Drupal registry, and it works in all other situations where you need to rebuild your registry.

I would not recommend the method described in #20 and #22 because the RulesPluginFeaturesIntegrationInterace still exists in Rules - it was deliberately left in the Rules codebase to ensure backwards compatibility with custom code and other contributed modules which might be still using it.

Updated issue summary.

@TR In this case a registry rebuild can fail as well, leaving a a site completely broken. That is a what #22 will solve. It is definitely not a recommended approach, but merely a last resort.

Does anyone have any Acquia Cloud tips for this one? The first opportunity to rebuild the registry is after the code has already been deployed, at which time all drush commands fail with the error described in the issue summary.

Update: not all drush commands fail, perhaps #22 is the way to go.

Ignore my silly rants—this works perfectly well in a post-code-deploy AC hook:

site="$1"
target_env="$2"

drush @none dl registry_rebuild-7.x
drush cc drush
drush --root=/var/www/html/$site.$target_env/docroot @sites rr

I had a problem on my site.
When I replace Rules 2.12 with 2.11, it works again, but crashes when I delete the cache and try to update using Drush.

Stephane, if it's still crashing your site you need to do what is described in #22. It is not recommended, but it is potentially necessary as a last resort to allow access to the site so you can rebuild the registry.

After successfully rebuilding the registry, it should have the correct records in the registry table.

You can use https://www.drupal.org/project/registry_rebuild FROM THE COMMAND LINE

@TR, I was using drush rr from the command line.

After running, I tried to do a drush cc all and got all types of error messages about it not being able to find the class, and was unable to load the site.

The *only* way I was able to resolve was to either modify or delete the offending record from the registry table, and then run drush rr from the command line again.

No, you're not understanding. From the command line, NOT using drush.

php registry_rebuild.php

This is all explained on the https://www.drupal.org/project/registry_rebuild project page under the heading "How To Use Registry Rebuild Without Drush"

Understood.

@TR Your continued attention to helping everyone on this issue is appreciated.

There are now almost 40,000 web sites successfully running Rules 7.x-2.12. See https://www.drupal.org/project/usage/rules . There have been no reports of problems for two weeks now.

So I'm moving this issue to "Fixed". If people keep posting here this issue will stay open until two weeks after the last comment, at which point it will be automatically closed.

I have updated to version 7.x-2.12 without any issues however when upgrading the site to PHP 7.2 I run into this issue.

Using PHP 7.2 this is an issue. None of the Solutions here helped. To say this is fixed by looking at stats is ridiculous. Bye.

@andros Did you execute a registry rebuild?

The instructions in #8 should work if followed to the letter, as #11 confirmed.

Don't think #19 followed #8 exactly.
#8 already mentions that "drush rr" has to be run BEFORE cron runs.

Wouldn't it just be easier to make another release with a note telling admins to rebuild the registry after the update?

@cilefen yes I tried it. But I have now uninstalled rules completely.

Here's the specific order of commands that worked for us:

drush @none dl registry_rebuild-7.x
drush cc drush
drush @YOURSITEALIAS up rules-7.x-2.12
drush @YOURSITEALIAS cc all
drush @YOURSITEALIAS rr
drush @YOURSITEALIAS updb

Note: If your site doesn't have an alias, you can remove the @YOURSITEALIAS bit from all the commands above and then run the commands in the directory of your Drupal install.

Alternatively, do as #22 /u/interX wrote to manually make the change the value in the site's database.

drush sql-query "UPDATE registry SET name = 'RulesPluginFeaturesIntegrationInterface' where name = 'RulesPluginFeaturesIntegrationInterace'"

Or run `php registry_rebuild.php` from the command line as instructed here: https://www.drupal.org/project/registry_rebuild

If you are still having issues, please post exactly what commands you have tried running, in what exact order, and what errors you're getting.

Having same problem after upgrade to PHP 7.2.
And can't run "drush cc all" exactly because of catching error.
Maybe "drush rr" should be run first.
But don't have chance to test it right now, reverting to 2.11.

If you rebuild the registry WITHOUT using drush, like I recommend, then it will work. The problem with using drush is that drush needs to bootstrap Drupal for many things, and if the registry is corrupted then neither Drupal nor drush will work. But using https://www.drupal.org/project/registry_rebuild and running php registry_rebuild.php from the command line will always work.

I had the same problem with update, luckly "drush rr" fixed this, didnt need to revert it, just run that and site was back to normal.

In my case Drush was broken, so I corrected the "registry" database table entry following advice from #20 above. Worked for me.

In my case the #20 helped, replacing straight to database and the site went back on.
When I went to look again the value in the database, it was back without "f" letter. Is it like it should be?
I don't understand much about this, should I run the "Drush rr" while the site is working?

I have multiple similar sites which luckily are still working, but I am afraid if same problem hits them also.

Also many here are saying "revert back to 2.11" does it mean that just delete the 2.12 version folder and put a new one? I do not have any backup of the databases with 2.11 rules installed.

UPDATE:
I compared all my working Drupal 7 sites to this one which broke and found one difference, it uses "Universally Unique ID"
module version 1.2. (I was not able to uninstall this module, it broke the whole site)
Not sure has this anything to do with this issue but this is what i found.

I had the same issue and am also using UUID - perhaps a red herring.

drush sql-query "UPDATE registry SET name = 'RulesPluginFeaturesIntegrationInterface' where name = 'RulesPluginFeaturesIntegrationInterace'"

Above query worked for me and no errors now.

So it appears the crashes were caused by the typo RulesPluginFeaturesIntegrationInterace in the code somewhere.

Is it likely that some future update that fixes the typo back to RulesPluginFeaturesIntegrationInterface will crash all sites again?

@serenity1 Version 2.12 was the update that fixed the typo.

On latest dev, updated from 2.10. I wasn't able to get the site working due to error subject:

Error: Unsupported operand types in FacesExtendable->extend() (line 233 of /var/www/html/public/sites/all/modules/contrib/rules/includes/faces.inc).

Registry rebuild didn't seem to work, but I'm using a new docker-based environment, and I'm not entirely sure rr is running correctly.

sandykadam's suggestion in #54 for me worked with the SQL query.

interface with typo still exists, although with a comment that it is there for legacy support.

This seems to be a very tricky problem. I got this error on an update test with "drush updb" and also fixed the test system with the drush command of #22. On next test with a fresh import of the old database but same codebase this error won't occur.

With the patch from duplicate issue, system doesn't break https://www.drupal.org/project/rules/issues/1111868

By means of what this issue got status "Closed (fixed)" for version "7.x-2.x-dev", if currently branch 7.x-2.x at rev bf7d3c68 still have

interface RulesPluginFeaturesIntegrationInterace extends RulesPluginFeaturesIntegrationInterface

??

drush rr works for me #50

If you don't have access to a command-line tool, but you do have access to your database, you can do something like

UPDATE registry set name='RulesPluginFeaturesIntegrationInterface' where name='RulesPluginFeaturesIntegrationInterace';

and

DELETE from registry where name='RulesPluginFeaturesIntegrationInterace';

We can prevent the fatal errors on upgrade with an update function in Rules, then users don't need the registry_rebuild workarounds. Patch is in #3334495: RulesPluginFeaturesIntegrationInterface does not exist and could not be loaded faces.inc.