[META] Fully support PHP 7.4 in Drupal 7

As PHP7.3 support is almost ready, I went ahead a bit and run tests using the latest D7 core against PHP7.4-beta4. The only patch I've added was from #3025335-3: session_id() cannot be changed after session is started

... and most of the tests fail - there are 199303 exceptions :) Actually, it's not that bad: 187911 of them are PHP notices in a single line of common.inc in element_children()

Then I've analyzed those exceptions and here is the document: https://docs.google.com/spreadsheets/d/1ROyMySRs8atpSc3dIPHCM9O2EZivNvJo...

Stay tuned for the issues!

Patch fixing some small misc issues attached

Updated patch attached:

1. Typo in NumberFieldTestCase causes PHP7.4 notice "Trying to access array offset on value of type null" in _field_write_instance() - number_float field formatter does not exist

- 'type' => 'number_float',
+ 'type' => 'number_decimal',

2. Trying to access NULL value as array in forum_get_topics()

$forum_topic_list_header = array(
  NULL,
  array('data' => t('Topic'), 'field' => 'f.title'),
  array('data' => t('Replies'), 'field' => 'f.comment_count'),
  array('data' => t('Last reply'), 'field' => 'f.last_comment_timestamp'),
);

$order = _forum_get_topic_order($sortby);
for ($i = 0; $i < count($forum_topic_list_header); $i++) {
  if ($forum_topic_list_header[$i]['field'] == $order['field']) {
    $forum_topic_list_header[$i]['sort'] = $order['sort'];
  }
}

- for ($i = 0; $i < count($forum_topic_list_header); $i++) {
+ for ($i = 1; $i < count($forum_topic_list_header); $i++) {

3. The array and string offset access syntax using curly braces is deprecated in SearchQuery::parseSearchExpression()

- if ($match[2]{0} == '"') {
+ if ($match[2][0] == '"') {

4. Typo in taxonomy_update_7004() causes PHP7.4 notice "Trying to access array offset on value of type null" in _field_write_instance() - select field formatter does not exist

- 'type' => 'select',
+ 'type' => 'options_select',

This code does work only due to Options module is doing:

$type = str_replace('options_', '', $instance['widget']['type']);

in options_field_widget_form(), ie it does not matter whether it's select or options_select

.. and that's it - with all listed children issues + #3025335-3: session_id() cannot be changed after session is started + #3081386-5: [META] Fully support PHP 7.4 in Drupal 7 (patch from this issue) D7 was able to pass all the tests with PHP7.4-beta4

Attaching combined patch (just for testing purposes)

@joseph.olstad seems like PHP7.4 testing is stuck in Queueing mode forever; probably, someone needs to take a look at DrupalCI setup?

Hello everyone, thanks for working on this php 7.4.x compatibility issue.
I've created an issue in the drupalci_testrunner queue.
Please followup here:

#3085368: Tests queued for 7 days before finally running when testing Drupal 7 with PHP 7.4

if we ever want to get traction on this issue someone new will have to become maintainer of Drupal core 7.x

#3086286: Offering to maintain Drupal core (@joseph.olstad)

we should have had a 7.68 release by now with the fix from
#3025335-3: session_id() cannot be changed after session is started

(among others)

great work so far @Taran2L , the tests finally completed, only 6 fails!

Hi @joseph.olstad, thanks for pushing this. On my local machine, all tests were green ... and I've figured out why: one patch is outdated and one is missing. Find new combined patch attached

so, there is one fatal error preventing test to be completed: seems like PHP7.4 throws PHP fatal error when trying to cast stdClass object into a string, but cannot find this change record

Updates:

• Found small issue in run-tests.sh script on PHP7.4
• And missing custom assert message was causing 2 fails on PHP5.3 :)

... and the new combined patch (should be all green 5.3-7.4)

.. and hopefully the last one :)

YAY!

wow, very awesome!!!

So, what next?

Cool! 😎

Okay, the various fixed patch should be updated to incorporate changes already available in the combined version

@joseph.olstad I guess someone needs to RTBC patches (most of them are super small and obvious) and then we need to push core team to have them committed (easier to day than do I think)

@Taran2L I guess we should move the "various fixes" to a separate issue since this issue is a Plan.

@sjerdo the various fixes are already in seperate issues:

#3084935: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array
#3084943: Pass parameters as implode($glue, $pieces); reverse order is deprecated
#3084945: Trying to access array offset on value of type null in _batch_finished()
#3084953: Trying to access array offset on value of type null in _drupal_build_css_path()
#3084955: Invalid characters passed for attempted conversion, these have been ignored in _color_unpack()
#3084961: Trying to access array offset on value of type null in theme_pager/pager_first/pager_last/pager_previous/pager_next()
#3084965: Trying to access array offset on value of type bool in search_excerpt()
#3084980: Trying to access array offset on value of type null in path_delete()
#3085088: menu_get_item() might return FALSE; calling code should take account of this
#3085098: PHP Phar Stream Wrapper should be updated (PHP7.4 support, drop fileinfo dependency)
#3085148: Fix field_test_field_attach_delete_bundle()
#3085151: field_ui_display_overview_form() expects to always get an array from field_info_formatter_types()
#3085163: Comment module causes PHP 7.4 Notices on uninstall
#3087121: SystemValidTokenTest is failing on PHP 7.4 when drupal_hmac_base64() is called incorrectly

@joseph.olstad, I believe @sjerdo would like to move patch from #22 into the separate issue and leave this one with combined version only. Totally fine with that

@Taran2L Actually, no. This issue is a plan, which don't need any patch, not even a combined one.
The related issue contains the patches, and those patches will be committed, one by one. Core maintainers will not commit a combined patch.

In the past, to make it clearer, [META] was added at the beginning of the issue title.

See comment #6.

I think it is best if we keep this issue for overall tracking and have all patches in child issues about specific issues.

php 7.4 compatibility patches are also 'almost' ready D8.9.x

Please continue reviewing the related D7 issues for php 7.4.x compatibility.

Thank you

Amazing work Taran2L, thanks again!

@Taran2L great work.

PHP 7.3 is working nicely now with core 7.69

Looking forward to getting your patches into the 7.x-dev branch so that we can give it a good head start on readiness with contrib testing and the rest.

OK, team! :)

Let's get @Taran2L code added to drupal core, so the community can benefit from PHP 7.4!

Thanks, everyone.

You're all doing excellent work.

Retitle for accuracy. Looks like various issues still need review and some are needs work. Updated issue summary, and transported list of child issues from #25 to issue summary for possibly easier scanning.

@Gábor Hojtsy

Could you/someone and @kiamlaluno have a discussion please?

He goes through and removes "in Drupal 7" from a load of issues, you and other go and add them back in.

Personally I don't see the point of it, the version filter is there for a reason, but either way can we come to a consensus on this?

The version filter is indeed useful on drupal.org. However consider when the issue is shared on Slack, social media (eg. https://twitter.com/gaborhojtsy/status/1224614436566114304) or even linking from issue comments, such as #3081386: [META] Fully support PHP 7.4 in Drupal 7 or in the sidebar related issues list. There is no indication of the Drupal major version it relates to in those cases.

In cases like this where the issue applies to all currently supported major versions of Drupal and they have different drupal.org issues to fix the problem, I strongly believe including it in the title is important. That said, I'll not go after @kiamlaluno to fix whatever he was updating :)

1+ for added clarity by including "... in Drupal 7"

Anyone here know how we go about getting some of the patches in the child tickets committed? Do they need more review or attention from a core committer (If so how do we get such attention?)

@Steven Jones it depends, there is definitely a bunch of issues that still need review (in the issue summary the ones that are not green). I count five of them. The ones that are green would need a Drupal 7 committer review. That said, verifying you agree it works and is a good solution would help to make it more likely to be committed faster.

We got a new core maintainer a few months back, but it's all gone quiet again.

Fork

| | | |
| | | |
\ | | /
  | |
   I
   I
   I

I met Drew (new D7 maintainer) at FOSDEM, and he mentioned he's currently busy with some exams and will attend the issues after.

Let's all remember there's https://www.drupal.org/core/drupal7-roadmap-release-schedule#release-sch... which clearly outlines the release schedule for Drupal 7 going forward. The next release is scheduled for 2020-06-03 and I'm sure core committers will ensure D7 is compatible with PHP 7.4 then.

Thank you for all the work that's gone into this so far. It's definitely the goal to get this into the next release (due 2020-06-03).

This is a no-op patch which we can use to test 7.x-dev with PHP 7.4 - we can then compare the test run with those for patches in individual issues to verify whether the patch fixes particular test failures.

I'm still trying to work out whether this is a good methodology when the test results are initially so noisy, but here's one way of seeing the exceptions from the failing PHP 7.4 test for the no-op patch in #49:

$ curl -s https://www.drupal.org/pift-ci-job/1601005 | grep -o 'exception: .* Line [0-9]* of .*:' | perl -pe 's#<.*?>##g' | sort | uniq -c | sort -rn 

 189257 exception: [Notice] Line 6656 of includes/common.inc:
   8661 exception: [Deprecated function] Line 394 of includes/common.inc:
   1132 exception: [Deprecated function] Line 740 of modules/color/color.module:
    549 exception: [Notice] Line 1175 of modules/search/search.module:
    106 exception: [Notice] Line 564 of includes/pager.inc:
    106 exception: [Notice] Line 528 of includes/pager.inc:
     79 exception: [Notice] Line 487 of includes/batch.inc:
     53 exception: [Notice] Line 565 of includes/pager.inc:
     53 exception: [Notice] Line 531 of includes/pager.inc:
     53 exception: [Notice] Line 529 of includes/pager.inc:
     53 exception: [Notice] Line 489 of includes/pager.inc:
     53 exception: [Notice] Line 459 of includes/pager.inc:
     53 exception: [Notice] Line 359 of includes/pager.inc:
     53 exception: [Notice] Line 337 of includes/pager.inc:
     53 exception: [Notice] Line 331 of includes/pager.inc:
     48 exception: [Notice] Line 475 of includes/path.inc:
     47 exception: [Notice] Line 266 of modules/block/block.module:
     35 exception: [Notice] Line 3743 of includes/common.inc:
     26 exception: [Notice] Line 782 of modules/field/field.crud.inc:
     16 exception: [Notice] Line 926 of modules/forum/forum.module:
     16 exception: [Notice] Line 460 of modules/field/tests/field_test.storage.inc:
     13 exception: [Notice] Line 781 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 774 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 773 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 772 of modules/field/field.crud.inc:
      7 exception: [Notice] Line 481 of modules/image/image.module:
      7 exception: [Notice] Line 480 of modules/image/image.module:
      6 exception: [Deprecated] Line 304 of includes/filetransfer/filetransfer.inc:
      4 exception: [Notice] Line 2494 of includes/menu.inc:
      4 exception: [Notice] Line 2488 of includes/menu.inc:
      2 exception: [Notice] Line 2490 of includes/menu.inc:
      2 exception: [Notice] Line 1088 of modules/field_ui/field_ui.admin.inc:
      2 exception: [Notice] Line 1029 of modules/field_ui/field_ui.admin.inc:
      1 exception: [Warning] Line 45 of modules/simpletest/tests/error_test.module:
      1 exception: [User warning] Line 47 of modules/simpletest/tests/error_test.module:
      1 exception: [Notice] Line 633 of modules/field/field.crud.inc:
      1 exception: [Notice] Line 617 of modules/field/field.crud.inc:
      1 exception: [Notice] Line 43 of modules/simpletest/tests/error_test.module:

(Please try not to hammer the drupal.org CI infra with excessive requests etc..)

That list seems fairly useful e.g. to compare with the test results for individual patches to confirm that they resolve individual items on the list e.g.:

• #3084935-31: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array
• #3084955-9: Invalid characters passed for attempted conversion, these have been ignored in _color_unpack()

I'm also looking at the list to give us a hint for prioritisation; starting at the top seems like it makes some sense.

Hopefully we'll see the list get shorter as start committing the fixes.

We've just committed 4 patches which should resolve several of the Notices / fails in the PHP 7.4 tests.

There's certainly still more to do though.

Here's another very similar no-op patch; with any luck the PHP 7.4 test for this should look a little better (and can be used to compare patches in the sub issues as we continue to work on them).

sh: 1: -t: not found

Erm.. :) I'll chase this up on Monday with the d.o infra team.

Keep up the great work!
Note, there's a problem with the test runner, but this shouldn't slow you down from the progress here. If you need, I could set up an test environment for you with simpletest and shell access?

I've noted in this issue:
#2997871: D7 testing broken

Thanks for the offer @joseph.olstad - looks like it was a short-lived blip though.

Looks like we've gone from 2,031 pass, 886 fail in #49 to 2,049 pass, 119 fail in #52.

Progress.

Much better, only 119 to go! :)

@mcdruid I really like how you approach this! Great job!

We ended up reverting #3084935: element_children() and DrupalRequestSanitizer::stripDangerousValues() should not use integer keys as array because it broke PHP < 5.6 but a new fix has just been committed there which should keep everything from PHP 5.3 to 7.4 happy (although we're not done with the 7.4 fixes yet).

Here's another no-op patch to confirm what condition our condition is in.

Nice work, looks like only 1 fail out of 2050, according to the test results 2051 passes on all the earlier versions and 2050 passes on 7.4.x. For kicks I triggered 5.4 and 5.5

It's good that we're making progress.

A bit strange that there are a few test fails on PHP 5.4 but I don't think we need be concerned; we discussed this in #3092260: [policy, no patch] Review and update automated testing config for 7.x branch and I don't think 5.4 is a version we need to test on.

If anyone disagrees with that, let's please discuss in that other meta issue on testing rather than here. Thanks!

@Liam Because the patch have been re-tested for PHP 5.4. (See comment #61.)

I guess it depends from how the environment test has been selected. Since the tests were run for PHP 5.4 and 5.5, it could be Retest […] was not used in this case.

@kiamlaluno @Liam Morland I've pressed the button; and yes, a retest button was not available, so I've used custom parameters option which (it seems) does not replace the previous run; however it's the same environment, see https://www.drupal.org/pift-ci-job/1617927 and https://www.drupal.org/pift-ci-job/1618682 both lead to the same page

Here are the counts of exceptions from the PHP 7.4 test in #60:

$ id='1617902' ; curl -s https://www.drupal.org/pift-ci-job/$id | grep -o 'exception: .* Line [0-9]* of .*:' | perl -pe 's#<.*?>##g' | sort | uniq -c | sort -rn
    549 exception: [Notice] Line 1175 of modules/search/search.module:
     79 exception: [Notice] Line 487 of includes/batch.inc:
     48 exception: [Notice] Line 475 of includes/path.inc:
     47 exception: [Notice] Line 266 of modules/block/block.module:
     35 exception: [Notice] Line 3743 of includes/common.inc:
     26 exception: [Notice] Line 782 of modules/field/field.crud.inc:
     16 exception: [Notice] Line 926 of modules/forum/forum.module:
     16 exception: [Notice] Line 460 of modules/field/tests/field_test.storage.inc:
     13 exception: [Notice] Line 781 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 774 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 773 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 772 of modules/field/field.crud.inc:
      7 exception: [Notice] Line 481 of modules/image/image.module:
      7 exception: [Notice] Line 480 of modules/image/image.module:
      4 exception: [Notice] Line 2494 of includes/menu.inc:
      4 exception: [Notice] Line 2488 of includes/menu.inc:
      2 exception: [Notice] Line 2490 of includes/menu.inc:
      2 exception: [Notice] Line 1088 of modules/field_ui/field_ui.admin.inc:
      2 exception: [Notice] Line 1029 of modules/field_ui/field_ui.admin.inc:
      1 exception: [Notice] Line 633 of modules/field/field.crud.inc:
      1 exception: [Notice] Line 617 of modules/field/field.crud.inc:

Working from the top of that list, I think the next 5 issues to tackle would be:

• #3084965: Trying to access array offset on value of type bool in search_excerpt()
• #3084945: Trying to access array offset on value of type null in _batch_finished()
• #3084980: Trying to access array offset on value of type null in path_delete()
• #3085088: menu_get_item() might return FALSE; calling code should take account of this (n.b. this is a bigger patch than many of the other issues)
• #3084953: Trying to access array offset on value of type null in _drupal_build_css_path()

Just committed those 5 patches from #69

Here's another no-op patch to see what we still have left to do for PHP 7.4 in D7.

Updating the IS.

The list is getting shorter:

$ id='1640782' ; curl -s https://www.drupal.org/pift-ci-job/$id | grep -o 'exception: .* Line [0-9]* of .*:' | perl -pe 's#<.*?>##g' | sort | uniq -c | sort -rn

     26 exception: [Notice] Line 782 of modules/field/field.crud.inc:
     16 exception: [Notice] Line 926 of modules/forum/forum.module:
     16 exception: [Notice] Line 460 of modules/field/tests/field_test.storage.inc:
     13 exception: [Notice] Line 781 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 774 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 773 of modules/field/field.crud.inc:
     13 exception: [Notice] Line 772 of modules/field/field.crud.inc:
      7 exception: [Notice] Line 481 of modules/image/image.module:
      7 exception: [Notice] Line 480 of modules/image/image.module:
      2 exception: [Notice] Line 1088 of modules/field_ui/field_ui.admin.inc:
      2 exception: [Notice] Line 1029 of modules/field_ui/field_ui.admin.inc:
      1 exception: [Notice] Line 633 of modules/field/field.crud.inc:
      1 exception: [Notice] Line 617 of modules/field/field.crud.inc:

👍🏽 awesome, thank you. #3118301: Curly brace syntax for accessing array elements and string offsets has been deprecated in PHP 7.4 looks quite straight forward too.

@mcdruid, excellent work, I am asking you or @Fabianx to please add an automated test on commit for php 7.4 on the Drupal 7 dev branch here: https://www.drupal.org/node/3060/qa

This will help us indicate how many tests are succeeding. ** Edit, I just noticed the patch to this issue for tests, only 20 left to go, still would be a good idea to have the test enabled **

@joseph.olstad the plan is to enable automatic testing on PHP 7.4 when we're happy that the 7.x branch should pass.

Looking at the remaining exceptions from the last round of tests, I think these are the next issues to tackle (one is a new one I've filed for the forum module - if there's already an issue for this, we'll close one as a dupe - I'll add this to the IS):

• #3085163: Comment module causes PHP 7.4 Notices on uninstall
• #3125824: Trying to access array offset on value of type null in forum_get_topics()
• #3085148: Fix field_test_field_attach_delete_bundle()
• #3085151: field_ui_display_overview_form() expects to always get an array from field_info_formatter_types()

That's not yet all of the outstanding children of this issue; it'd be interesting to see what tests look like with these 4 resolved, as they look like they account for most if not all of the remaining exceptions/notices.

Actually, there are more small issues. Originally there was a patch (see #22) fixing those smaller items. I completely forgot to put them into separate issues (some of them now have separate issues):

1. #3118301: Curly brace syntax for accessing array elements and string offsets has been deprecated in PHP 7.4
2. #3125824: Trying to access array offset on value of type null in forum_get_topics()
3. NumberFieldTestCase uses non-existing formatter number_float => number_decimal (line 178 of modules/field/modules/number/number.test)
4. taxonomy_update_7004() uses non-existing widget select => options_select (line 452 of modules/taxonomy/taxonomy.install)
5. there is another PHP notice trying to access array offset on value of type null in simpletest_script_print(), which is not triggered by any test (line 733 of scripts/run-tests.sh)

UPDATE:

Added 3 new issues addressing items 3-5 from the list above:

• #3126133: NumberFieldTestCase uses non-existing formatter number_float
• #3126138: taxonomy_update_7004() uses non-existent widget select
• #3126140: PHP 7.4 notice in run-test.sh

added #3126312: Since PHP 7 func_get_args() no longer reports the original value as passed to a parameter, so call it early

added #2788565: sample code for callback_filter_process() and callback_filter_prepare() should not include deprecated regex option

Thanks for adding all of those.

I've been working on #3085163: Comment module causes PHP 7.4 Notices on uninstall which ended up being a bit of a rabbit hole.

In the process, I've started to address a small handful of the several exceptions from field.crud.inc and image.module - these mostly look pretty similar and are a result of e.g. $field's being passed around by hooks etc.. where $field is either not an array at all or doesn't include expected elements such as $field['type'].

In a quick review of the remaining child issues we have in this issue, I've not found patches which address the exceptions in field.crud.inc and image.module so I'm going to file a new issue which lists all of them and work on a patch.

Couple of thoughts though:

1. Am I missing an existing issue / patch which already does this?
2. Do we really want to go through e.g. all of field.crud.inc and defensively avoid addressing array elements which might not exist?

I think that last question is probably one we should discuss in the new issue rather than here.

Created #3129961: Fix $field / $instance exceptions in field.crud.inc and image.module

hi @mcdruid

There are at least 3 other issues related to the Field API:

#3126133: NumberFieldTestCase uses non-existing formatter number_float
#3126138: taxonomy_update_7004() uses non-existent widget select
#3085148: Fix field_test_field_attach_delete_bundle()

Updated IS; 8 more issues moved to Done.

Another no-op patch to see what condition our condition is in, tests wise.

@Taran2L , should those items be added to the issue summary ? see comment #3081386-82: [META] Fully support PHP 7.4 in Drupal 7

oh wow! only 3 to go, nice!

curiously, it still says 2053 passes on both 7.2 and 7.4 test results, interesting!

--nevermind--
Sorry.

We just committed the last 4 on the list in the IS (which I've updated).

With any luck, Drupal 7 now passes tests with PHP 7.4 - (last?) noop patch to verify that.

There are other PHP 7 issues still in the queue in varying states of readiness.

I think we can call this one fixed now though, as tests pass and we've got all the way through the list.

Thanks everyone for all the hard work that's gone into making Drupal 7 compatible with PHP 7.4!

wow, 100% passing, this is great!

🎉🎉🎉🍾 This is great! Thanks to those who submitted issues/patches/feedback and Drew for triaging and applying them to core.

I've switched on automated testing for PHP 7.4 / MySQL 5.5 on D7 core.

so how much more stuff are you going to jam into 7.71 ? There's lots of RTBC to choose from.

Any timeline when this will be pushed to production?

https://www.drupal.org/core/drupal7-roadmap-release-schedule#release-sch...

@mcdruid Thank you.

So, with enormous thanks to all contributors, we can expect the new release on 2020-06-03 with all those patches?

It would be great!!!!

:-)

@eliosh if you want to help out, send contact messages to all contrib module maintainers
now is the time to push contrib maintainers to add php 7.4 automated tests on commit for each project, so that we can test contrib , modules like views for instance currently only testing up to php 7.3.x.

Now that we have php7.4 support, any ideas which files to add to opcache preload?

I'm not finding any information online about this. :(

Opcache preloading is better to be outside the scope of this ticket, or let alone Drupal because it's something not easily done in a way that suits everyone.

I maintain Composer Preload (https://github.com/Ayesh/Composer-Preload) that has support for all projects. Your Drupal site doesn't even have to meaningfully use Composer.
Generally speaking, all `.php`, `.inc`, and `.module` files in `./includes`, `./modules`, `./sites/all/modules`, and your theme directory are better preloaded.

#3151810: D7.71: Array and string offset access with curly braces is deprecated in PHP 7.4

Another PHP 7.4 issue at #3155357: menu tree output() notice after upgrade to php 7.4 with core 7.72

@Taran2L

wondering if you can do for PHP 8 , what you did for PHP 7.4 ?

PHP 8 support:

#3145797: [META] Make Drupal 7 core compatible with PHP 8.0

@joseph.olstad, as far as I can see there is not that much work :)

anyway, seems like the drupal.org test bot cannot run PHP8 + D7, right?

No, it is possible to run php 8 testing

Also, I wouldn't really call Drupal 7 on PHP 8 as "there is not that much work".
I could not get Drupal 7 to run in PHP 8 at all, until #3185918: [PP-1] [PHP 8] Fix DatabaseConnection::query signature mismatch with PDO::query is fixed. Unfortunately, I am afraid more major issues are yet to be discovered in the first place. It would be a massive feat to have Drupal 7 working with PHP 5.3, 7.x, and 8.0 working, and with D7's EOL extended by two years, I think it will be a lot of work.

Drupal 7 will run on PHP 8. Taran2L will work his magic again, and if not him, someone else will come through for us.

@joseph.olstad: the matter of fact is @Ayesh has been working on #3145797: [META] Make Drupal 7 core compatible with PHP 8.0 for half a year (alongside Liam Morland). Would be great to continue the PHP 8 discussion there.