Unicode requirements check not working with PHP 5.6

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.

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

https://travis-ci.org/md-systems/captcha/jobs/34575246

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'?

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
</IfModule>

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

Back to ini_set in settings.php?

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

Untested.

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

What a mess.

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.

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

Updated issue title to what the patch fixes.

Patch for D7.

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.

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

klausi opened a new pull request for this issue.

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.

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

Committed deb2590 and pushed to 8.0.x. Thanks!

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

D7 Backport.

Awesome!

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

As per #2332295-24: Unicode requirements check not working with PHP 5.6 this has been RTBC.

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

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?

Committed to 7.x - thanks!

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.

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

Thanks!

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.

What about Drupal 6? Will this be backported?

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)

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.

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

Sorry, my mistake.

RTBC for #23

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

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

Oops, sorry, missed that. Thanks helmo.

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.

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

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.

Drupal 6 is no longer supported, sorry.

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

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.

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

Thank you.

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

Patch in #23 still applies to latest 6.44 without problems. Used it for at least a couple of years without problems. Can it be committed to next Drupal 6 LTS release?

Me too: The patch still applies to 6.44. Please commit it to the LTS release.

The patch in #23 still applies to D6.46 and works with php 7.2 without problems. It has already been committed to Drupal 7 several years ago and also to Drupal 8. Can it be committed to D6LTS ?

Thanks you.

Thanks, Everyone!

I've committed the patch from #23 to the D6LTS fork:

https://github.com/d6lts/drupal/commit/23454dfc41440d4098d2890a05163b6a3...

Now that the patch has been applied to the D6LTS fork it is finally closed, ya hoo.

I am returning this to the drupal core queue, where I think it belongs and to facilitate future queries on core issues. This issue has spanned 4 years and includes comments of similar issues described in Drupal 7 and 8 that may be helpful for the history.