Global Ray doesn't work with artisan serve

[driesvints]

For some bizar reason, Global Ray has stopped working for me. Everytime I try to use ray, dd or dump nothing happens for me and nothing appears in Ray. I have no idea how this happened or where to begin to troubleshoot...

I've tried:

• Restarting and reinstalling Ray
• Restarting PHP 8.1 & 8.0
• Checked if the auto_prepend_file config is correct in php.ini
• Restarting and upgrading PHP Monitor

Any help is greatly appreciated.

[freekmurze]

Things you can try:

• run php --ini and check if the ini file being loaded is the one where the auto_prepend_file is modified
• try to replace our script at auto_prepend_file by a script of your own that does something simple you can verify (maybe an echo or something like that)
• maybe you're using a different PHP binary for CLI and web requests, and this is what confuses you? Create a script with phpinfo(), let in render in the browser and check the path to the ini file there.

[driesvints]

Thanks!

1. Yes that's the case
2. I can see the echo in CLI but now when running the app on a web request
3. From testing 2. I also thought this but it seems it's definitely the same file (see the screenshots below)

[freekmurze]

If you create a new project and install Ray into it, does it work?

I'm afraid of suggestion this but...

but...

[driesvints]

If you create a new project and install Ray into it, does it work?

I'll try that in a sec.

I'm currently trying:

Route::get('/', function () {
    dd(ini_get('auto_prepend_file'));

    ray('test');

    return view('welcome');
});

The dd gives me /Users/driesvints/.composer/vendor/spatie/global-ray/src/scripts/global-ray-loader.php so the correct prepend is loaded. But when I remove it I get the Ignition error screen saying ray cannot be found.

I'm afraid of suggestion this but...

Yeah, just tried that, no luck :/

I also tried reinstalling Valet and upgrading PHP monitor. Both didn't work. I'm at a complete loss here 😓

[driesvints]

Can confirm that spatie/laravel-ray works when installed. Global Ray doesn't.

[driesvints]

If I access phpinfo() from PHP Monitor I see file:///private/tmp/phpmon_phpinfo.html as the url and I can see the echo statement from within the ray loader file: /Users/driesvints/.composer/vendor/spatie/global-ray/src/scripts/global-ray-loader.php.

But if I do return phpinfo(); as the very first line of public/index.php in a Laravel app I see the php info without the echo statement. Maybe this is a Valet thing?

[driesvints]

Beginning to strongly suspect this is a Valet thing. I tried running php -S localhost:8888 and then I start seeing the echo statement and the ray function starts working if I use it in public/index.php.

[stevebauman]

Hey @driesvints!

global-ray will backoff from loading if it sees ray or laravel-ray as a composer dependency (via the composer.json file) in the current working directory: https://github.com/spatie/global-ray/blob/e10071c6385eb1909fe48b04dc2cd61bc0d31dcc/src/scripts/global-ray-loader.php#L50-L56

Could this be what you're experiencing?

I'm using Laravel Valet and am not experiencing this issue. I tested with a fresh Laravel install as well 👍

Let me try PHP 8.1 👍

[stevebauman]

@driesvints Are you on the new PHP isolation update in Valet? https://github.com/laravel/valet/releases/tag/v3.0.0-alpha

[driesvints]

Hey @stevebauman. Thanks for helping out. I don't have spatie/laravel-ray installed and I'm not using PHP isolation.

[stevebauman]

Ok, can you try re-use'ing PHP 8.1 or 8.0 with Valet via valet use [email protected] --force? I just tested with PHP 8.1 on my machine and it's working fine.

[driesvints]

Versions (notice the "test" which is the echo in the loaded Global Ray prepend file.

main $ valet --version                                                                                                                                                                                          ~/Sites/test-laravel
testLaravel Valet 2.18.10
main $ php --version                                                                                                                                                                                            ~/Sites/test-laravel
PHP 8.0.15 (cli) (built: Jan 21 2022 04:34:55) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.15, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.15, Copyright (c), by Zend Technologies
main $ a --version                                                                                                                                                                                              ~/Sites/test-laravel
testLaravel Framework 9.5.1
main $ global-ray --version                                                                                                                                                                                     ~/Sites/test-laravel
testSpatie Global Ray Installer 1.0.0

And Ray itself is v2.0.1

[driesvints]

$ valet use [email protected] --force                                                                                                                                                                                ~/Sites/test-laravel
testUnlinking current version: php
Linking new version: [email protected]
Stopping php...
Updating PHP configuration...
Restarting php...
Restarting nginx...
Valet is now using [email protected].

Note that you might need to run composer global update if your PHP version change affects the dependencies of global packages required by Composer.

And I still get the Call to undefined function ray().

[driesvints]

@stevebauman I'm a bit closer. I was using artisan serve and mistakenly thought Valet was the culprit. When I use valet link and visit the site using the Valet link then it works for me. php artisan serve seems to not work.

[stevebauman]

$ php -v
PHP 8.1.3 (cli) (built: Mar  1 2022 09:21:02) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.3, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.3, Copyright (c), by Zend Technologies

$ brew unlink [email protected] && brew link [email protected] ...
$ php -v
PHP 8.0.16 (cli) (built: Mar  1 2022 09:59:14) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.16, Copyright (c) Zend Technologies
    with Zend OPcache v8.0.16, Copyright (c), by Zend Technologies
macbook-pro:prism stevebauman$ 

$ valet --version
Laravel Valet 2.18.10

$ global-ray --version
Spatie Global Ray Installer 1.0.0

Here's my env for reference, I'm on the same Valet version (tried on PHP 8.1 and 8.0).

[driesvints]

@stevebauman can you try artisan serve and the following route file?

<?php

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    ray('test');

    return view('welcome');
});

[stevebauman]

php artisan serve seems to not work.

Yup you're right I'm able to reproduce this on my end 👍

[driesvints]

Sorry for the misdirection here. I should have noticed earlier that it's purely an artisan serve issue.

[stevebauman]

No problem, I'm glad we know where to look now! 😄

[driesvints]

The strange thing is that it works with php -S localhost:8888 but not with artisan serve. This strikes me as odd because that's exactly what artisan serve uses under the hood. The echo also doesn't work when just running the PHP binary: php --v. @freekmurze noted to me that that can't work although I don't understand why.

main $ which php                                                                                                                                                                                         ~/Sites/test-laravel/public
/opt/homebrew/bin/php
main $ ll /opt/homebrew/bin/php                                                                                                                                                                          ~/Sites/test-laravel/public
lrwxr-xr-x 1 driesvints 27 Mar 22 14:06 /opt/homebrew/bin/php -> ../Cellar/php/8.1.2/bin/php*

[stevebauman]

Hey @driesvints! This appears to be an issue with supplying a router script in the ServeCommand.

Can you try opening up:

vendor/laravel/framework/src/Illuminate/Foundation/Console/ServeCommand.php

And then modifying this:

From:

protected function serverCommand()
{
    $server = file_exists(base_path('server.php'))
        ? base_path('server.php')
        : __DIR__.'/../resources/server.php';

    return [
        (new PhpExecutableFinder)->find(false),
        '-S',
        $this->host().':'.$this->port(),
        $server,
    ];
}

To:

protected function serverCommand()
{
    return [
        (new PhpExecutableFinder)->find(false),
        '-S',
        $this->host().':'.$this->port(),
        '-t',
        public_path(),
    ];
}

You should see global-ray working. I believe the router script is altering the way the ini is loaded?

[driesvints]

@stevebauman that indeed worked! I'm not sure we can adjust that though... We also use artisan serve for Sail, etc.

Here's the server.php file but I can't see anything odd in it: https://github.com/laravel/framework/blob/9.x/src/Illuminate/Foundation/resources/server.php

[stevebauman]

@driesvints Do you think we could use Foundation/resources/ as the root via the -t option and rename server.php to index.php to retain the mod_rewrite functionality?

I think this is an issue with the PHP CLI itself when running a specific file...

[stevebauman]

Wonder if this is the same when specifying a "router" file:

https://www.php.net/manual/en/features.commandline.options.php

Note: This option is only intended for very basic code, so some configuration directives (such as auto_prepend_file and auto_append_file) are ignored in this mode.

[stevebauman]

Ah and here we go -- auto_prepend_file and auto_append_file are not used when specifying a router script:

https://bugs.php.net/bug.php?id=64566

https://github.com/jpauli/php-src/commit/eb44bd892679b350243123b76a8edcf0f84e31b8

I wouldn't call that a bug; since there is only ever a single router file involved, auto_append|prepend isn't really important (contrary to classic "page controllers"). Furthermore, fixing this bug at this time would likely cause more harm than good. Changing to doc problem.

[driesvints]

Heya sorry, I missed this a bit while being sick last week.

Do you think we could use Foundation/resources/ as the root via the -t option and rename server.php to index.php to retain the mod_rewrite functionality?

I'm unsure. We could maybe duplicate it into a different directory but I'd need to check with the team. I'll check.

Wonder if this is the same when specifying a "router" file: Ah and here we go -- auto_prepend_file and auto_append_file are not used when specifying a router script:

So I guess we can't go that way.

[driesvints]

Do you think we could use Foundation/resources/ as the root via the -t option and rename server.php to index.php to retain the mod_rewrite functionality?

I tried that but it doesn't work. Getting a white page. I don't think we can simple rename the file? The directory probably needs to be the public dir of the app still? That would defeat the purpose of a server.php file.

[stevebauman]

Apologies for the late reply.

I tried that but it doesn't work. Getting a white page. I don't think we can simple rename the file? The directory probably needs to be the public dir of the app still?

Yea you're right -- I'm not sure of the path forward. Do you know if there a particular reason that Laravel doesn't use the public dir of the application to serve? Is it possibly for the mod_rewrite emulation?

[driesvints]

I have no idea myself... I'd have to ask my colleagues but afraid atm it's a bit too busy for that. I'll try to ask soon.

[spatie-bot]

Dear contributor,

because this issue seems to be inactive for quite some time now, I've automatically closed it. If you feel this issue deserves some attention from my human colleagues feel free to reopen it.