Comments

David_Rothstein created an issue. See original summary.

David_Rothstein’s picture

Status: Active » Needs review
FileSize
427 bytes
David_Rothstein’s picture

Looks like a lot of the failures are covered by #2460833: _drupal_session_destroy() should return boolean and #2620104: PHP 5.4 test failures, although there may be a few others beyond that.

pounard’s picture

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

twistor’s picture

twistor’s picture

Status: Needs review » Needs work

The last submitted patch, 6: 2656548-6.patch, failed testing.

twistor’s picture

Status: Needs review » Needs work

The last submitted patch, 8: 2656548-8.patch, failed testing.

twistor’s picture

twistor’s picture

twistor’s picture

twistor’s picture

Related issues:
littletiger’s picture

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?

anavarre’s picture

Issue tags: +PHP 7
matglas86’s picture

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?

ayalon’s picture

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

MustangGB’s picture

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

hass’s picture

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

mikeytown2’s picture

omega8cc’s picture

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

btopro’s picture

#21 looking good thus far

MustangGB’s picture

Priority: Normal » Major

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.

twistor’s picture

Boom shakalaka!!

David_Rothstein’s picture

Thanks for all the great work on this!

I'll try to review those last 4 issues myself if no one else does (though I don't really like being the only reviewer and committer on the same patch). And I'll check to make sure that all the RTBC ones look on track for commit also. It would definitely be nice to have all these tests passing for the upcoming release.

The Drupal7 package is not installable on Ubuntu 16.04:
....
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.

This really does seem odd to me; my understanding was that all the issues are pretty minor. And no one really complained before about Drupal 7 not passing tests on PHP 5.4 or PHP 5.5 :) But in any case, hopefully we can get them passing on all versions soon.

Fabianx’s picture

Category: Task » Plan
Priority: Major » Critical

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.

stefan.r’s picture

Title: Drupal 7 PHP 7 testing issue » Fully support PHP 7 in Drupal 7
Fabianx’s picture

Status: Needs review » Needs work
Related issues: +#2454439: [META] Support PHP 7

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.

DamienMcKenna’s picture

David_Rothstein’s picture

Category: Plan » Task
Priority: Critical » Major
Status: Needs work » Needs review

Current status here (regarding the test failures specifically):

  1. I reviewed all the patches from #29 and marked them all RTBC.
  2. I committed most of the others that were already marked RTBC (with lots of help from stefan.r and Fabianx verifying that they were ready to commit!)
  3. The big one left that needs review is #2215369: Various bugs with PHP 5.5 imagerotate(), including when incorrect color indices are passed in since I found a few problems with it - so followup reviews definitely needed there.
David_Rothstein’s picture

Category: Task » Plan
Priority: Major » Critical
Status: Needs review » Needs work

Sorry, I had that window open in my browser for a few days :)

Cyberwolf’s picture

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.

mikeytown2’s picture

geerlingguy’s picture

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!

Ayesh’s picture

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.

DamienMcKenna’s picture

@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.

greg.1.anderson’s picture

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.

Fabianx’s picture

#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).

Ayesh’s picture

FileSize
2.35 KB

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/*).

Cyberwolf’s picture

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

MustangGB’s picture

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?

Fabianx’s picture

#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.

MustangGB’s picture

@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.

Fabianx’s picture

Priority: Critical » Major

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!

David_Rothstein’s picture

I added tests above for all the other environments also, just to see where we're at and to make sure all PHP versions 5.3/5.4/5.5/5.6/7 are now passing. (I don't really expect the SQLite/PostgreSQL ones to pass, but added those too just to check.)

I think we might want to be a little more aggressive about labeling PHP 7 as actually supported rather than "experimental". If we have known issues we should definitely document and link to them, but I would say unless they're serious, we could go ahead and mark PHP 7 as supported in the table at https://www.drupal.org/requirements/php and advertise it in the release notes. I do agree with offering a caveat/warning that it hasn't been used on many production sites yet, though.

But basically, we're holding it to a pretty high standard here :) PHP 5.5 was considered as "supported" for a long time, well before all tests were passing, and with known bugs like #2215369: Various bugs with PHP 5.5 imagerotate(), including when incorrect color indices are passed in that was more serious than any of the PHP7-only bugs fixed here. With all tests passing on PHP 7 and several comments here and elsewhere that it's perfectly possible to run Drupal 7 on PHP 7 and has been for a while, I feel like we can say that it's meaningfully supported (which is not the same as saying there are no bugs :).

Fabianx’s picture

#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.

Ayesh’s picture

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).

hass’s picture

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).
dillix’s picture

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

bojanz’s picture

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

DamienMcKenna’s picture

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.

DamienMcKenna’s picture

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).

Alan D.’s picture

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. :)

Ayesh’s picture

FileSize
20.5 KB

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?

hass’s picture

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.

dillix’s picture

Is there any blokers for this issue?

Fabianx’s picture

David_Rothstein’s picture

Priority: Major » Critical
Status: Needs review » Needs work
Issue tags: +7.50 release notes
David_Rothstein’s picture

Priority: Critical » Major
Status: Needs work » Needs review
MegaChriz’s picture

Fabianx’s picture

#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

David_Rothstein’s picture

Trying to figure out how to reference this in the Drupal 7.50 release announcement, here's what I came up with for now (just in case anyone has any feedback):

Improved support for recent PHP versions, including PHP 7

Drupal core's automated test suite is now fully passing on a variety of environments where there were previously some failures (PHP 5.4, 5.5, 5.6, and 7). Several bugs affecting those versions were fixed as well. These PHP versions are officially supported by Drupal 7 and recommended for use where possible.

Because PHP 7 is particularly new (and not yet used on many production sites) extra care should still be taken with it, and there are some known bugs (see the discussion for more details). However anecdotal evidence from a variety of users suggests that Drupal 7 can be successfully used on PHP 7, both before and after the 7.50 release.

And then:

Alan D.’s picture

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 ;)

MegaChriz’s picture

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.

Crell’s picture

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.

heddn’s picture

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.

btopro’s picture

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.

klausi’s picture

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

David_Rothstein’s picture

Thanks for the suggestions everyone.

  1. PHP 7.0 rather than PHP 7 is a good point, but it seems Drupal uses "PHP 7" many places already, so I think I'll just keep it consistent and do the same in the announcement. (Also it will be a while before 7.1 comes out, and hopefully Drupal will support it without many changes since it's not as big of a release.)
  2. I'm not sure it's contradictory to say it works and all tests pass, but there are still some bugs.... Drupal in general is always in that situation :) I'm also not sure the only remaining issues are edge cases though (might depend on what modules you're using?). So how about, especially based on the feedback about core/contrib, we just change it to this: "...there are some known bugs, especially in contributed modules (see the discussion for more details)..."
  3. The recommendation for PHP 5.4+ for Drupal 7 (rather than something newer) comes from https://www.drupal.org/requirements so I'd rather not contradict it in the release announcement. It's possible that should be changed at some point, although I think some Linux distros are still providing security support for older PHP versions (maybe even including 5.3).
  4. PHP 7 is barely 7 months old, which is still very new in the world of production websites :) But we could say "the newest release" rather than "particularly new" instead...

Putting it together, text would be:

Improved support for recent PHP versions, including PHP 7

Drupal core's automated test suite is now fully passing on a variety of environments where there were previously some failures (PHP 5.4, 5.5, 5.6, and 7). We have also fixed several bugs affecting those versions. These PHP versions are officially supported by Drupal 7 and recommended for use where possible.

Because PHP 7 is the newest release (and not yet used on many production sites) extra care should still be taken with it, and there are some known bugs, especially in contributed modules (see the discussion for more details). However anecdotal evidence from a variety of users suggests that Drupal 7 can be successfully used on PHP 7, both before and after the 7.50 release.

btopro’s picture

:thumbsup

Fabianx’s picture

+1 from me as well on #76

heddn’s picture

+1 to #76.

David_Rothstein’s picture

Now that Drupal 7.50 is out, I edited the table at https://www.drupal.org/requirements/php so that PHP 7 + Drupal 7 is green.

I put "yes, but see this issue for discussion" (linking to this issue) as the text. Based on some of the above comments here, we might want to refine that more as time goes on, but I figured that was good enough for now.

David_Rothstein’s picture

FYI, only partially related to this issue (but related to the tests of all the PHP versions done in #51 above) - we tried running Drupal 7 core branch tests on a regular basis for PHP 5.5 and 5.6, but I had to turn it off because they're failing due to a testbot problem (#2762541: PHP 5.5 and 5.6 branch tests fail on Drupal 7 core, even though they pass when run on a patch). The underlying tests themselves presumably still pass though, as in the results above.

We're still running PHP 5.4 and PHP 7 tests after every Drupal 7 commit though.

DamienMcKenna’s picture

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

Tharick’s picture

+ 1 to #76

a1tsal’s picture

Should this issue be marked as closed?

I'm confused because external references suggest the matter is resolved, but the status here is still "needs review."

MegaChriz’s picture

andypost’s picture

btw PHP 7.1 released

DamienMcKenna’s picture

jonathan.green’s picture

David_Rothstein’s picture

I think we might consider closing this issue actually:

So I don't see any open core issues linked here that represent problems really specific to PHP 7.

Or is it helpful to keep this issue open still for people to coordinate on fixing contrib modules, etc?

alesr’s picture

+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.

cilefen’s picture

chrisgross’s picture

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)
----------------------------------------------------------------------
DamienMcKenna’s picture

@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.

chrisgross’s picture

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

chrisgross’s picture

cilefen’s picture

David_Rothstein’s picture