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).
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
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 setopcache.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:
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
@ElForastero please see https://github.com/laravel/tinker/issues/63 & https://github.com/bobthecow/psysh/issues/540
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:
http://nonexisting404.com/image-404.png
gives out The url format is invalid.
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
error_reporting(E_ALL & ~E_WARNING);
"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
@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
Most helpful comment
UPDATE 4: PHP 7.3.2 stable released on February 7th