Framework: PHP 7.3 Compatibility Notice

Created on 3 Jan 2019  Â·  44Comments  Â·  Source: laravel/framework

For those experiencing issues with PHP 7.3.0, Laravel requires PHP 7.3.2 or later due to bugs in opcache. For those experiencing issues with xdebug beta releases with PHP 7.3, you will need to compile the master branch of xdebug for it to work properly (23rd December 2018 or later will work).

TLDR:

Works

  • PHP 7.2.x + xdebug 2.6.x no known issues
  • PHP 7.2.x + xdebug 2.7.0 no known issues
  • PHP 7.3.2 + xdebug 2.7.0 known issues with tinker, everything else should work
  • PHP 7.3.3 + xdebug 2.7.0 no known issues

Broken:

  • PHP 7.3.0 + xdebug 2.7.0beta1 various known issues
  • PHP 7.3.1 + xdebug 2.7.0beta1 bugs affecting queueing fixed, other known issues

UPDATE 1: 7.3.1 release is likely to be on 10th January (http://news.php.net/php.internals)
UPDATE 2: 7.3.1 has been released today, with some fixes deferred until 7.3.2
UPDATE 3: PHP 7.3.2RC1 and Xdebug 2.7.0RC1 has been released
UPDATE 4: PHP 7.3.2 stable released on February 7th
UPDATE 5: PHP 7.3.3 stable released on March 7th

Most helpful comment

UPDATE 4: PHP 7.3.2 stable released on February 7th

All 44 comments

Hopefully PHP 7.3.1 will be released today as originally scheduled as the ArrayAccess OPCache bug has quite an impact on the ecosystem (PHP 7.2.14 which was also supposed to be released today got delayed to January 10th).

Looks like the release is being delayed. There also look to be further bug fixes to opcache coming in 7.3.2. Perhaps they are going to backport to 7.3.1. I'm not sure what their QA process is.

Update (8th Jan): PHP 7.3.1 is scheduled to land on Thursday 10th January, and will not have the additional fixes currently on the 7.3.2 branch. The bug affecting laravel's queue system is looking to be included in the upcoming 7.3.1 release though. ;)

Thanks for the update @GrahamCampbell

PHP 7.3.1 has been released ;)

Gonna leave this open for a bit longer so people who haven't upgraded yet can find the issue better.

It took a few days, but finally PHP 7.3.1 is published in one of the most popular PPAs for those who use distros based on Ubuntu.

I did not do a full clean install, but I can confirm PHP 7.3.1 + xdebug (does not need to be xdebug master, the actual one will work) will work and, as reference, \Illuminate\Support\Arr::flatten([[]]); will not trigger "Unsupported operand types" or "Segmentation fault (core dumped)"

PHP: 7.3.1-1+ubuntu16.04.1+deb.sury.org+1
xdebug: 2.7.0~beta1+2.6.1+2.5.5-1+ubuntu16.04.1+deb.sury.org+10
no need to disable opcache or set opcache.optimization_level=0x7FFFBBFF


Edit 1:
Note that on my case is not a clean install, and also or some extra parameter was different from the default installation. Also, maybe even the ppa:ondrej/php (https://launchpad.net/~ondrej/+archive/ubuntu/php) have updated the PHP or xdebug package to have some extra patch and this is why it is working even if it's not the xdebug master. I have re-installed xdebug a few times (but I did not compiled master). I would recommend hold a bit longer that PHP 7.3.1 would be sufficient to solve the issue with Arr::flatten untill have more testers, and also could be a good idea cite from where the PHP and xdebug version are compiled.

We are still getting "Unsupported operand types" with PHP 7.3.1 and xdebug 2.7.0beta1

@GrahamCampbell you might want to update the TLD from above with the latest info

Tested this with a fresh project in Homestead and the Arr::flatten issue still persists. I also noticed that I randomly get 502 errors from Nginx. Not sure this is due to a bug in the framework, but rather in PHP-FPM.

Versions used:

  • PHP: 7.3.1
  • Xdebug: 2.7.0beta1
  • Vagrant: 2.2.3
  • VirtualBox: 6.0.2
  • Homestead (vagrant box): 7.0.0
  • Homestead (composer): 8.0.0
  • Laravel: 5.7.21

Just to note this still happens when created a fresh Laravel project, adding the latest Homestead (8.0.0.) via composer. The version it installs are:

PHP: 7.3.1-1+ubuntu18.04.1+deb.sury.org+1
php-xdebug: 2.7.0~beta1+2.6.1+2.5.5-1+ubuntu18.04.1+deb.sury.org+10

..removing xdebug "fixes" the error.

I've had this problem (bad gateway and Unsupported operand types) for quite a while now. You can either use PHP 7.2 (via /etc/nginx/sites-enabled/) or disable Opcache (via /etc/php/7.3/fpm/conf.d/10-opcache.ini) till there is a patch.

@cosmicvibes As noted in the original post, xdebug beta1 is not compatible. You'll need to build the master branch yourself.

@cosmicvibes As noted in the original post, xdebug beta1 is not compatible. You'll need to build the master branch yourself.

Perhaps I'm in the wrong thread here - it's just this happens out the box with a fresh Laravel Project / Homestead instance instance, meaning that Laravel/Homestead is broken for new new projects. Am in the wrong place to be posting this? I assume it isn't wanted that new users get a broken project by default?

Thanks for your patience and if I'm missing something obvious then my apologies.

@cosmicvibes,

@svpernova09 has a great explanation of why homestead does not revert the default PHP version to PHP 7.2 and what you can do instead as a workaround.

Of course is not Laravel's intention that new users get broken projects by default, neither is PHP's. We just try to be helpful while this opcache bug gets fixed 😃

7.3.1 with 2.7.0.beta2-dev (at it is on master today) still has the problem. Does anyone know which xdebug commit will work 7.3.1 ?

Zend Engine v3.3.1, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.1, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.0beta2-dev, Copyright (c) 2002-2018, by Derick Rethans

There are still some OPCache bugs in PHP 7.3.1 which are fixed on the PHP 7.3 branch.

https://twitter.com/derickr/status/1087696014746812417

Expect a release soon. The last (important) outstanding bug turned out to be one in PHP: https://bugs.php.net/bug.php?id=77287 … → will make it into 7.3.2.

PHP 7.3.2 will be released on February 7th.

https://bugs.php.net/bug.php?id=77287 as of this moment didn't make it into 7.3.2 RC1, hopefully it will be included in the final 7.3.2 release.

As I said in my post 18 days ago, PHP 7.3.1 did not include fixes for all the known opcache bugs in 7.3.

Update: PHP 7.3.2RC1 + xdebug 2.7.0RC1 should work properly with laravel.

@GrahamCampbell I'd recommend you to update first sentence in your initial comment to actual version, because now it's says:

Laravel requires PHP 7.3.1RC

@antonkomarev done.

UPDATE 4: PHP 7.3.2 stable released on February 7th

Tinker silently exits after the first statement being typed. 🤔

PHP 7.3.2 (cli) (built: Feb  5 2019 22:19:09) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.2, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.2, Copyright (c) 1999-2018, by Zend Technologies

Does it work with phpenv + phpbuild? I think this is just a homebrew build setup issue?

@GrahamCampbell at the moment I don't have the time to try this out.

PHP 7.3.3 + xdebug 2.7.0 should now work, including fixing the issue with tinker on macos.

@GrahamCampbell Thanks for your great efforts. I just want to notice that you should change issue's title to "Compatibility" instead of "Compatability" 😃

Hello,

Disclaimer: I am not sure this is the right place to place comments regarding php 7.3 compatibility. Please direct me to the right channel if this is not the place.

I have discovered 1 and have the suspicion of 1 more incompatibility with the laravel validators:

  • ACK 'url'. E.g. http://nonexisting404.com/image-404.png gives out The url format is invalid.
  • NACK: 'email' (suspect might have broken)

Please suggest how to move forward? E.g. should I file a separate issue, attach testcase or something else ...

Have a good day.

Hey @leonardinius. It's best to create separate issues. Please provide enough info to reproduce the issue.

@leonardinius What makes you think you are having PHP 7.3 compatibility issues? I also tested your example URL and it validates fine on PHP 7.3.3.

Hey @leonardinius. It's best to create separate issues. Please provide enough info to reproduce the issue.

@driesvints Sure thing. Will do.

@leonardinius What makes you think you are having PHP 7.3 compatibility issues? I also tested your example URL and it validates fine on PHP 7.3.3.

@ThomHurks valid question. It broke on one Ubuntu box with php 7.3.x installed. Will try to reproduce locally / docker and file a separate issue with testcase attached.

If fail to reproduce - will leave a message here.

Ok it turns out URL validation issues is present only when all of the factors below

  • php 7.3
  • has error_reporting(E_ALL & ~E_WARNING);
  • has extra (a bit outdated dependency) "nesbot/carbon": "1.24.1"

If no error_reporting line, then it fails with

ErrorException : preg_match(): Compilation failed: invalid range in character class at offset 1828

Please advise on how to proceed (e.g. is this something worth to file as a separate issue or not)

/cc @driesvints @ThomHurks

Yes, please post a separate issue. It's hard to keep track of multiple things in one single issue.

PHP 7.3.3 (cli) (built: Mar  8 2019 16:40:07) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.3, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v2.7.0, Copyright (c) 2002-2019, by Derick Rethans

Tinker still issue

@GrahamCampbell let's keep this pinned as long as the PsySh issue isn't resolved (just got a new issue about this in the tracker).

The PsySh issue seems to be finally resolved: https://github.com/bobthecow/psysh/issues/540#issuecomment-547847844

How to fix this issues
php version 7.3.0
Laravel Version : 6.11.0

D:\xampp\htdocs\prefer-dist-lara>php artisan:fresh
Could not open input file: artisan:fresh

D:\xampp\htdocs\prefer-dist-lara>php artisan migrate:refresh --seed
Nothing to rollback.

Symfony\Component\Debug\Exception\FatalThrowableError : syntax error, unexpe
cted '.', expecting '{'

at D:\xampp\htdocs\prefer-dist-lara\database\migrations\2020_01_26_070828_lara
vel.password_resets.php:7
3| use Illuminate\Database\Migrations\Migration;
4| use Illuminate\Database\Schema\Blueprint;
5| use Illuminate\Support\Facades\Schema;
6|

7| class Laravel.passwordResets extends Migration
8| {
9| /**
10| * Run the migrations.
11| *

Exception trace:

1 Illuminate\Filesystem\Filesystem::requireOnce("D:\xampp\htdocs\prefer-dist
-lara\database\migrations/2020_01_26_070828_laravel.password_resets.php")
D:\xampp\htdocs\prefer-dist-lara\vendor\laravel\framework\src\Illuminate\D
atabase\Migrations\Migrator.php:477

2 Illuminate\Database\Migrations\Migrator::requireFiles()
D:\xampp\htdocs\prefer-dist-lara\vendor\laravel\framework\src\Illuminate\D
atabase\Migrations\Migrator.php:103

@dilipom13 Laravel.passwordResets is not valid class name create migration file with diffrent name (laravel_password_resets) will solve your issue.

laravel_password_resets

Thank you @pavinthan but still is not working.

D:\xampp\htdocs\prefer-dist-lara>php artisan migrate
Migrating: 2014_10_12_000000_create_users_table

Illuminate\Database\QueryException : SQLSTATE[42S01]: Base table or view alr
eady exists: 1050 Table 'users' already exists (SQL: create table users (id
bigint unsigned not null auto_increment primary key, name varchar(255) not nul
l, email varchar(255) not null, profile_image varchar(255) null, email_veri fied_at timestamp null, password varchar(255) not null, remember_token varc
har(100) null, created_at timestamp null, updated_at timestamp null) default
character set utf8mb4 collate 'utf8mb4_unicode_ci')

at D:\xampp\htdocs\prefer-dist-lara\vendor\laravel\framework\src\Illuminate\Da
tabase\Connection.php:669
665| // If an exception occurs when attempting to run a query, we'll
format the error
666| // message to include the bindings with SQL, which will make th
is exception a
667| // lot more helpful to the developer instead of just the databa
se's errors.
668| catch (Exception $e) {

669| throw new QueryException(
670| $query, $this->prepareBindings($bindings), $e
671| );
672| }
673|

Exception trace:

1 PDOException::("SQLSTATE[42S01]: Base table or view already exists: 1050 T
able 'users' already exists")
D:\xampp\htdocs\prefer-dist-lara\vendor\laravel\framework\src\Illuminate\D
atabase\Connection.php:463

2 PDOStatement::execute()
D:\xampp\htdocs\prefer-dist-lara\vendor\laravel\framework\src\Illuminate\D
atabase\Connection.php:463

Please use the argument -v to see more details.

D:\xampp\htdocs\prefer-dist-lara>php artisan migrate:status
+------+------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+------------------------------------------------+-------+
| No | 2014_10_12_000000_create_users_table | |
| No | 2014_10_12_100000_create_password_resets_table | |
| No | 2019_08_19_000000_create_failed_jobs_table | |
| No | 2020_01_26_070828_laravel.password_resets | |
+------+------------------------------------------------+-------+

D:\xampp\htdocs\prefer-dist-lara>

Hi @dilipom13 your issue is not related to this topic, you can find the answers for your questions in

  1. https://discordapp.com/invite/mPZNm7A
  2. https://laravel.io/
  3. https://laracasts.com/discuss

@pavinthan i am fix my issue my self.
Thank you so much brother for your replay.

Hi, I got issue about laravel 7 component when I deployed my web app into ubuntu server, the laravel component is undefined error message. I have used PHP 7.3.15 but still got the error. I running in my local, and it's normal, no error. Please need help. Thanks

Was this page helpful?
0 / 5 - 0 ratings

Related issues

felixsanz picture felixsanz  Â·  3Comments

klimentLambevski picture klimentLambevski  Â·  3Comments

shopblocks picture shopblocks  Â·  3Comments

CupOfTea696 picture CupOfTea696  Â·  3Comments

progmars picture progmars  Â·  3Comments