Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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?
Comment | File | Size | Author |
---|---|---|---|
#54 | enable payment method for specific address.txt | 2.49 KB | arefen |
#54 | snapshot1.png | 44.1 KB | arefen |
Comments
Comment #1
westbywest CreditAttribution: westbywest commentedI just saw this as well when triggering cache refresh. Couldn't reproduce.
Drupal 7.7
Entity API 7.x-1.0-beta10
Comment #2
fagoPlease re-try using the latest rules dev version - does it still happen with that?
Comment #3
dboulet CreditAttribution: dboulet commentedUpdated 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.
Comment #4
fagoComment #5
jackalope CreditAttribution: jackalope commentedI'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.
Comment #6
mikl CreditAttribution: mikl commentedI was just bitten by this as well, but it's all all pages, the site is completely broken :(
Comment #7
mikl CreditAttribution: mikl commentedIt 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):
Comment #8
mikl CreditAttribution: mikl commentedAh, 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:
It appears this might in fact be related to OG (organic groups).
Comment #9
mikl CreditAttribution: mikl commentedI'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?
Comment #10
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedI'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?
Comment #11
DuaelFrHere 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
Comment #12
khan2ims CreditAttribution: khan2ims commentedI am getting the problem with dev version as well. Any solution please?
Comment #13
mikl CreditAttribution: mikl commentedThis 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:
(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).
).Comment #14
DuaelFrI 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.
Comment #15
fagoI 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.
Comment #16
AdamGerthel CreditAttribution: AdamGerthel commentedClearing cache using Drush fixed it for me. Probably temporarily though :/
Comment #17
eric-ie CreditAttribution: eric-ie commentedI 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.
Comment #18
mdixoncm CreditAttribution: mdixoncm commentedThis 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
Not suggesting this will solve all the above - but it might help find the culprit ...
Comment #19
mdixoncm CreditAttribution: mdixoncm commentedA nasty fix for the above I've just hacked together :
Comment #20
Michael-IDA CreditAttribution: Michael-IDA commentedStill 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
Comment #21
patrickd CreditAttribution: patrickd commentedSame problem here. I get it periodically, dunno how to reproduce, but i already had to reinstall my local site several times.
Comment #22
Johan_s CreditAttribution: Johan_s commentedI 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: //
I hope someone can find a more substantial solution.
Comment #23
patrickd CreditAttribution: patrickd commentedI 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?
Comment #24
rogerpfaffSimply 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.
Comment #25
paulbuk CreditAttribution: paulbuk commentedI'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.
Comment #26
007pig CreditAttribution: 007pig commentedsubscribe
Comment #27
mitchell CreditAttribution: mitchell commentedPlease try with the latest versions and report back.
Comment #28
tevih CreditAttribution: tevih commentedI'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.
Comment #29
tevih CreditAttribution: tevih commentedI'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.
Comment #30
DuaelFrRules 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 ;)
Comment #31
plachI experienced this too, it seems indeed related to cache rebuilding. In my case I was calling
commerce_cart_order_load()
from ahook_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 ;)
Comment #32
fagohm, 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?
Comment #33
plachYep, probably, but I've no idea of how to do that :)
Comment #34
davea CreditAttribution: davea commentedI 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:
So the patch helps to shed some light on the ACTUAL cause of the problem.
Thanks,
Dave
Comment #35
jackdaniel9 CreditAttribution: jackdaniel9 commentedWith Commerce Kickstart if i want to see Payment methods page
help us !
The patch don't work
Comment #36
dude74 CreditAttribution: dude74 commentedComment #37
fago#35 seems to be occurring relationship with rules_conditional project, so not a good cause to raise this issue as critical for this project.
Comment #38
Marc Storms CreditAttribution: Marc Storms commentedHaving 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.
Comment #39
Summit CreditAttribution: Summit commentedHi, I am having the same issue as #38. greetings, Martijn
Comment #40
greggadsdon CreditAttribution: greggadsdon commentedI've been getting the error "FacesExtendableException: There is no method dependencies for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of [error]
/Users/greg/sites/dotcom.drupal/sites/all/modules/contrib/rules/includes/faces.inc)" for some time when I clear caches.
I debugged to see what action it was failing on and it looked to be incomplete. I loaded the action up in rules UI and since then I've not had a problem! It must just have cached a half-built action and didn't actually re-build until I loaded it up to look at it.
Comment #41
pyry_p CreditAttribution: pyry_p commentedFor me it was caused by looping over items on reaction "Select available payment methods for an order". By moving the loop to component it seems fixed.
Same as #29 #35 #38
Located the name of the rule by injecting before the throw error dpm(ddebug_backtrace()); and after that dpm($this); at rules.core.inc function forceSetUp
Comment #42
fox_01 CreditAttribution: fox_01 commentedConditions inside the payment rules will cause this error. I moved my conditions from the actions section to the conditions section of the rule
Comment #43
blattmann CreditAttribution: blattmann commentedUpgrading to version = "7.x-2.7+6-dev" is what I needed to do to resolve this issue. I didn't try the patch, but the dev version has resolved the issue.
By "resolve the issue" I mean that I can load my site again and possibly address some misconfigured rules that were causing serious problems.
Comment #44
marcelovaniPatch #31 works for me, I would recommend committing it.
Comment #45
geek-merlinMy gut feeling is that this might be solved by patch from #2324587: Rules might be triggered too early in the bootstrap - can anyone check this?
Comment #46
marcelovaniI had to apply these two patches agains the dev version to get rules to work properly
https://www.drupal.org/files/issues/d7_rules_invoke_later.patch (https://www.drupal.org/node/2324587)
https://www.drupal.org/files/rules-cache_rebuild-1285856-31.patch (https://www.drupal.org/node/1285856)
I think both should be committed.
Comment #47
el_reverend CreditAttribution: el_reverend commentedExperiencing the same issue on a commerce site (d7.34 / Commerce (kit) 1.9, commerce_views_display 1.0).
Truncating the cache tables will fix the issue for me. However I noticed that a call exhausted the memory on a 16GB mem server and I had to restart apache. Not sure if the two are related. I have noticed that when clearing the cache via drush (drush cc all) this symptom appears some of the time. However clearing the cache section by section (drush cc css-js, etc.) seems to forego this issue.
This also happens on a RedHat install, but so far has not occurred on a ubuntu box... Again, not sure if that has any influence.
Comment #48
my-family CreditAttribution: my-family commentedI experienced the same problem when I tried to add an "if" branch. So what's the recommended solution? the -dev version with the #46 patches?
Comment #49
romeof1980 CreditAttribution: romeof1980 commentedpatch rules-cache_rebuild-1285856-31.patch seems to work for me too.
thanks!
Drupal 7.31 , PHP 5.5.21, Commerce 7.x-1.9
Comment #50
RavindraSingh CreditAttribution: RavindraSingh as a volunteer and at Srijan | A Material+ Company commentedCann't reproduce the error in 2.9 release. I followed the steps added in #11.
"
"
Comment #51
RavindraSingh CreditAttribution: RavindraSingh as a volunteer and at Srijan | A Material+ Company commentedComment #52
nwoodland CreditAttribution: nwoodland commentedThe tip from #42 fixed this issue for me. Thanks fox_01!!
Comment #53
sujith.nara CreditAttribution: sujith.nara as a volunteer and commentedI got this error,
FacesExtendableException: There is no method getElementName for this instance of the class RulesLoop. in FacesExtendable->__call() (line 133 of /sites/all/modules/contrib/rules/includes/faces.inc).
Then I removed a particular rule (may be buggy) from my feature. No error now!
(Removing it from feature_name.info didn't work, I actually deleted feature_name.rules_defaults.inc)
Comment #54
arefen CreditAttribution: arefen commentedHello. i have a rules that have condition in action section. i want enable specific payment method depend on customer address. and create a rule for that such below image:
I can't move my conditions to conditions section (42) . and path 31 don't work for me.
Comment #55
RAWDESK CreditAttribution: RAWDESK commentedThis patch fixed my issue with this error on payment methods configuration pane :
https://www.drupal.org/node/2500311
Comment #56
mrP CreditAttribution: mrP commentedI can still easily dupe this with a Commerce Kickstart 1.40 installation.
Steps to duplicate:
FacesExtendableException: There is no method process for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of /data/all/006/commerce-1.40-7.41.1/profiles/commerce_kickstart/modules/rules/includes/faces.inc).
Workaround (commerce_kickstart specific, I think):
Comment #57
velpan CreditAttribution: velpan commentedWow! Thank mrP! Save my life.
Comment #58
Collins405 CreditAttribution: Collins405 commentedI just ran into this...
FacesExtendableException: There is no method getElementName for this instance of the class RulesLoop. in FacesExtendable->__call() (line 133 of /var/www/html/sites/all/modules/rules/includes/faces.inc).
So i disabled all rules on the site, flushed cache, ran cron, accessed the site, and still the same error on a WSOD.
Reporting it here in case anyone has a fix while i look into it further.
Comment #59
Collins405 CreditAttribution: Collins405 commentedI've disabled rules module, site working fine, re-enabled and WSOD again.
I'm on php 7, and I've tried upgrading rules to the rules dev version, still WSOD.
Comment #60
Collins405 CreditAttribution: Collins405 commentedGot it, i had this rule....
{ "commerce_cart_expiration_delete_expired_carts" : {
"LABEL" : "Delete expired carts \u0026 increase stock",
"PLUGIN" : "reaction rule",
"OWNER" : "rules",
"REQUIRES" : [ "commerce_cart_expiration", "commerce_ss" ],
"ON" : { "commerce_cart_expiration_cron" : [] },
"DO" : [
{ "commerce_cart_expiration_delete_orders" : { "interval" : 480, "limit" : "100" } },
{ "LOOP" : {
"USING" : { "list" : [ "site:current-cart-order:commerce-line-items" ] },
"ITEM" : { "list_item" : "Current list item" },
"DO" : [
{ "commerce_ss_increase_by_line_item" : { "commerce_line_item" : [ "list-item" ] } }
]
}
}
]
}
}
For some reason this was causing the error, Ive posted it incase it helps anyone else.
Comment #61
vtamas CreditAttribution: vtamas commented@ Collins405,
Could you specify which PHP 7 version you had?
Comment #62
BerdirAlso had a version of this with method "process". In my case it turned out to be due to a rule being invoked during early-bootstrap (watchdog) due to a php warning/error caused with an incompatibility between rules and a core patch : #2977485: Avoid use of system_list('module_enabled') call in _rules_discover_module() for compatibility with core patch
Comment #63
morybel CreditAttribution: morybel commentedI have no idea what started it all for me, but after 5 hours of investigating and reading every single post about this problem I decided to update both Rules and Commerce to their latest dev versions, rules 7.x-2.x-dev and commerce 7.x-1.x-dev but none of those repaired my site. (I completely removed Rules conditional also. )
When I disable Payment (from the commerce module) I can open Rules. But when Payment is enabled, this is when I get the message
FacesExtendableException: There is no method getElementName for this instance of the class RulesConditional. in FacesExtendable->__call() (line 133 of /modules/contrib/rules/includes/faces.inc). AND cannot access Rules at all!!!
This is what I did to fix it:
- Disabled and uninstalled Payment from the Commerce suite (Payment and Payment UI)
- Disabled and uninstalled all other payments method that needed payment (Paypal, Payment by check, Payment sample, etc..)
- Deleted all rules using Payment one by one. (They were all broken)
- Installed back Payment from Commerce
- Installed back all other payments methods (Paypal, Payment by check, Payment sample, etc..) (This is forcing Drupal to recreate the rules).
And voila! Everything now work as expected so far so good, fingers crossed it's not coming back. Nasty bug if you ask me!
Comment #64
Jens Peter CreditAttribution: Jens Peter commentedI had the same error.
My error was caused by a rule set by Quickpay Payment for Commerce.
I was not able to get on to the site at all - just the wsod.
I knew the error happened while setting the Quickpay rule, so after reading here, I took a chance and focused on this module and rules.
My solution was:
- logged into the database.
- disabeled the Quickpay module
- site got back online again but I could not get to
/admin/config/workflow/rules
and/admin/commerce/config/payment-methods
- i ran update.php - got the same error again
- back on the database I deleted all rules related to the Quickpay module
And the site worked again and I could get into all parts.
At the time I got the error none of the rules related to the Quickpay module was active.
Comment #65
PaulDinelle CreditAttribution: PaulDinelle at Fenix Solutions Inc commentedRan into this error today. We used
drush rr
to rebuild the registry, and that seemed to solve it for us? Hope this helps someone else!Comment #66
benjarlett CreditAttribution: benjarlett commentedFor me I found replacing the (only two rules) on my site that I had that were using rules from Conditional Rules (rules_conditional) module with ones that I found I could implement a different way and disabling Conditional Rules allowed me to upgrade and not have this error.. a sidestep that maybe demonstrates the problem could be with the Conditional Rules module or the interaction between that and Rules. I don't have any answers really just a way round. I struggled with this a lot before finding this as a way round. Some of the helpful comments above got me to this solution, thanks!
Comment #67
Ananda CreditAttribution: Ananda commentedHi,
This issue just reappeared out of the blue, I have all latest modules and Commerce installed.
Dirty but genius solution #22 fixed it for me !
I just commented out the line 135 on profiles/commerce_kickstart/modules/contrib/rules/includes/faces.inc with //
// throw new FacesExtendableException("There is no method $name for this instance of the class $class.");
Now the site is working again ( for now ... ;)
Comment #68
earthangelconsulting CreditAttribution: earthangelconsulting commentedi just upgraded from Drupal 7.67 to 7.77 (on php 7.3.25 ) and i can confirm what was said in #67, this is still a problem! i am running Rules 7.x-2.12
the solution from #22, as much of a "hack" as it might be, worked for me too.
can this possibly be fixed in the next release of Rules?
(i looked at the latest dev Release, from Mar 15 2020, and there are no changes to faces.inc other than one documentation change... so i am pretty sure this isn't fixed yet!)
Comment #69
earthangelconsulting CreditAttribution: earthangelconsulting commentedto be clear, the upgrade of Drupal from 7.67 to 7.77 wasn't what caused this error message to start happening, we were doing the upgrade because the hosting company pushed the php version up to 7.3.25 without warning.
Comment #70
Chase. CreditAttribution: Chase. commentedI ran into this issue as a result of a seemingly unrelated issue with a deprecation warning in PHP 8.1: Issue 2483729
Comment #71
rclemings CreditAttribution: rclemings commentedOne more data point: On upgrading from PHP 7.4 to PHP 8.1. I began seeing this error on cache clear. WSODs all over, including the front page and everything that touches rules.
I'm still investigating but I think I found a clue (in this case) in the cache_rules table.
After the WSOD error, there are no records in that table except for "data:en" and it is incomplete.
If I rebuild the rules cache from /admin/config/workflow/rules/settings/advanced, everything appears to work fine and the cache_rules table is populated with several dozen records.
I compared the "data:en" record after a cache clear to the same record from an /admin/config/workflow/rules/settings/advanced rules cache rebuild. The [data_info] element is identical. The bad (cache clear) version then just ends abruptly with an empty [plugin_info] array.
At this point, I don't know what the best fix might be -- maybe hack the cache clear code to skip the rules cache? -- or what the underlying cause is.
Significantly, though, I did not see this problem in PHP 7.4, and I did not see it in PHP 8.1 until I moved from my development laptop to my test server (VPS). This makes me think there may be some difference(s) in the PHP settings that is(are) causing an incomplete cache rebuild.
I do have about 100 rules and rules components on this site, so an out-of-memory or similar problem wouldn't surprise me.
Comment #72
Chase. CreditAttribution: Chase. commentedDo you have watchdog entries on PHP 8.1 that you don't have on PHP 7.4? Because for me that was causing the issue: A deprecation notice concerning a string function. Nothing else was different, because the string function still returned the same value as on PHP 7.4. Just the notice broke everything, it seems.
Comment #73
rclemings CreditAttribution: rclemings commentedOnly one that isn't triggered by the cache clear, and fixing it doesn't change anything.
Comment #74
rclemings CreditAttribution: rclemings commentedSpoke (typed) too soon -- this patch seems to have fixed everything.
https://www.drupal.org/project/variable_email/issues/3308465
Still not sure I understand why, including why it didn't happen on my devel laptop. Maybe because the service is faster and there's some kind of race condition?
Comment #75
Chase. CreditAttribution: Chase. commentedMaybe different logging settings between your machines?
When migrating to PHP 8.1 I've come across a lot of different issues because includes didn't work due to deprecation notices. You would think a notice is just logged and everything continues working as long as the called functions return the same values as under PHP 7.4 - which all the string functions I came across do.
Comment #76
freeform.steph CreditAttribution: freeform.steph commentedAfter switching to PHP 8.1 we got hit with this. Rebuilding the rules cache as mentioned in #71 was the fix for us.