Fully support PHP 7.0 in Drupal 7

I quite sure making Drupal 7 PHP7 friendly is doable, I'd very much to see it happen!

Combining #2460833: _drupal_session_destroy() should return boolean and #2620104: PHP 5.4 test failures to see what's left.

Current patch contains:

• #2460833: _drupal_session_destroy() should return boolean
• #2620104: PHP 5.4 test failures
• #2215369: Various bugs with PHP 5.5 imagerotate(), including when incorrect color indices are passed in
• #2663746: Array to string conversion in trigger.test for PHP 7.
• #2663752: Undefined string index 0 in DrupalTestCase::getAbsoluteUrl() in PHP 7

Hi, what's the status on this? Who is working on it? Is it stuck on some difficult issues, or all fixed but in need of testing?

Looking at this issue and having Ubuntu 16.04 being released with Php 7 as default a few days ago I'm curious if there is any progress on the last two fails?

The Drupal7 package is not installable on Ubuntu 16.04:

Most PHP-dependent packages were either rebuilt or upgraded for PHP7.0 support. Where that was not possible, packages may have been removed from the archive. There was one exception, Drupal7.

Drupal7 does not pass upstream testing with PHP7.0 as of the 16.04 release (https://www.drupal.org/node/2656548). An SRU will be provided once upstream PHP7.0 support is available and verified. Until that time, the drupal7 package will not be installable in 16.04.

https://wiki.ubuntu.com/XenialXerus/ReleaseNotes

I took a crack at the first of the remaining two failures.
#2712993: Can't override the same CSS files multiple times

Any chance to commit the RTBC patches to move things forward?

Latest from
#2460833-30: _drupal_session_destroy() should return boolean
#2620104-14: PHP 5.4 test failures
#2215369-69: Various bugs with PHP 5.5 imagerotate(), including when incorrect color indices are passed in
#2663746-2: Array to string conversion in trigger.test for PHP 7.
#2663752-2: Undefined string index 0 in DrupalTestCase::getAbsoluteUrl() in PHP 7
#2712993-2: Can't override the same CSS files multiple times

Also commented out the RDF failure from #12. Will open up an issue for that if this goes green.

Also for anyone moving to PHP 7 this will find issues with Uniform Variable Syntax change grep -rn -e "->\$[a-zA-Z0-9_]*\[" ./

Created #2717633: PHP 7 hook_rdf_mapping() ['mapping']['rdftype'] failing in rdf.test: RDF type is present on post. in order to deal with the RDF failure in PHP 7

@mikeytown2 Works great for BOA/Aegir, thank you all ! -- https://www.drupal.org/node/2704303#comment-11153029

#21 looking good thus far

Since this was a sub-task of a previously major task that has since been marked as fixed, I think it's only valid to increase the priority, especially considering we were specifically called out as being incompatible with Ubuntu 16.04.

Here's the fix from #2717633: PHP 7 hook_rdf_mapping() ['mapping']['rdftype'] failing in rdf.test: RDF type is present on post. rolled in.

Boom shakalaka!!

For those interested, the 5.4 issues still need review.

1. #2660766: UpgradePathTaxonomyTestCase::testTaxonomyUpgrade() doesn't properly test field settings.
2. #2660744: Skip test for decoding invalid numeric entities in 5.4+
3. #2660754: Invalid numeric comparison in OpenIDTestCase::testConversion()
4. #2660762: TrackerTest::testTrackerNewComments() sets the node title incorrectly.

Per discussion with stefan.r making this a critical plan.

The goal is to say:

"Drupal 7 core fully supports PHP 7".

And hopefully contrib will follow along then.

We need to check _all_ the issues in #2454439: [META] Support PHP 7 for implication on Drupal 7.

Just because tests don't fail, does not mean that we are not affected by them.

And these things can lead to very very very weird bugs.

BTW we'll also need #2738921: Drupal 7 tests should not be blocked for PHP 7 on the Automated Testing tab of project pages in order for contrib to support it.

Now this issue has a real title and child issues have been linked we don't need to double reference them all.

Hi,

Is the one-line change in modules/rdf/tests/rdf_test.info in patch #26 intentional?

+dependencies[] = blog

This seems a bit strange to me, for a PHP 7 compatibility patch.

@Cyberwolf
#2717633-16: PHP 7 hook_rdf_mapping() ['mapping']['rdftype'] failing in rdf.test: RDF type is present on post. explains it; also see #20 in that issue.

Just an aside... Last night I had a brain fart to end all brain farts and accidentally upgraded one of my production Drupal 7 servers to PHP 7 instead of 5.6, and surprisingly, even though the server had over 25 wildly-different D7 sites with a combination of around 150 different D7 modules per site, none of the sites had any discernible new errors, and I monitored syslog for a couple hours and didn't see one notice, warning or error out of the ordinary.

Bonus: for the few sites that aren't served via a proxy cache, page loads got 30% faster across the board (monitoring through the night confirmed it wasn't just a short term speed up due to a fresh server reboot).

So, though there are a couple dark corners where D7 needs a little brushing up to work perfectly under PHP7 (see: this issue), on the whole, people should not be afraid to dive into modern PHP. The water's nice... And pleasantly fast-flowing!

I can also confirm D7 current dev works reasonably well with PHP 7.0 and MySQL 5.7. The session errors were not fixed at the time I tested, and the patches (now in dev) fixed that. I have my blog and several other production sites working perfectly well there.

I have been pulling my hair to fix the RDF issue, but not much luck with that.

@geerlinguy: For the contrib-focused contributors in the audience, would you mind providing a list of the contrib modules the site is currently using? Thanks.

I encountered an issue with updatedb on D7 with php7 (n.b. fresh install with no updates to run), but it's been a little while since I tried. Sounds encouraging -- I'll have to give it another spin.

#40 Thanks for the anecdotal evidence.

I would suggest to open a wiki or documentation page with known good contrib modules.

I feel for the next release, we will be able to say something like:

"We have experimental support for PHP 7. There could still be bugs. Please test carefully. We will fully support PHP 7 once we feel safe that it works in the "wild". And @contrib: Please test and make your modules ready for PHP 7 as well - if needed."

I think for now the most crucial issues are stable sorting and syntax errors (due to stricter syntax).

If it helps, you can check your current contrib code with php7cc (https://github.com/sstalle/php7cc ; requires PHP 5.3 or later).
Attached a check results for core (includes/*, modules/*).

Thanks @mikeytown2 for pointing me to the other ticket regarding the missing dependency on the blog module in rdf_test.

Not really the point of this issue, but all my servers (production or otherwise) have run on PHP7 for the last 8 months, and yes it's glorious, hence my enthusiasm for this issue. Less so for 5.4/5.5, which I guess partially answers #30.

Although if we're doing asides, I'd love to know what the "Pending Drupal 7 commit" tag is for, I read all the comments on all the issues that have added this tag and not one of them explains or points to an explanation of where it comes from or what it's intent is, is there a timeline associated with this, if not what's the point of the commit delay?

#47:

The "Pending Drupal 7 commit" was originally used by me and stefan.r when we were officially announced, but did not yet have the power to actually commit, but really wanted to start triaging the queue.

I think of it as an (experimental) feedback mechanism: e.g. One D7 core committer thinks it is ready and there is no more work needed, but another core committer or even maintainer / contributor might disagree.

I am a fan of giving quick feedback to the Community (You are all awesome), but on the other hand reviewing something as "okay" / "approved" is not the same as actually committing it and in D7 especially we need to be really careful with not breaking anything. The tag is just a way to organize that.

And if you have followed some of the issues, David especially had some great insights on some of them still.

Also sometimes I (personally) am on a computer, where I can't commit, but can already give the feedback to the community that no more work is needed.

Also stefan.r and me talked about having two core committers sign off on more complicated patches. Or me doing reviews, him committing if my schedule does not permit committing at the moment. (e.g. team up on that)

So this is all internal and experimental for now, but I feel it is better to give some kind of feedback, than to leave an issue for RTBC for 2 months (though that could still happen too), where no one knows if this just has not yet been reviewed and actually needs work or just need some time to being committed - due to careful testing and re-review.

I also - and this is more personal for me - often find that my brain continues to think about reviewed patches and often I find flaws or issues hours or days later or when I re-review the issue.

I hope this clarifies the question - even though it is totally off-topic here.

TL;DR: Patch review and that something is ready does not mean that it passes all testing in depth or might need some more thinking or careful review before commit.

@Fabianx: Thanks!

Also congrats to yourself and stefan.r, I was aware D7 was looking for maintainers, didn't know it got some though, very happy to hear the good news.

Okay I'll shut-up now, sorry for the off topic, honestly thought I'd just get pointed at a docs page where it was all explained that I'd missed.

PHP 7 is green on tests and will be available for contrib modules testing soon! (pending #2738921: Drupal 7 tests should not be blocked for PHP 7 on the Automated Testing tab of project pages)

However not yet marking this fixed, because there are still issues to review and #45 should be checked / fixed as well.

I would however say we have experimental PHP 7 support now!

Adding test to prove it.

#52: I do agree, but especially the non-stable sorting can you bite in edge cases quite hard (element_children e.g.).

I ran into some of them myself and it was quite a WTF (and very hard to debug). I also do think we should be aggressive.

Maybe: Supported with some known bugs that happen in edge cases.

Woot!
D8 has a working fix for element sorting, so what is left is porting it to 7 (from the current known issues of course).

Does it make sense to suppress these warnings in core error_reporting or should the modules change their code? I'm not sure if this is possible... als not sure if this only bubbles up on my dev machine because of devel or so. Just asking...

Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context has a deprecated constructor in require_once() (line 30 of sites\all\modules\contrib\ctools\includes\context.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context has a deprecated constructor in require_once() (line 30 of sites\all\modules\contrib\ctools\includes\context.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context_required has a deprecated constructor in require_once() (line 93 of sites\all\modules\contrib\ctools\includes\context.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context_required has a deprecated constructor in require_once() (line 93 of sites\all\modules\contrib\ctools\includes\context.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context_optional has a deprecated constructor in require_once() (line 205 of sites\all\modules\contrib\ctools\includes\context.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; ctools_context_optional has a deprecated constructor in require_once() (line 205 of sites\all\modules\contrib\ctools\includes\context.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; panels_cache_object has a deprecated constructor in require_once() (line 117 of sites\all\modules\contrib\panels\includes\plugins.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; panels_cache_object has a deprecated constructor in require_once() (line 117 of sites\all\modules\contrib\panels\includes\plugins.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; panels_allowed_layouts has a deprecated constructor in include_once() (line 44 of sites\all\modules\contrib\panels\includes\common.inc).
Deprecated function: Methods with the same name as their class will not be constructors in a future version of PHP; panels_allowed_layouts has a deprecated constructor in include_once() (line 44 of sites\all\modules\contrib\panels\includes\common.inc).

@hass, I think that maintainers of ctools & panels should change their code to be compatible with php7.

Class-named constructors are literally PHP4 code. No need for that to stay unfixed.

I've opened issues for CTools (#2760041: Make CTools on D7 fully compatible with PHP 7) and Panels (#2760043: Make Panels on D7 fully compatible with PHP 7) to cover its PHP 7 incompatibilities.

Because CTools doesn't have a release that fixes the PHP 7 bugs, any module that depends upon it is likely to have its tests fail due to CTools 1.9's bugs, this problem is hitting Panelizer (#2687795: Make Panelizer on D7 fully compatible with PHP 7) and Metatag (#2687793: Make Metatag on D7 fully compatible with PHP 7).

Awesome work everybody.

I guess once the new release is rolled, all that needs to be done in relation to this issue is to update the doc's page...

https://www.drupal.org/requirements/php

The table

In progress (orange) to yes (green)

Probably some contrib with PHP 5.3 notices still, but I guess you could mention something in the section below, but these are no longer a core issue:

Drupal 7

Drupal 7 requires PHP 5.2.5 or higher (or PHP 5.2.4 with backported security patches, such as the version included with Ubuntu 8.04). PHP 5.4 or higher is recommended. PHP 7 support was added on DATE and support in various modules and themes are likely to follow quickly. If you notice any errors, please report these into the appropriate project issue queue tagged with "PHP 7".

[edit]
Most of the core projects do have good PHP7 support, Views, CTools, ..., but many lack recent releases. I'm partially responsible for this with Diff for example that has PHP 4 style class constructors that have been fixed, but no new release done yet. :)

I ran php7cc on top 200 modules as reported on drupal.org, and only 58 of them have issues from php7cc. Most of them are false positives due to func_get_args() usage. I'm attaching the list if anyone's interested. The zip file contains multiple txt files named after the module machine name, and their issues inside them as relative paths. This is the script I used. Most notably, ctools, SMTP, and Panels modules have surefire issues. May be we split up and report them to each issue queue?

I can say that php7cc seems to be highly unreliable. It has not found errors that crashed (wsod) my site. See #2760025: Make HTTPRL on D7 fully compatible with PHP 7. I checked all my modules and nothing was found, but I fear this may not true now.

Is there any blokers for this issue?

Yes,

#2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport] is a blocker, but I guess we'll need to ship 7.50 with the known bug.

I found another PHP 7 issue: #2761285: _drupal_session_write() does not always return a boolean

#67: I RTBC'ed the issue and brought it to the other committers attention - in the worst case it will be in the next bug fix release instead.

I also found another one, which I always apply locally to make self-signed certificates work: #2761345: PHP 5.6, 7 - drupal_http_request() behavior changes for SSL using self-signed certs

Maybe it is best to use PHP 7.0 rather than PHP 7? A bit nitpicky, but if 7.1 doesn't pass, the doco will be misleading.

If this is going to be like PHP 5, with minor releases, there were lots of API changes between 5.2 & 5.3 that causes a large amount of issues with core & contrib. Using just PHP 7 suggests coverage of all versions, including yet to be released versions ;)

I think the text includes everything it should, though if I overanalyze it, there are some parts in it that sound like contradictions:
"Drupal 7 can be successfully used on PHP 7" vs "There are some bugs when using Drupal 7 on PHP 7".
And: "Drupal < 7.50 can be used on PHP 7" vs "Several bugs affecting PHP 7 have been fixed in Drupal 7.50".
The text could be a bit puzzling for a small group of users, but I think in the end the message is clear enough: "When you want to use Drupal 7 with PHP 7.0, please test first if it works for you."

I think it is good to keep this issue open until all child issues have been fixed.

It sounds like the proposed text recommends anything from 5.4-7. We should probably explicitly recommend PHP 5.6 as the oldest to use, given that PHP 5.5 is dead (checks watch) today! :-)

The "all tests pass" and "some bugs" seem in conflict. I'd suggest clarifying that the bugs are in selected edge cases (if accurate, seems to be). Contrib is the bigger concern, since who knows how tests are doing there. That warrants a mention, too.

I take some issue with

Because PHP 7 is particularly new (and not yet used on many production sites) extra care should still be taken with it,

It isn't that new. Its been out for quite some time. I feel the *real* reason to be cautious with 7.0 is contrib. Core is fairly solid at this point. I'm already running several sites on 7.0 in production.

The "all tests pass" and "some bugs" seem in conflict. I'd suggest clarifying that the bugs are in selected edge cases (if accurate, seems to be). Contrib is the bigger concern, since who knows how tests are doing there. That warrants a mention, too.

Definitely worth mentioning that even though core supports it that contrib is still woefully behind. Perhaps pushing an issue tag like #PHP7compat or something. Also maybe a link to the PHP7 deprecation note about what is no longer compatible. For example the bulk of issues I've had in prepping for PHP7 involved converting return; to return FALSE;. Not to suggest it's the only thing but it's probably the easiest gotcha that can quickly be resolved across much of contrib.

There is already the "PHP 7" tag for all of core and contrib: https://www.drupal.org/project/issues/search?issue_tags=PHP%207

:thumbsup

+1 from me as well on #76

+1 to #76.

Now that CTools 7.x-1.10 is out with the PHP 7 fixes, we can get back to writing contrib tests :-)

+ 1 to #76

@a1tsal
I think this issue is still open because two child issues are still open:
#2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport]
#2761345: PHP 5.6, 7 - drupal_http_request() behavior changes for SSL using self-signed certs

btw PHP 7.1 released

Update notes for PHP 7.1: http://php.net/manual/en/migration71.php

I think this is another issue that will cause issues with PHP support in Drupal core:
#2834022: drupal_sort_weight sort order undefined and possibly inconsistent between PHP 5 and PHP 7

Very much related to, but not solved by:
#2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport]

+1

Quite surprisingly actually, all is working fine with Drupal 7.53 on PHP 7.0.8 with a bunch of contrib and custom modules installed too.

FYI, I ran PHP_Codesniffer against 7.0 on my drupal Install and found a few issues in core:

FILE: includes/bootstrap.inc
----------------------------------------------------------------------
FOUND 1 ERRORS AFFECTING 2 LINES
----------------------------------------------------------------------
 687 | ERROR | INI directive 'magic_quotes_runtime' is deprecated since
     |       | PHP 5.3 and removed since PHP 5.4
     |       | (PHPCompatibility.PHP.DeprecatedIniDirectives.magic_quotes_runtimeDeprecatedRemoved)
----------------------------------------------------------------------

FILE: misc/healthchecks/db.check.php
----------------------------------------------------------------------
FOUND 3 ERRORS AFFECTING 4 LINES
----------------------------------------------------------------------
  6 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed
    |       | since PHP 7.0; Use mysqli instead
    |       | (PHPCompatibility.PHP.RemovedExtensions.mysql_DeprecatedRemoved)
  8 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed
    |       | since PHP 7.0; Use mysqli instead
    |       | (PHPCompatibility.PHP.RemovedExtensions.mysql_DeprecatedRemoved)
 11 | ERROR | Extension 'mysql_' is deprecated since PHP 5.5 and removed
    |       | since PHP 7.0; Use mysqli instead
    |       | (PHPCompatibility.PHP.RemovedExtensions.mysql_DeprecatedRemoved)
----------------------------------------------------------------------

FILE: modules/filter/filter.api.php
----------------------------------------------------------------------
FOUND 2 ERRORS AFFECTING 3 LINES
----------------------------------------------------------------------
 205 | ERROR | preg_replace() - /e modifier is deprecated since PHP 5.5
     |       | and removed since PHP 7.0
     |       | (PHPCompatibility.PHP.PregReplaceEModifier.Removed)
 237 | ERROR | preg_replace() - /e modifier is deprecated since PHP 5.5
     |       | and removed since PHP 7.0
     |       | (PHPCompatibility.PHP.PregReplaceEModifier.Removed)
----------------------------------------------------------------------

@chrisgross: FYI the file misc/healthchecks/db.check.php doesn't exist in the Drupal codebase, maybe you have something else added to your site?

The magic_quotes_runtime and modules/filter/filter.api.php things could be split off as new issues.

@DamienMcKenna, it must be from Pantheon, then. I can create new issues for the other two.

Looks like there's already one out there:

#2594235: phpcs php codesniffer produces errors on compatibility test for php 56 5.6

#2877243: DATE_RFC7231 already defined in PHP 7.0.19 and 7.1.5

With the first 7.2 alpha available, I tested with it, and there are a few minor issues with some functions being deprecated:
- #2885309: [PHP 7.2] each() function is deprecated
- #2885129: [PHP 7.2] create_function() is deprecated
- #2885610: [PHP 7.2] Avoid count() calls on uncountable variables

Shouldn't we not close this issue as PHP 7.0 and 7.1 is fully supported from my understanding? Than we could open a follow up for 7.2 and maybe more follow ups for later releases. Otherwise we end up with an 10 years case trying to tackle all possible PHP 7.x releases!?

You are right mass my apologies. It makes much more sense.

Agreed. Please open a new meta issue to track PHP 7.2 support for Drupal 7.

While we are running PHP 7.0 with Drupal 7 successfully for a year now there are 2 child issues left that are not fixed yet:
#2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport]
#2594235: phpcs php codesniffer produces errors on compatibility test for php 56 5.6

Do we consider those minor enough that we can still close this issue?

Personally I think we should wait until #2756297: element_children sort order inconsistent between PHP 5 and PHP 7 [Drupal 7 backport] is fixed at least, as this can be quite a wtf when encountered.

Which is preferred at this point PHP70 or PHP71?

We should definitely be targeting a minimum of 7.1 since php 7.0 is completely unsupported before php 5.6 (by 28 days). http://php.net/supported-versions.php

drupal 7 isn't fully compatible with PHP7. here is a report with php7cc (compatibility tester) :

File: /modules/filter/filter.api.php
> Line 205: Removed regular expression modifier "e" used
preg_replace('|(.+?)|se', '[codefilter_code]$1[/codefilter_code]', $text);
> Line 237: Removed regular expression modifier "e" used
preg_replace('|\\[codefilter_code\\](.+?)\\[/codefilter_code\\]|se', '

$1

', $text);

phpcs produced this list on my Drupal 7.56 codebase...

file line column message
modules/filter/filter.api.php 205 11 error preg_replace() - /e modifier is deprecated since PHP 5.5 and removed since PHP 7.0
modules/filter/filter.api.php 237 11 error preg_replace() - /e modifier is deprecated since PHP 5.5 and removed since PHP 7.0
modules/system/system.tar.inc 291 21 warning INI directive 'safe_mode' is deprecated since PHP 5.3 and removed since PHP 5.4
modules/system/system.tar.inc 308 17 warning Function dl() is deprecated since PHP 5.3
modules/system/system.tar.inc 308 45 warning Function dl() is deprecated since PHP 5.3
modules/system/system.mail.inc 46 63 warning INI directive 'safe_mode' is deprecated since PHP 5.3 and removed since PHP 5.4
modules/system/system.mail.inc 73 54 warning INI directive 'safe_mode' is deprecated since PHP 5.3 and removed since PHP 5.4
includes/common.inc 1201 26 warning INI directive 'magic_quotes_gpc' is deprecated since PHP 5.3 and removed since PHP 5.4
includes/unicode.inc 122 17 warning INI directive 'mbstring.http_input' is deprecated since PHP 5.6
includes/unicode.inc 125 17 warning INI directive 'mbstring.http_output' is deprecated since PHP 5.6
includes/bootstrap.inc 692 11 error INI directive 'magic_quotes_runtime' is deprecated since PHP 5.3 and removed since PHP 5.4

That is 3 errors and 8 warnings. #108 says that two of these errors are not a concern.

First major problem observed after my move to PHP71, easily reproduced in my configurations.

Create a book node. Add some children. Try to edit and save the book node and I get this error...

Warning: Illegal string offset 'weight' in drupal_array_set_nested_value() (line 6781 of /..../includes/common.inc).
Error: Cannot create references to/from string offsets in drupal_array_set_nested_value() (line 6781 of /..../includes/common.inc).

I was initially concerned thinking that I broke things while creating book node content programmatically. However, the error occurs the same whether I create the book content manually or programmatically.

Also curious is that the error does not occur when logged in as user 1, but does occur when logged in as another user.

And likewise when I drop back to PHP56 the error goes away.

Any insight? Is this the best place to post this issue?

Create a new issue (if one doesn't already exist), and tag with PHP 7, and reference back to this thread, albeit this thread seems to have run it's course now.

Thanks, new thread started here, https://www.drupal.org/node/2897415

Dear @webservant316,

I'm a complete newbie in Drupal development considering the stature of all the members in this discussion, so, please stay with me even if I ask any lame questions!

Our existing code base consists of:-
- D7.5.6
- contrib modules (90+)
- custom modules (25+)

Currently, I run the PHPCS report with PHP_CodeSniffer version 2.9.1 on the DrupalPractice ruleset, bound with our existing code base based on PHP 5.3.3.

I'm trying to run Drupal 7.56 on PHP 7.0.10, and I haven't seen any major issues so far. May be our project haven't been using the pure core to the fullest yet.
However, I still want to go ahead and run a PHPCS report on our existing code base with PHP 7.0.10.

So, can you please help me understand if there is any updated/new DrupalPractice ruleset version to run a PHPCS report on PHP 7.0.x + D7.5.6?

Thank you, and Appreciate your help!

Hi @knowledge-c:

The scope of this issue is getting Drupal 7 to operate properly on PHP 7, not coding standards as such—see drupal/coder for that. I think your question is better for IRC or the forums.

So, can you please help me understand if there is any updated/new DrupalPractice ruleset version to run a PHPCS report on PHP 7.0.x + D7.5.6?

I just used phpcs to look for any issues before moving to PHP71. The only special concern I was investigating was functionality. I wanted to figure out if Drupal 7.56 and the contributed modules I am using work with PHP71. I did discover a problem in the book_made_simple module and so abandoned it as explained at https://www.drupal.org/node/2897415.

Otherwise I have been using PHP71 with Drupal 7.56 and 100+ contributed modules on 4 production websites with no problem for several months. Thanks Drupal!

That helps, @webservant316, Thank you!

@cilefen - Yes, I would have done so, and Thank you for guiding me on the correct process!
I posted it here because I wanted to take some confirmation from "webservant316". Next time onwards, I will be careful.

Certainly report any PHP 7 issues here.

This warning shows up with the new PHP 7.2:
Warning: count(): Parameter must be an array or an object that implements Countable in theme_table() (line 2061 of /var/www/html/imart/includes/theme.inc).

@heyyo
You should create a new ticket for this and reference this issue as a parent.

This looked like a GIGO issue, but it should be easily replicatable.

i.e. Just don't define any of the theme parameters that default to NULL that are then are used with count(), namely caption, header, rows, colgroups theme variable arguments.

theme('table', array());

Workaround should be a trivial via THEME_preprocessor_table to add some checks, fix would be to change the theme default definitions from NULL to array I believe ;)

    'table' => array(
      'variables' => array('header' => NULL, 'rows' => NULL, 'attributes' => array(), 'caption' => NULL, 'colgroups' => array(), 'sticky' => TRUE, 'empty' => ''),
    ),

I got these error message on screen when I upgrade to php7.2 for my D7, and the whole site is gone.

Fatal error: Uncaught Error: Call to undefined function cache_get() in /home/abccom/abc.com/includes/module.inc:754 Stack trace: #0 /home/abccom/abc.com/includes/module.inc(954): module_implements('system_theme_in...') #1 /home/abccom/abc.com/modules/system/system.module(2511): module_invoke_all('system_theme_in...') #2 /home/abccom/abc.com/includes/theme.inc(798): _system_rebuild_theme_data() #3 /home/abccom/abc.com/includes/theme.maintenance.inc(57): list_themes() #4 /home/abccom/abc.com/includes/bootstrap.inc(2872): _drupal_maintenance_theme() #5 /home/abccom/abc.com/includes/errors.inc(179): drupal_maintenance_theme() #6 /home/abccom/abc.com/includes/bootstrap.inc(2609): _drupal_log_error(Array, true) #7 [internal function]: _drupal_exception_handler(Object(Error)) #8 {main} thrown in /home/abccom/ab.com/includes/module.inc on line 754

IF i only upgrade to php7.0 or 7.1, the drupal site simply just display a blank front page.

Please suggest what should I do ? Thank you!

@freelylw How to extract logs from a WSOD: https://www.drupal.org/node/158043

@cilefen sorry its not blank page when update to php7.0/7.1, its a page displaying the message :

This page isn’t working
abc.com is currently unable to handle this request.
HTTP ERROR 500

@freelylw Indeed. Check the logs.

Hi everyone, what's the current status of Drupal 7 on PHP7? My Linux distribution of choice for my server will soon be dropping PHP5 and moving to PHP 7.2.5. They are dropping PHP5 because the last release of PHP 5.6 is nearing the end of its support lifecycle on 31 Dec 2018, and apparently that's the last release in the 5.x branch.

I'm a bit worried about the contrib modules with PHP7. For example, Rules just recently fixed two major PHP7 compatibility issues:
- https://www.drupal.org/node/2952654
- https://www.drupal.org/node/2923477

@sb56637: Once core is fixed up we can test out core modules to make sure they work correctly.

@sb56637
Of course, this issue is only toward Drupal Core.

Assuming your project is using Rules..and that's the only issue for that site. life will be good. You'll have to look at each project used in your site (or sites).

Really only run the project on a test server and...see how good or bad it's going to go running under php7.x. You'll have probably need to comb thru each project's issues to see if any issues/patches exist, if not: happy patching!

I also do/have long term maintenance for projects, so i hear your concern. hopefully you're project(s) are build 'well'.

This is resolved with:
#2947772: Fully support PHP 7.2 in Drupal 7

FYI, I've created a new issue for support of PHP 7.3.
#3028648: Fully support PHP 7.3 in Drupal 7

I don't think it can be justified to close this issue with so many outstanding child issues that haven't been fixed or moved to another parent issue that is active.

Please clarify why you think #2947772: Fully support PHP 7.2 in Drupal 7 resolves this, if these child issues aren't resolved?

Ok, yes MustangGB, after looking again there appears to be several related issues left over.

I suggest that someone (other than me) attach/link any remaining unresolved related issues onto #3028648: Fully support PHP 7.3 in Drupal 7

and then close this for us,
please and thanks :)

As an aside, this thread was primarily related to PHP 7.0, which is itself now an unsupported branch (EOL was 10 Jan 2019) and David himself suggested closing this a couple years back (#89).

Maybe there should be a parent meta issue for PHP support per Drupal major branch, with child issues to cover individual minor PHP release support for that branch (PHP 7.1, 7.2, ...). Otherwise this thread will still be open in 2021/22 for PHP 7.6 related issues. :/

Agreed, php 7.0 is not supported anymore, let's continue in follow-up issues on the supported or future versions. Then people don't have to read up on this long thread where 95% is fixed already.

Ok put that way, yes I agree with Klausi and Alan D, keep this closed as it was in #127.

slight correction;
php 7.0 is supported by Drupal, however not by zend
Vendors of Linux distributions such as RedHat offer security support for versions of PHP going back to 5.x.x