Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
As a prerequisite for porting Project* to D8+ (probably straight to D9 at this point!), we need to get all the modules at least compatible with PHP 7+.
Proposed resolution
Investigate and solve any compatibility issues with Project* on PHP 7+. Initial target: 7.2.
This is a meta to track child issues for each part of the suite and its dependencies:
field_extrawidgetsmachine_nameproject: #3116819: Make Project module compatible with PHP7+- project_release: #3116820: Make project_release compatible with PHP7+
- project_package: #3116821: Make project_package compatible with PHP7+
conflictdereference_listnodechangestoken_formatters- project_issue: #3116822: Make project_issue compatible with PHP7+
- versioncontrol: #3138034: Make Version Control API compatible with PHP 7+
- drupalorg: #3143101: Fix line endings to make PHPCompatibility happy (not actually a problem, just a warning)
- flag: #3067469: Since PHP 7.0, functions inspecting arguments, like func_get_args(), no longer report the original value as passed to a parameter
- field_group: #3083542: Fix PHPCS compatibility warning with PHP 7.4, error with PHP 8.0
- homebox: #3143108: Fix PHP 7.4 compatibility warnings in Homebox
- views: #3076826: Since PHP 7.0, functions inspecting arguments, like func_get_args(), no longer report the original value as passed to a parameter and #3006201: Errors with PHP7
Remaining tasks
TBD.
User interface changes
None.
API changes
Perhaps.
Data model changes
Hopefully none.
Release notes snippet
TBD.
Comments
Comment #2
dwwComment #3
dwwmachine_name is working fine, so I didn't bother spinning out a child issue for that one.
project.module itself is also fine without changes.
Comment #4
dwwAdded #3138034: Make Version Control API compatible with PHP 7+ for a small problem in Version Control API.
Comment #5
dwwAdding some more links to related issues that are dependencies of Project* and/or d.o.
Comment #6
dwwCrossing out projects from the initial list that have no warnings from
phpcs --standard=PHPCompatibility.Comment #7
joseph.olstadKeep up the good work
Comment #8
dwwThanks, @joseph.olstad! Curious: are you using Project* somewhere off d.o?
Note that this effort is somewhat on hold until we can spin up d.o sandbox sites using different versions of PHP. I've basically gotten things as far as I can with limited local testing and with static analysis...
Cheers,
-Derek
Comment #9
joseph.olstadI'm using this project on drupal.org as is everyone else. Getting drupal.org onto php 7.3.x+ should be good for everyone.
Comment #10
raffaeljJust to be sure - is this the module that powers everything on
https://www.drupal.org/project/*?And if so, does this mean, that drupal.org still runs on PHP 5.6, which reached EOL on 2018-12-31?
Initially I was testing and digging how to automate a module release. Than I noticed, that the project module needs v7 and that drupal.org still runs with v7. Now I'm a little bit concerned about security issues...
Comment #11
joseph.olstad@raffaeilj, yes, over 40,000 project pages.
With that said, they may be using PHP 8 for all we know they could be using patches.
Comment #12
raffaelj@joseph.olstad Yeah, I also hope that this is just a forgotten issue and drupal.org runs on modern systems. This issue being open just leaves too much room for speculation...
Comment #13
joseph.olstad@dww, any progress on this?
I've been running PHP 8.1 with one of my more complex D7 instances, it's working well and possibly time for an upgrade to PHP 8.2.
Comment #14
joseph.olstadPHP 8.3 is a worthy upgrade, significant performance improvements available. Could easily upgrade this project to work with PHP 8.3
https://kinsta.com/blog/php-benchmarks/