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?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

westbywest’s picture

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

Drupal 7.7
Entity API 7.x-1.0-beta10

fago’s picture

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?

dboulet’s picture

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.

fago’s picture

Status: Active » Postponed (maintainer needs more info)
jackalope’s picture

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.

mikl’s picture

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

mikl’s picture

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).
mikl’s picture

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).

mikl’s picture

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?

Johnny vd Laar’s picture

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?

DuaelFr’s picture

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

khan2ims’s picture

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

mikl’s picture

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:


/**
 * 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).).

DuaelFr’s picture

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.

fago’s picture

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.

AdamGerthel’s picture

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

eric-ie’s picture

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.

mdixoncm’s picture

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 ...

mdixoncm’s picture

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;
            }
}
Michael-IDA’s picture

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

patrickd’s picture

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

Johan_s’s picture

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.

patrickd’s picture

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?

rogerpfaff’s picture

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.

paulbuk’s picture

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.

007pig’s picture

subscribe

mitchell’s picture

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

Please try with the latest versions and report back.

tevih’s picture

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.

tevih’s picture

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.

DuaelFr’s picture

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 ;)

plach’s picture

Component: Rules Engine » Rules Core
Status: Postponed (maintainer needs more info) » Needs review
FileSize
659 bytes

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 ;)

fago’s picture

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?

plach’s picture

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 :)

davea’s picture

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

jackdaniel9’s picture

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

dude74’s picture

fago’s picture

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.

Marc Storms’s picture

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.

Summit’s picture

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

greggadsdon’s picture

Issue summary: View changes

I'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.

pyry_p’s picture

For 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

fox_01’s picture

Conditions inside the payment rules will cause this error. I moved my conditions from the actions section to the conditions section of the rule

blattmann’s picture

Upgrading 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.

marcelovani’s picture

Patch #31 works for me, I would recommend committing it.

geek-merlin’s picture

Version: 7.x-2.3 » 7.x-2.x-dev

My 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?

marcelovani’s picture

el_reverend’s picture

Experiencing the same issue on a commerce site (d7.34 / Commerce (kit) 1.9, commerce_views_display 1.0).

WD php: FacesExtendableException: There is no method process for this instance of the class RulesAction. in FacesExtendable->__call() (line 133 of [error]
/var/www/html/mysite.com/public/sites/all/modules/rules/includes/faces.inc).
Drush command terminated abnormally due to an unrecoverable error.

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.

my-family’s picture

I 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?

romeof1980’s picture

patch 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

RavindraSingh’s picture

Cann't reproduce the error in 2.9 release. I followed the steps added in #11.

"

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

"

RavindraSingh’s picture

Status: Needs review » Closed (cannot reproduce)
nwoodland’s picture

The tip from #42 fixed this issue for me. Thanks fox_01!!

sujith.nara’s picture

I 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)

arefen’s picture

FileSize
44.1 KB
2.49 KB

Hello. 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:

add conditional for rules in action section
I can't move my conditions to conditions section (42) . and path 31 don't work for me.

RAWDESK’s picture

This patch fixed my issue with this error on payment methods configuration pane :
https://www.drupal.org/node/2500311

mrP’s picture

I can still easily dupe this with a Commerce Kickstart 1.40 installation.

Steps to duplicate:

  1. Install Commerce Kickstart 1.40
  2. drush cc all
  3. Browse to site -- error 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):

  1. Go to admin/config/workflow/rules
  2. Disable all rules
  3. drush cc all
  4. Browse to site -- no FacesExtendableException error
  5. Re-enable all rules
  6. drush cc all
  7. Browse to site -- no FacesExtendableException error
velpan’s picture

Wow! Thank mrP! Save my life.

Collins405’s picture

I 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.

Collins405’s picture

I'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.

Collins405’s picture

Got 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.

vtamas’s picture

@ Collins405,

Could you specify which PHP 7 version you had?

Berdir’s picture

Also 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

morybel’s picture

I 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!

Jens Peter’s picture

I 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.

PaulDinelle’s picture

Ran 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!

benjarlett’s picture

For 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!

Ananda’s picture

Hi,

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 ... ;)

earthangelconsulting’s picture

i 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!)

earthangelconsulting’s picture

to 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.

Chase.’s picture

I ran into this issue as a result of a seemingly unrelated issue with a deprecation warning in PHP 8.1: Issue 2483729

rclemings’s picture

One 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.

Chase.’s picture

Do 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.

rclemings’s picture

Only one that isn't triggered by the cache clear, and fixing it doesn't change anything.

rclemings’s picture

Spoke (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?

Chase.’s picture

Maybe 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.

freeform.steph’s picture

After switching to PHP 8.1 we got hit with this. Rebuilding the rules cache as mentioned in #71 was the fix for us.