Everytime that I clear the cache, I get this error:

FacesExtendableException : There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 in /sites/all/modules/rules/includes/faces.inc).

Can anyone give me a clue as to what is happening here?

Files: 
CommentFileSizeAuthor
#31 rules-cache_rebuild-1285856-31.patch659 bytesplach
PASSED: [[SimpleTest]]: [MySQL] 329 pass(es).
[ View ]

Comments

I just saw this as well when triggering cache refresh. Couldn't reproduce.

Drupal 7.7
Entity API 7.x-1.0-beta10

Project:Entity API» Rules
Version:7.x-1.0-beta10» 7.x-2.x-dev
Component:Code - misc» Rules Engine
Status:Active» Postponed (maintainer needs more info)

Please re-try using the latest rules dev version - does it still happen with that?

Status:Postponed (maintainer needs more info)» Active

Updated to latest dev version of Rules, still getting the error when clearing all caches. I’ll look further into this.

EDIT: I might have spoken too soon, the problem seems to have gone away now. I’ll comment here if it returns.

Status:Active» Postponed (maintainer needs more info)

I'm using the most recent Rules dev version and repeatedly see this error; it usually goes away when refreshing the page, but I can't tell what's triggering it.

I was just bitten by this as well, but it's all all pages, the site is completely broken :(

It seems this might be related to the link or email module (it appeared just after I enabled it, and now I can't disable them):

% drush dis link email
WD php: FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of /Users/mikl/Sites/ding2/profiles/ding2/modules/contrib/rules/includes/faces.inc).
Drush command terminated abnormally due to an unrecoverable error.
FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of /Users/mikl/Sites/ding2/profiles/ding2/modules/contrib/rules/includes/faces.inc).

Ah, that was a red herring, I didn't actually have the link module present. It seems the error only occurs when the cache is used:

(mikl@Kerry-Pippin) (36/s004/0) (~/Sites/ding2/profiles/ding2/modules/contrib)
% drush en link
The following extensions will be enabled: link
Do you really want to continue? (y/n): y
link was enabled successfully.
% drush en link                                                                                                                                                                                                                                                                                                                                                                                                             WD og_membership_type: FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of /Users/mikl/Sites/ding2/profiles/ding2/modules/contrib/rules/includes/faces.inc).
WD menu: FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of /Users/mikl/Sites/ding2/profiles/ding2/modules/contrib/rules/includes/faces.inc).
link is already enabled.
There were no extensions that could be enabled.

It appears this might in fact be related to OG (organic groups).

Status:Postponed (maintainer needs more info)» Active

I've tried reinstalling the site and the same module combination, and now it works. It seems there's something sinister going on.

May I suggest you at least not throw exceptions without catching them, because it makes it almost impossible to recover the site?

I'm having the same problem:
FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133

I'm not running OG or email. I am running link module but I think the problems started when I added commerce_ogone module. So I guess it's not caused by just 1 module?

FacesExtendableException : There is no method dependencies for this instance of the class RulesAction. dans FacesExtendable->__call() (ligne 133 dans D:\wamp\www\D7_core\sites\all\modules\rules\includes\faces.inc).

Here is mine.

Steps to reproduce :
1- Create some content-type, views and rules
2- Build a feature from this
3- Load your feature then enable it
4- Cry because your website is down

I use OG, email and link modules.
My content type is a group content type and has 5 link fields but no email field.

If your website is down following this bug follow this steps :
1- Open your databse and disable Rules module (table : system, field status => 0)
2.1- Load your website
2.2- Go to Features
2.3- Disable your Feature
2.4- Submit and get an error
2.5- Keep this error in a tab
3- Reopen your database, enable Rules
4- Refresh the page with the error and submit data resubmission
5- Page reloads, the feature is disabled, the error is gone

I am getting the problem with dev version as well. Any solution please?

Version:7.x-2.x-dev» 7.x-2.0
Priority:Normal» Critical

This is a huge problem, and present in the stable 2.0 release.

I've managed to hit this on a very simple site with only one rule:

<?php
/**
* Implements hook_default_rules_configuration().
*/
function foo_bar_default_rules_configuration() {
 
$items = array();
 
$items['rules_foo_bar_update'] = entity_import('rules_config', '{ "rules_foo_bar_update" : {
      "LABEL" : "Bar create\\/update\\/delete",
      "PLUGIN" : "reaction rule",
      "TAGS" : [ "foo_bar" ],
      "REQUIRES" : [ "cache_actions", "rules" ],
      "ON" : [ "node_insert", "node_update", "node_delete" ],
      "DO" : [
        { "cache_actions_action_clear_views_cache" : { "view" : { "value" : { "foo_bar_list" : "foo_bar_list" } } } }
      ]
    }
  }'
);
  return
$items;
}
?>

(The error message in this case was FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. i FacesExtendable->__call() (linje 133 af [..]/modules/contrib/rules/includes/faces.inc).).

Status:Active» Needs work

I spent a few hours on this bug but with no result...
This module is a lot more complex than the others I used to fix.

I hope that the main contributor will handle this quickly.

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

I guess this problem stems somehow from a cache-rebuilding issue, such as fixed with #1290986: avoid entity_load() during entity info cache rebuilds. Please try updating entity, og, message, profile2, field-collection if used. If that doesn't help please report which modules you are using and try to find out which module (combination) creates the issue.

Clearing cache using Drush fixed it for me. Probably temporarily though :/

I was specifically getting this bug when i tried to add a rule responding after a new user was saved. When i switched it to Before User Save it worked with no error.

This may or may not help, but I've found a bug in the uc_coupon_workflow module that causes the same error as described here. The issue was the module was iterating through a set of rules conditions and attempting to get the name of each one, using the getElementName method ... however, the method does not exist on a RulesOr object (and I would imagine a RulesAnd too).

For reference this is the code that is throwing the exception

foreach ($rule->conditions() as $condition) {
          if ($condition->getElementName() == 'uc_coupon_workflow_suspended' && (!$events || count(array_intersect($rule->events(), $events)))) {
              $found[] = $rule->label;
          }
        }

Not suggesting this will solve all the above - but it might help find the culprit ...

A nasty fix for the above I've just hacked together :

if ($condition instanceof RulesAbstractPlugin){
            if ($condition->getElementName() == 'uc_coupon_workflow_suspended' && (!$events || count(array_intersect($rule->events(), $events)))) {
                $found[] = $rule->label;
            }
}

Version:7.x-2.3» 7.x-2.0
Component:Rules Core» Rules Engine
Priority:Major» Critical
Status:Needs review» Postponed (maintainer needs more info)

Still going strong in D7.9 (my reasonably current list of site/modules http://drupal.org/node/1323740 )

@ mdixoncm,

Thanks for the uc_coupon tip. It didn't kill the site entirely, just the Add User page. "drush dis uc_coupon" 'fixed' my issue.

Following,
Michael

Same problem here. I get it periodically, dunno how to reproduce, but i already had to reinstall my local site several times.

I have been working with Drupal for a While now and to be honest, between the versions 6 and 7 all these little bugs keep creeping up on me at the weirdest moments.
I encountered this bug while wanting to create a new User in Drupal 7, (People - Add User)
A dirty workaround for this bug, which helped me actually get to the part where a user could be added,
was to simply "comment" the line 133 in faces.inc using double slash: //

}
      $class = check_plain(get_class($this));
      // throw new FacesExtendableException("There is no method $name for this instance of the class $class.");
    }

I hope someone can find a more substantial solution.

I found out that this does happen for rules version >= rc-1

update: traced it down to this commit:
http://drupalcode.org/project/rules.git/commit/3d54edd3ed72a710ccd7667bf...
related to http://drupal.org/node/1223028

I'm currently working on a batched ruleset plugin: http://drupal.org/node/1342126
I get these errors everytime I try to create an action or a condition of a rule in the rule set.
Did I simply do something wrong, causing this error?

Simply throwing this more or less cryptic error message does help nobody. I was not able to figure out which setting or dependency was causing the error.

I had to go back to a previous release of rules and somehow I had the impression that some files are missing in the last update.

I'm currently building 3 D7 project sites, today I experienced the "FacesExtendableException" error as per:

"FacesExtendableException: There is no method getElementName for this instance of the class RulesOr. in FacesExtendable->__call() (line 134 of /var/www/domainname/sites/all/modules/rules/includes/faces.inc)."

NOTE: I'm working on localhost with no WAMP just pure Linux on a LAMP box. The above path 'domainname' would be my site name, removed here for example.

All the sites have the same modules mirrored for D7 use and the only thing I know I've added this week is the uc_coupons and the uc_affiliate modules (UberCart).
If I try to add a new user from the admin D/B, I get the above error, but on my other 2 project sites, I don't get any error and can add new users.

I can add new users via the frontend registration process on the error site, but NOT the D7 backend "Add user" DB.

I'm a 12 month+ noobie running an Ubuntu 10.04 workstation for webdev (with no M$ in sight); I've tried the backend SQL Myphpadmin to see if it was a cache/optmise issue, but to no avail.
Cleaned the D7 caches also, but no joy.
D7 has been going well, I'm a new Drupal WebDev (25 years with comps/music tec/M$), novice PHP, but keen to "look n' hack", but for now, deffo no pro PHPer.

Any ideas, comments on the above errors?

PB, Lancs, UK.

subscribe

Version:7.x-2.0» 7.x-2.x-dev
Priority:Critical» Major

Please try with the latest versions and report back.

I'm running 7.0-2.1 and have the same error. I don't have coupon or OG modules installed - I think it's purely rules-related. Clearing cache didn't work.

I've isolated my error as being caused by a specific rule. It enables a payment method if specific product types are on the order during checkout. I get the error when I try to view payment method on the order payment tab.

Rules 2.1 works well for a simple Rule only using core events, conditions and actions.
No problems with more complex Rules using Components or things from other modules like Commerce for example.

Seems RTBC ;)

Component:Rules Engine» Rules Core
Status:Postponed (maintainer needs more info)» Needs review
StatusFileSize
new659 bytes
PASSED: [[SimpleTest]]: [MySQL] 329 pass(es).
[ View ]

I experienced this too, it seems indeed related to cache rebuilding. In my case I was calling commerce_cart_order_load() from a hook_rules_config_load() implementation in a custom module. This caused rules to be loaded before finishing to be loaded :)

One interesting thing is that it seems this is triggered only for dirty rules, which may explain why with the same code base this cannot be replicated reliably.

I found that simply not throwing the exception in this particular case seems to fix things, but I ain't sure this is the proper fix, maybe @fago can help ;)

hm, I'm not sure. Just saying nothing in this case might be problematic when this is really an issue. I guess the question is how this becomes invoked during a load operation or whether we detect this situation better?

I guess the question is how this becomes invoked during a load operation or whether we detect this situation better?

Yep, probably, but I've no idea of how to do that :)

I got the same error this morning...the site was down this morning when I came in. (Glad it isn't a production site yet!)

Anyway, running Drupal 7 with Rules 7.x-2.3. This error appeared when I try to run "drush cc all". It just started after yesterday's commits but didn't appear immediately.

I applied the patch in https://drupal.org/node/1285856#comment-7532049 and then tried "drush cc all" and got the following from Drush:

Invalid argument supplied for foreach() rules.module:901                                                                                                                                       [warning]
WD menu: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the    [error]
right syntax to use near '))' at line 1: SELECT base.id AS id, base.name AS name, base.label AS label, base.plugin AS plugin, base.active AS active, base.weight AS weight, base.status AS
status, base.dirty AS dirty, base.module AS module, base.access_exposed AS access_exposed, base.data AS data
FROM
{rules_config} base
WHERE  (base.plugin IN  ()) ; Array
(
)
in EntityAPIController->query() (line 187 of /var/www/html/example.com/sites/all/modules/entity/includes/entity.controller.inc).
Fatal error: Call to undefined method stdClass::event() in /var/www/html/example.com/sites/all/modules/commerce_shipping/commerce_shipping.rules_defaults.inc on line 25
Drush command terminated abnormally due to an unrecoverable error.                                                                                                                             [error]
Error: Call to undefined method stdClass::event() in /var/www/html/example.com/sites/all/modules/commerce_shipping/commerce_shipping.rules_defaults.inc, line 25

So the patch helps to shed some light on the ACTUAL cause of the problem.

Thanks,
Dave

Version:7.x-2.x-dev» 7.x-2.3
Priority:Major» Critical

With Commerce Kickstart if i want to see Payment methods page

FacesExtendableException: There is no method getElementName for this instance of the class RulesConditional. in FacesExtendable->__call() (line 133 of /home/admin/public_html/mysite/profiles/commerce_kickstart/modules/contrib/rules/includes/faces.inc).

help us !

The patch don't work

Priority:Critical» Major

#35 seems to be occurring relationship with rules_conditional project, so not a good cause to raise this issue as critical for this project.

Version:7.x-2.0» 7.x-2.3
Component:Rules Engine» Rules Core
Priority:Critical» Major
Status:Postponed (maintainer needs more info)» Needs review

Having the same error as #35 when trying to open admin/commerce/config/payment-methods
"FacesExtendableException: There is no method getElementName for this instance of the class RulesLoop. em FacesExtendable->__call() (linha 138 de /www/sites/all/modules/rules/includes/faces.inc)."

I am using Drupal 7.23 with Commerce 7.x.1.7, Commerce Rules Extra 7.x.1.1 and Rules 7.x.2.3 amongst a lot of other modules.

Looking for help! Thx.

Hi, I am having the same issue as #38. greetings, Martijn