Issue Laravel Toolkit 1.5.7 fails to detect Laravel 13 instance — artisan list --format=json returns empty output for domain user

Matanzas

Matanzas

New Pleskian
Server operating system version
AlmaLinux release 10.1 (Heliotrope Lion)
Plesk version and microupdate number
Plesk Obsidian 18.0.77.3
Greatings

After the automatic update of Laravel Toolkit to 1.5.7-11846 (applied automatically on May 22, 2026 at 03:46), the toolkit stopped detecting my Laravel 13 application. The toolkit was working correctly on May 21, 2026.

Environment:
- Laravel Toolkit: 1.5.7-11846
- Laravel: 13.4.0
- Symfony Console: 7.4.8
- PHP: 8.4.21
- Plesk: 18.0.77

Symptoms:
- Clicking "Scan" shows "Done" in all steps but the Laravel panel does not appear
- No error is shown in the Plesk UI (bug EXTPLESK-8981)
- The following error appears in panel.log with debug enabled:

array_filter(): Argument #1 ($array) must be of type array, null given
File: Laravel.php:206 → getCommandList() → artisanCommandExist('plesk-ext-laravel:config-source')

Root cause identified:
The command "artisan list --format=json" returns 0 bytes (empty output) when executed as the domain user, but works correctly as root. The toolkit calls this command internally to detect the Laravel instance.

Reproduction:
su -s /bin/bash -c '/opt/plesk/php/8.4/bin/php /path/to/httpdocs/artisan list --format=json 2>&1' domain_user | wc -c
Result: 0

The same command on a different domain with Laravel Toolkit working correctly returns the expected JSON output.

Please investigate why artisan list --format=json produces empty output when executed as the domain system user in Toolkit 1.5.7.

Thank you.
 
Hi, @Matanzas . If the website in question has been compromised, it is very likely for the toolkit to fail with the detection. Can you please scan the website using Imunify or a similar tool? If there are any infected files detected, please either clean them or remove them (if possible).

p.s. we have a registered bug (EXTPLESK-8981) to improve the error reporting of Laravel Toolkit in such cases.
 
I check all files, the problem only happens with json output format.

The root cause identified:

When filemng executes artisan list --format=json as the domain user, it returns 0 bytes (empty output). All other formats work correctly:
  • artisan list --format=txt → works
  • artisan list --format=md → works
  • artisan list --format=json → empty, 0 bytes
The same command works correctly on another domain on the same server with a different user. All file permissions are correct, no BOM characters found, PHP configuration is identical between both users.

The toolkit was working correctly on May 21, 2026 before the automatic update.

In Plesk I got this error
array_filter(): Argument #1 ($array) must be of type array, null given:
0: /usr/local/psa/admin/plib/modules/laravel/library/Service/Laravel.php:206
array_filter(NULL null, object of type Closure)
1: /usr/local/psa/admin/plib/modules/laravel/library/Service/Laravel.php:206
PleskExt\Laravel\Service\Laravel->getCommandList()
2: /usr/local/psa/admin/plib/modules/laravel/library/Service/Laravel.php:277
PleskExt\Laravel\Service\Laravel->artisanCommandExist(string 'plesk-ext-laravel:config-source')
3: /usr/local/psa/admin/plib/modules/laravel/library/Service/Laravel.php:323
PleskExt\Laravel\Service\Laravel->getIntegrationConfigurationSource()
4: /usr/local/psa/admin/plib/modules/laravel/library/Service/QueueWorker.php:108
PleskExt\Laravel\Service\QueueWorker->getConfigSource()
5: /usr/local/psa/admin/plib/modules/laravel/library/Service/QueueWorker.php:48
PleskExt\Laravel\Service\QueueWorker->__construct(object of type pm_Domain)
6: /usr/local/psa/admin/plib/modules/laravel/controllers/ApiController.php:216
ApiController->domain()
7: /usr/local/psa/admin/plib/modules/laravel/library/Controllers/BaseController.php:37
PleskExt\Laravel\Controllers\BaseController->__call(string 'domain', array)
8: /usr/local/psa/admin/plib/vendor/plesk/zf1/library/Zend/Controller/Action.php:518
Zend_Controller_Action->dispatch(string 'domainAction')
9: /usr/local/psa/admin/plib/vendor/plesk/zf1/library/Zend/Controller/Dispatcher/Standard.php:308
Zend_Controller_Dispatcher_Standard->dispatch(object of type Zend_Controller_Request_Http, object of type Zend_Controller_Response_Http)
10: /usr/local/psa/admin/plib/vendor/plesk/zf1/library/Zend/Controller/Front.php:954
Zend_Controller_Front->dispatch()
11: /usr/local/psa/admin/plib/pm/Application.php:87
pm_Application->run()
12: /usr/local/psa/admin/htdocs/modules/laravel/index.php:5

I can read those files cause that IONCube protected; I think Toolkit programmers must set some Try/Catch in the future to avoid null entries; and maybe some verbose error to customers (just an idea)

I'll keep testing
 
Hi @Sebahat.hadzhi

Problem solve!!! The issue was a command file (ai generated) with an incorrect encoding (Non-ISO extended-ASCII with NEL (Next Line, 0x85) line terminators instead of standard UTF-8); The NEL characters in the malformed file were being injected into stdout before the JSON output, corrupting it entirely. As a result, "filemng" read the corrupted output, closed the pipe, and the JSON never arrived.

You should use this post to fix the Laravel Toolkit; checking the "Non-ISO extended-ASCII text, with CRLF, NEL line terminators" and output the an verbose error for users understand.

Cheers
 
Thank you for the update. Could you please provide the steps to reproduce the issue along with the content of the file in question? I tried replicating the behavior in order to file up a report but was unsuccessful and I am assuming that I might be missing something. Thank you in advance.
 
Hi @Sebahat.hadzhi

The file was a Console/Command with a ISO-8859-1 (I think, don't really remember well; the files was provided by an AI, and I download as it, check the code and was OK, but don't check the format...by mistake, would happen again), but the main problem was the CRLF; its looks that breaks the JSON response. I just guessing because I don't decrypt the IONCube PHP files. As I said you, I think you might use try...catch to avoid NULL responses in the future. I think that can avoid also some UTF-8 with BOM problems (was not my case, but was the first I check)

I notice the problem when I do "composer show" and the extended characters in description don't show properly; maybe that was part of the problem also. Anyway, if you need my help reprogramming some of the PHP files just tell me and I'll gladly help you.

Cheers

PS: I do apology for my english, its not my mother language
 
You must log in or register to reply here.
Back
Top