Hey guys,

I just tried to install Drupal 8 for test purposes using PHP 5.6 and all it showed me was a "Select language" message, nothing else, it might be related to deprecated functions in PHP 5.6, but please take a look at it.


Members fund testing for the Drupal project. Drupal Association Learn more


jfha73’s picture

That was on PHP for Windows, for Linux it shows a bunch of errors when installing with PHP 5.6.

This are the errors it finds:

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://www.domain.com/drupal8/core/install.php?langcode=en&profile=standard&id=2&op=do_nojs&op=do
StatusText: OK
ResponseText: Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'revision.langcode' in 'field list': SELECT revision.revision_id AS revision_id, revision.langcode AS langcode, revision.revision_log AS revision_log, base.id AS id, base.type AS type, base.uuid AS uuid, base.revision_id = revision.revision_id AS isDefaultRevision
{block_content} base
INNER JOIN {block_content_revision} revision ON revision.revision_id = base.revision_id; Array
in Drupal\Core\Database\Connection->query() (line 569 of /srv/www/htdocs/drupal8/core/lib/Drupal/Core/Database/Connection.php).
zengenuity’s picture

I just installed D8 from git on Ubuntu 14.04 with PHP 5.6, with no problems. Both install and operation of the site are working fine.

I don't think this is a critical issue.

Berdir’s picture

Could be a configuration thing, I noticed today that .travis with 5.6 default configuration isn't able to install, gives a unicode failure.


Apparently the new default value for this setting is empty and our tests are breaking because of it as they expect it to be 'pass'?

zengenuity’s picture

Possibly, but I don't think that was the OP's problem. The error messages for that particular issue are displayed the requirements screen.

For apache/mod_php, the defaults shouldn't matter, since they are set in .htaccess. But, a change in defaults may affect other configs.

<IfModule mod_php5.c>
  php_flag session.auto_start               off
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_flag mbstring.encoding_translation    off
Berdir’s picture

Good point, travis is using fcgi. And installation through drush, so those defaults aren't there.

chx’s picture

Back to ini_set in settings.php?

Berdir’s picture

Status: Active » Needs review
714 bytes

Or check the php version in the requirements? that's the only place where we care.


cilefen’s picture

Issue tags: +needs backport to D7

@raidensnake on IRC noticed this on D7. If a small patch like this keeps D7 running on 5.6, let's do it.

chx’s picture

Status: Needs review » Reviewed & tested by the community

What a mess.

Berdir’s picture

Thanks. We should however either open a new issue for my specific problem or, if nobody can reproduce the original problem, update the issue title and summary for this.

  • catch committed 12bb051 on 8.0.x
    Issue #2332295 by Berdir: Fixed Unicode requirement check not working...
catch’s picture

Title: Drupal 8 not working with PHP 5.6 » Unicode requirements check not working with PHP 5.6
Version: 8.0.0-alpha14 » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Committed/pushed to 8.0.x, moving to 7.x for backport.

Updated issue title to what the patch fixes.

er.pushpinderrana’s picture

Status: Patch (to be ported) » Needs review
1.53 KB

Patch for D7.

Ollie222’s picture

In the patch in #13 is the second if comparison not supposed to be checking the http_output instead of input?

  if (version_compare(PHP_VERSION, '5.6.0') == -1 && ini_get('mbstring.http_output') != 'pass') {

instead of

  if (version_compare(PHP_VERSION, '5.6.0') == -1 && ini_get('mbstring.http_input') != 'pass') {

In case it helps others while testing php 5.6.0 on windows when trying to install Drupal 7.31 the install process works up to when it asks to fill in the database details, it created the database but would then go back to the database details screen again.

Trying to install from a custom profile allowed me to go through until it tried installing the rdf module and it would then crash.

Using the patch in #7 gave me the warning and then setting the http_input and http_output to pass in php.ini allows installation to work correctly for both a standard and my custom profile install.

jfha73’s picture

Version: 7.x-dev » 8.0.0-alpha14
Issue tags: -needs backport to D7

I have all the requirement on my PHP 5.6 but all I'm getting is this using PHP 5.6 for Windows:

<body class="install-page">

<div class="l-container">

  <header role="banner">
          <div class="name-and-slogan">
                      </div>      </header>

  <main role="main">
          <h1>Choose language</h1>


Nothing else, also, I changing it back to D8, I have D7 installed using LAMP, WAMP & WIMP as Module (for Apache) and FCGI (for both Apache and IIS) and it works just fine, I encountered this ONLY in D8.


klausi’s picture

Version: 8.0.0-alpha14 » 8.0.x-dev
Status: Needs review » Needs work

mbstring.http_output is deprecated as well, so this needs work for D8.

klausi’s picture

Status: Needs work » Needs review
1.29 KB

klausi opened a new pull request for this issue.

klausi’s picture

Proof that this patch works: https://travis-ci.org/fago/rules/builds/35030101

The Travis build for Rules includes a Drupal core installation via drush, which now also works on PHP 5.6.

tstoeckler’s picture

Status: Needs review » Reviewed & tested by the community

Checked on php.net that these two are deprecated and the rest are not.

alexpott’s picture

Version: 8.0.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Committed deb2590 and pushed to 8.0.x. Thanks!

  • alexpott committed deb2590 on 8.0.x
    Issue #2332295 followup by klausi: Fixed Unicode requirements check not...
marcvangend’s picture

Looking at the patch, it seems that I can safely ignore the error message when using D7 on php 5.6. Is that correct?

sanduhrs’s picture

Status: Patch (to be ported) » Needs review
2.18 KB

D7 Backport.

tstoeckler’s picture

Status: Needs review » Reviewed & tested by the community


jfha73’s picture

I just tried D8 beta1 on Windows with Apache 2.4 and PHP 5.6 and I'm still getting only a "Choose language" message, nothing else, not able to continue from there.

jfha73’s picture

Version: 7.x-dev » 8.0.0-beta1

This was never a D7 issue, but a D8, I don't know why it keeps changing.

cilefen’s picture

@jfha73 Regarding the versioning, this issue has been committed to D8 and it is being back-ported to D7. That is why prior contributors changed the version to 7 on this issue. If there is still a problem, it is OK to continue work on 8.0.x.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 23: drupal7-unicode_requirements-2332295-23.patch, failed testing.

cilefen’s picture

Version: 8.0.0-beta1 » 7.x-dev
Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 23: drupal7-unicode_requirements-2332295-23.patch, failed testing.

Status: Needs work » Needs review
sanduhrs’s picture

Status: Needs review » Reviewed & tested by the community
TwoD’s picture

I'll take the liberty of hiding the older patches to make things a bit less confusing.

I can also confirm the #23 patch works well when using Drupal 7 under FPM/FastCGI (the existing mbstring section in .htaccess gets ignored so defaults are used).

yareckon’s picture

OK, this prevented installs of D8 for a while, and still prevents automated installs of D7, for instance drush quick-drupal fails out on php 5.6. Can a core maintainer take a look at this nice patch which updates D7 for 5.6 compatibility?

yareckon’s picture

Issue tags: +PHP 5.6
David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +7.33 release notes

Committed to 7.x - thanks!

  • David_Rothstein committed 5f380f9 on 7.x
    Issue #2332295 by sanduhrs, klausi, er.pushpinderrana, Berdir | jfha73:...
ckosloff’s picture

My vbox has:
System Linux debox 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10) x86_64
Build Date Oct 17 2014 16:58:59
Server API Apache 2.0 Handler
PHP Version 5.6.2-1
Updated system first with a full update && dist-upgrade.
Installed D733 without a glitch, no modifications to php.ini.
Apparently issue fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

oxydog’s picture

Guys, sorry if this is a stupid question, but I can't find an answer to it from the replies. We're upgrading PHP from 5.3.3 to 5.6 because of a bug that prevents some extensions we require from working. We're running Drupal 7.14. Should I be worried about this or not? (I can't determine from the thread whether this is just a Drupal 8 problem or 7 as well).


cilefen’s picture

This affected 7 and 8. However, you may have larger problems than this by running a version of Drupal that is more than two years old, unless you mistyped 7.14.

maximpodorov’s picture

What about Drupal 6? Will this be backported?

helmo’s picture

The patch from #23 applies nicely to Drupal 6.35.

It helped me get the Aegir test suite working on Debian Jessie with Drupal 6. See #2496417: Drupal 6 and PHP 5.6 (Debian Jessie)

ordermind’s picture

Status: Closed (fixed) » Needs review
775 bytes

Is the patch in #23 really correct? Based on http://php.net/manual/en/function.version-compare.php it would seem that version_compare(PHP_VERSION, '5.6.0') will only return -1 if PHP_VERSION is actually lower than 5.6.0. However what the patch should actually do is test if PHP_VERSION is 5.6.0 or higher, right? Attached is a patch that accomplishes this.

Berdir’s picture

Version: 7.x-dev » 6.x-dev

No, the code is correct. The goal is to *not* check that.

Seems like we should commit this to 6.x as well, so setting back to 6.x and needs review for the patch in #23 that apparently also applies to 6.x

ordermind’s picture

Sorry, my mistake.

Fabianx’s picture

Status: Needs review » Reviewed & tested by the community

RTBC for #23

marcvangend’s picture

Version: 6.x-dev » 7.x-dev

@Fabianx #23 is for D7, I think you meant to change the version too.

helmo’s picture

Version: 7.x-dev » 6.x-dev

@marcvangend: no, it was committed to D7 in #37. The same patch however also applies to Drupal 6.

marcvangend’s picture

Oops, sorry, missed that. Thanks helmo.

fgm’s picture

FWIW, I've been running D6, D7, and D8 on PHP 5.6.9-1+deb.sury.org~precise+2 for a few months now without significant problems. D5 is another story entirely, though. This is on Ubuntu 12.04.2 LTS using the sury PPA.

  • catch committed 12bb051 on 8.1.x
    Issue #2332295 by Berdir: Fixed Unicode requirement check not working...
  • alexpott committed deb2590 on 8.1.x
    Issue #2332295 followup by klausi: Fixed Unicode requirements check not...
vijaycs85’s picture

+1 to get this in. Just faced this issue when I tried to install 6.x from HEAD.

Status: Reviewed & tested by the community » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.

Leksat’s picture

Status: Closed (outdated) » Active

Just met this issue on a D6 project. Spent some hours to track it down...
Can the patch be committed to 6.x? I can confirm that #23 applies nicely.

klausi’s picture

Status: Active » Closed (outdated)

Drupal 6 is no longer supported, sorry.

fgm’s picture

Just got this on a Pressflow 6 site too. Patch looks sane (and simple).

fgm’s picture

Project: Drupal core » Drupal 6 Long Term Support
Version: 6.x-dev »
Component: base system » Code
Status: Closed (outdated) » Reviewed & tested by the community

Since there is a D6 LTS project /and/ a RTBC patch, it might be movable over there.

Downgrading from critical per #2.

The D6LTS maintainers may choose if they wish to apply it or not.

fgm’s picture

Priority: Critical » Normal
Kris77’s picture

I have this problem with DRUPAL 8.35 and PHP 7.0...
How can i fix the problem?

Thank you.

fgm’s picture

@Kris77: this issue queue is for Drupal 6 LTS. The problem is not supposed to exist in Drupal 8.3.x with PHP 7.0.y. You'll need to create another issue on D8 with steps to reproduce the problem on 8.3.5.