See https://wiki.php.net/rfc/named_params and scroll down to call_user_func_array().

call_user_func_array() is used by Rules core to invoke conditions/actions, which each define their own set of context variables that need to passed in as parameters.

Core dealt with this in #3174022: call_user_func_array() and named arguments in PHP 8.

I opened this as a separate issue from #3210303: PHP 8 introduced breaking change to call_user_func_array() because, although the cause is the same, the affected code is quite different in D7 than it was in D8. So the solution is not a backport of the D8 solution, it is a different solution in a different part of the codebase.

However, #3210303: PHP 8 introduced breaking change to call_user_func_array() does include some discussion of the problem which is also relevant.

CommentFileSizeAuthor
#5 3210622-5.patch1.5 KBtr
#2 3210622-2.patch739 bytestr

Comments

TR created an issue. See original summary.

tr’s picture

Status: Active » Needs review
StatusFileSize
new739 bytes

The relevant errors shown in the test output https://www.drupal.org/pift-ci-job/2039308 are:

4	Rules.RulesSchedulerTestCase
✓		-setUp
✗	
__call
exception: [Error] Line 132 of sites/all/modules/rules/includes/faces.inc:
Unknown named parameter $settings

exception: [Error] Line 132 of sites/all/modules/rules/includes/faces.inc:
Unknown named parameter $settings

These occur in the faces code, which is specific to the D7 version of Rules. And as faces is a lot more dynamic than other parts of the code, here's a small patch which should help without major structural changes.

tr’s picture

Title: [D7[ PHP 8 introduced breaking change to call_user_func_array() » [D7] PHP 8 introduced breaking change to call_user_func_array()
tr’s picture

tr’s picture

StatusFileSize
new1.5 KB
tr’s picture

#5 seems to have worked to solve the problems that show up in our tests. There are several other usages of call_user_func_array() in the codebase that don't cause test failures, perhaps because the tests might not cover those usages. Those usages are found in path.eval.inc, rules.module, and rules.state.inc. To find out if these are a problem, someone will have to try to exercise those pieces of code manually on a D7 site with PHP 8 installed. If they ARE a problem, then it would be ideal if we could add the missing test coverage.

My thought is we should just commit #5 now and leave this issue open to see if someone encounters a problem with one of those other usages.

liam morland’s picture

I have reviewed the code. This will fix the problem without any side-effects.

liam morland’s picture

Title: [D7] PHP 8 introduced breaking change to call_user_func_array() » [D7] PHP 8.0 introduced breaking change to call_user_func_array()
Issue tags: +PHP 8.0

  • TR committed 84eceda on 7.x-2.x
    Issue #3210622 by TR: [D7] PHP 8.0 introduced breaking change to...
tr’s picture

Status: Needs review » Fixed

Committed #5.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

joseph.olstad’s picture

as per

#3221001-13: Plan for release of 7.x-1.10

Please tag and release rules 7.x-2.x

joseph.olstad’s picture

there's a chain of events that have to happen for us to resolve file_entity and media module php 8.0 automated test passing as media relies on file_entity, which in turn automated tests depend on the entity api which in turn relies on rules for it's automated test coverage dependency.

so , in this order:

  1. Tag and release rules 7.x-2.x branch for new tag #3210622: [D7] PHP 8.0 introduced breaking change to call_user_func_array()
  2. confirm that the new rules release fixes automated testing then Tag and release entity api 7.x-1.x branch for new tag for 7.x-1.10 #3221001: Plan for release of 7.x-1.10
  3. Confirm that the new entity api build fixes file_entity automated testing (test dependency) and then tag 7.x-2.x/7.x-3.x branch for new file_entity release #3208277: PHP 8 compatibility for file_entity
  4. confirm that the new file_entity release fixes media php 8.0 automated test coverage , review if anything needs adjusting in the media module #3208029: PHP 8.0 compatibility for Media
  5. Follow up with the core issue for php 8.0, if everything looks good, mark this issue as fixed: #3145797: [META] Make Drupal 7 core compatible with PHP 8.0
  6. Then continue working on making drupal core php 8.1 compatible #3224299: [META] Make Drupal 7 core compatible with PHP 8.1