[META] Make Drupal 7 core compatible with PHP 8.1

https://github.com/php/php-src/blob/php-8.1.0beta1/UPGRADING the list is not huge

Is there a point to add support of PHP8.1 to D7?

PHP8.0 will be supported until 26 Nov 2023 (a year after D7 end of life), also I think most D7 modules won't be updated. I see that even some of the most popular D7 modules are not updated to PHP8.0 yet.

#6 Yes, I agree with @mcdruid
There are a lot of sites running in D7. It will take time for all the sites to be migrated to D8. Meanwhile, there are many servers that are being upgraded with PHP 8.1. Such D7 code would also need to be run in PHP 8.1.

There are also many projects that have been adapted to D7 for the admin interface and the front sites are built in some other technology. And other technologies require PHP 8.1, so the admin panel may crash.

looks like drush is the first thing that needs patching.

Retitle and mark as plan.

Making the PHP 8.0 issue a related one rather than a parent.

@mcdruid, wow looking great so far! Amazing progress, dropped from 500 errors to only a handful! Very encouraging! One nit, perhaps set the default issue branch test as php 8.0 and MySQL 8 instead of php 7.3 mysql 5.7
?
just a suggestion

I just triggered php 8 and php 7.4 tests on your latest patch to make sure there's no regressions with those versions.

@mcdruid, would seem completely rational to want to commit the above changes as it will make patching easier and allow us to focus on the remaining items. Doesn't seem to cause any regressions at all if you look at the tests, still passing accross the board.

Wow! yes that is a pleasant surprise, appears exactly as you suggest that the remaining issues are in the MySQL specific code.

hi @mcdruid, great job, great job!

Wow thanks @mcdruid!

Thank you @mcdruid! PHP 8.1 is official out, and all pending tests and issues looks green. Are we done?

@mcdruid Thoughts on casting check_plain() $text variable to string?

I'm seeing this on ctools ATM, in the midst of tracking it down but thought I'd ask

exception: [Deprecated] Line 1898 of includes/bootstrap.inc:
htmlspecialchars(): Passing null to parameter #1 ($string) of type string is deprecated

EDIT: to give more context to why I ask, is that I think happening very generically in ctools, for example:

  protected function assertPluginMissingFunction($module, $type, $id, $function = 'function') {
    $func = ctools_plugin_load_function($module, $type, $id, $function);
    $this->assertEqual($func, NULL, t('Plugin @plugin of plugin type @module:@type for @function with missing function successfully failed.', array(
      '@plugin' => $id,
      '@module' => $module,
      '@type' => $type,
      '@function' =>$func,
    )));

Where one of those @ variables in t() is being passed to check_plain as either FALSE or NULL (null in this case). There are probably more places than can be counted. I could probably cast them in the test to make it pass (because I think this is testing missing plugins)

Done #3254699: [D7 PHP 8.1] check_plain(): Passing null to parameter #1 check_plain() includes/bootstrap.inc, line 1907, thanks @mcdruid, added a test but still trying to figure out the workflow for pass/fail patch equivalent to MR...

A merge request for the check_plain() fix is now RTBC including tests.

@mcdruid

I also reviewed the MR in #3254699-5: [D7 PHP 8.1] check_plain(): Passing null to parameter #1 check_plain() includes/bootstrap.inc, line 1907

It's ready for commit.

Thanks!

We have run into another issue with PHP 8.1 and PostgreSQL database: #3258185: [D7 PHP 8.1] Undefined array key "sequence_name" , so I am adding it also here.

Adding another one deprecated warning in PHP 8.1 and Drupal 7.84: #3258313: [D7 PHP 8.1] strlen(): Passing null to parameter #1 ($string) of type string is deprecated in theme_file_upload_help()

Next one PostgreSQL and PHP 8.1 deprecation message: #3259482: [D7 PHP 8.1] fwrite(): Passing null to parameter #2 ($data) of type string is deprecated in InsertQuery_pgsql->execute()

Core tests now pass on PHP 8.1 in Drupal 7. All the issues referred to in this issue are fixed. Is anything else needed or can this issue be marked fixed?

@Liam Morland
Core looks good for PHP 8.1, however the exif_custom module exposed a PHP 8.1 bug in file_entity, I'd appreciate a hand with it.
#3267961: file_entity - PHP 8.1 compatibility

This might expose something deeper down, might be worthwhile to have a look. I've been pushing a few contrib projects to add tests for PHP 8.0 and 8.1 this way we put core through it's paces a bit.

Yes, I have PHP 8.1 testing configured on all my projects. But many don't. Mine all pass except election which is waiting for a fix to date.

What is the criteria for showing Drupal 7 as compatible with a PHP version? I don't think it requires every module to be working, just that none of the problems are in core.

Well, we are currently seeing some another PHP 8.1 deprecated warnings but these are likely caused by 3rd party modules. I do not know if it is worth fixing it on the Drupal core side (thus I have not created the issue for these yet).

Deprecated function: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in drupal_validate_utf8() (line 1936 of /xxx/includes/bootstrap.inc).

Deprecated function: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in filter_xss() (line 1503 of /xxx/includes/common.inc).

These are likely caused by some module sending null to filter_xss() function. We have experienced these on some ajax calls (related to admin views, or views ajax filters), but it needs more testing.

What do you think, it is worth to create Drupal core issue for these to sanitize it on the Drupal core side?

In principle, they should be fixed in each module, but many modules do not get much if any maintenance now. So, it is probably more useful to fix them in core. Still, I don't think this should hold up declaring that Drupal core is compatible with PHP 8.1.

The automated testing in many modules is configured to use old versions of PHP. It would be great to automatically update these to current versions. It would also be helpful to better expose the most recent version that a module passes on.

I think the issue is, hardly anyone is using PHP 8.0 at this moment, let alone PHP 8.1. There's great reasons to want to upgrade to PHP 8.0 however I haven't yet done so (but soon yes). I have a system that can handle multiple versions of PHP but I haven't configured PHP 8.0 and PHP 8.1 on my servers yet.

With that said, I've been fixing issues related to PHP 8.0 relying on the automated test results on Drupal.org.

In time I can see contrib getting more attention as people decide to upgrade to PHP 8.0 and PHP 8.1, just give it some time.

Great work on core from @mcdruid , it's nice to have core in a good state like this. There's work to be done in contrib, not insurmountable but there's still quite a bit to do.

It would be nice if some of us could be granted special privileges to go through contrib and fix PHP 8.1 issues through many many projects. It's time consuming to go through all the processes to be able to do so. With that said, most of the projects I'm responsible for are PHP 8.0 ready and probably not much effort for PHP 8.1, I'm keeping an eye on them.

Currently I have a vestibular neuritis condition so it's been slowing me down for the past month or so. Some other issues dealing with too.

In #3254699: [D7 PHP 8.1] check_plain(): Passing null to parameter #1 check_plain() includes/bootstrap.inc, line 1907 the check_plain() input was cast to string, despite the function being documented as only accepting string - @param string $text - which I'd say sets a precedent that the same should be done for drupal_validate_utf8() and filter_xss() - which are documented as just @param $text and @param $string - i.e. accepting loosely-typed input is even more reasonable for these functions.

Thanks @mfb, good point.

I have created two PHP 8.1 deprecation issues. One was mentioned before (filter_xss() problem) and the second is a new issue which I have run into while working on fix for l10n_update module.

#3270546: [D7 PHP 8.1] str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in filter_xss()

#3270543: [D7 PHP 8.1] preg_split(): Passing null to parameter #2 ($subject) of type string is deprecated in _locale_parse_js_file()

There is another similar deprecation warning in text_summary() also caused by NULL input.

#3270881: [D7 PHP 8.1] strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in text_summary()

Found an issue in Simpletest module reported by @DamienMcKenna also related to the PHP 8/8.1: #3276848: run-tests.sh gives "Deprecated: str_replace(): Passing null to parameter" with PHP 8.0. It seems like an easy fix.

In addition to the last run-tests.sh issue, there is another PHP 8 issue. Patch with backport is ready, already fixed in D9: #3273723: fopen() error in stream_wrappers.inc on PHP 8

We have run into this PHP 8.1 deprecation on one windows environment: #3299271: [D7 PHP 8.1] strlen(): Passing null to parameter #1 ($string) of type string is deprecated in drupal_random_bytes(). Patch attached.

I just RTBC'd the issue 3299271 by @poker10 mentioned in comment #59. Good to go.

Patch needs a reroll. Might be useful to fix this in a fork instead of using attached patches?

Looks like just the 3 RTBM issues left
#3273723: fopen() error in stream_wrappers.inc on PHP 8
#3276848: run-tests.sh gives "Deprecated: str_replace(): Passing null to parameter" with PHP 8.0
#3299271: [D7 PHP 8.1] strlen(): Passing null to parameter #1 ($string) of type string is deprecated in drupal_random_bytes()

Rerolled the patch from #32 and opened a merge request.
Most issues have been solved in separate issues linked to this meta issue.

- In the meanwhile the int conversion fix in the color module from https://www.drupal.org/i/3248752 was reverted in https://www.drupal.org/project/drupal/issues/3249605#comment-14678206
- this issue missed one https://www.drupal.org/project/drupal/issues/3241422#comment-14678213

The change in _color_unpack() introduced a regression, so it was reverted. You now propose the same change, as was reverted - can we please know a reason for this?

I tried to run color.module tests on this change again a they failed. So if this is causing any issues in PHP 8.1, please open a new issue with the different approach to fix, as this cannot be used (does not pass tests).

The second one (missed) - I see the assertion without the conversion on two more places (instead of one), but have not experienced problems with tests until now. Are these causing any issues? I do not think we need to fix something that is working. If this is causing problems, then I think that also here we need to create a new issue so we can check that and fix.

Thanks!

Last three issues are commited.

I think we should close this as fixed and mark D7 compatible with PHP 8.1. with September release or December release. PHP 8.1. was released on 25.11.2021 and the last reported problem was in May (if I do not count the specific windows-related one). But let's wait a few days for @mpp, whether new problems will arise.

Might be some sort of test bot issue with 5.3
https://www.drupal.org/pift-ci-job/2467436

looks like maybe Mixologic might have changed something I don't see any automated test results for 7.x

https://www.drupal.org/node/3060/qa

I created a ticket in the DrupalCI: Test Runner issue queue
 #3307795: Drupal 7.x core tests dissappeared

@joseph.olstad Thanks for noticing it! We have also asked on #drupal-infrastructure slack channel what could cause this. The issues are with all D7 tests (not only PHP 5.3). I have noticed it here with the main PHP 7.4/MySQL testing: https://www.drupal.org/pift-ci-job/2467463

Does the release yesterday of Drupal 7.92 mean that php 8.1 "compatibility" won't exist until December?

We're currently moving 7.x sites and would prefer to move to php 8.1 rather than 8.0 and then 8.1.

For Drupal 7 core - currently all known PHP 8.1 issues are resolved and commited (see child issues here), so the 7.92 release should be pretty safe and stable on PHP 8.1. If we don't get any new reports about the PHP 8.1 compatibility issues in the near future, then I think we will close this issue as Fixed and announce the compatibility officially, but practically it won't change anything (it's only the announcement).

The situation with contrib modules is a bit different. You will need to carefully check which you are using a see if they made a release with PHP 8+ compatibility fixes. If not, you will need to apply patches from their issue queue manually (if there are any).

Changing the status of this issue back to Active (no work needed currently, all child issues are resolved).

@Poker 10 I've been following this issue from the start and last week I updated my previous project with PHP 8.1. It's really good to know that D7 is compatible with PHP 8.1. Thank You

Same here, all our sites are tested and running on php 8.1

I think I found another php v8 issue when using contact form since each() has been removed in v8.

Error: Call to undefined function each() in SMTP->Data() (line 393 of /home/mywebsite/public_html/sites/all/modules/smtp/smtp.transport.inc).

This is the code at that location.

while (list(, $line) = @each($lines)) {
      $lines_out = NULL;
      if ($line == "" && $in_headers) {
        $in_headers = FALSE;
      }

UPDATE: I guess smtp is a 3rd party module and not part of core, so I guess it doesn't belong in this thread.

Anways, this is how I fixed it. There is another line a bit further down with a similar fix.

foreach($lines as $line) {
      $lines_out = NULL;
      if ($line == "" && $in_headers) {
        $in_headers = FALSE;
      }

The mentioned problem is caused by the SMTP module, see this issue: #2946667: Remove usage of deprecrated each() function for PHP 7.2+ future proofing. Unfortunatelly, it was fixed 4 year ago, but not stable release was published until today, so you will need to either download a DEV version of that module, or apply that patch manually.

That did the trick, thanks!

#2946667-18: Remove usage of deprecrated each() function for PHP 7.2+ future proofing

Just a quick thank you to all.
Your work here allows me to build new D10 sites on the same infrastructure that host legacy D7 sites.
Site by site migration and is number 1 priority but it helps to know I will not have to wait a long time to upgrade D9 sites to D10.
Thank you for making our tax dollars go further.

@ccarnnia, yes it's a win-win-win for everyone, my Drupal 7 sites are performing extremely well on PHP 8.2. Still a few minor issues to deal with on some contrib stuff but it's working well overall. I'm impressed!