[Bug]: Disk does not have a configured driver.

[realpoke]

What happened?

The custom Storage for the file system still doesn't seem to work for me.

Disk [user_documents] does not have a configured driver.
Disk [documents] does not have a configured driver.
Using the example in the #99 Storage::disk('user_documents')->files();

Using V0.4.0 of both NativePHP/laravel and NativePHP/electron

How to reproduce the bug

I'm simply just trying to use the file system for the computer, trying to get into the user's documents folder.
When using the example from the docs or in #99 it seems like the disk does not exist. And when looking at what disks exists in the coding Config::get('filesystems.disks') it only displays the disks I set up myself.

I'm calling a liveware function that only die dumps the disk files. But it can't find it.

public function test()
{
    dump(Config::get('filesystems.disks'));
    dd(Storage::disk('user_documents')->files());
}

Package Version

0.4.0

PHP Version

8.2.9

Laravel Version

10.18.0

Node Version

20.5.0

Which operating systems does with happen with?

Linux

Notes

Using Livewire component, which I then run a function on with a simple button wire:click="test()".
Upgraded from V0.3.0

[realpoke]

Found that the plugin was running v0.2.0, and it has a v0.3.0 release.

However, the v0.3.0 release still don't have the environment variables setup for PHP in that release. It's only in the main branch that the disk environment variables gets set.

Either making a v0.3.1 where the environment variables gets set or waiting for the plugin to be updates to v0.4.0 from main would do the trick.

The fix I run with for now is to replace the php.js files in the dist of the plugin with a custom one that sets the variables.

Feel free to close, or let me know if I should do a PR to help fix a v0.3.1!

[dreammonkey]

Same issue here, I was expecting a dialog asking for read/write access to the Documents folder...

[realpoke]

I think it always runs in heighten security access because of PHP, so it should have access by default. Seems to work just fine for me with the minor fix, and should work in v0.4.0.

[dreammonkey]

I'm sorry, but I can't get it to work, even though I'm using version 0.4.0 of the nativephp/electron package. None of the native disks seem to have a driver configured...

[realpoke]

Issue: Filesystem missing

The v0.3.0 release of the electron-plugin lacks the necessary environment variables for PHP functionality. Unfortunately, these variables are only properly configured in the main branch of the plugin.

Temporary Fix:

Replace the existing php.js files in the plugin's distribution (dist) with a custom version that includes the required environment variable settings for PHP. This temporary fix will allow you to continue using the plugin with the desired functionality until an official solution becomes available.

[flowan]

@realpoke @dreammonkey For development you have to set the environment variables to make the disks work, not sure if this needs to be done for production/build as well. But either way, i have it working when i set NATIVEPHP_USER_HOME_PATH=/path/to/home in my .env file.

[dreammonkey]

@realpoke @dreammonkey For development you have to set the environment variables to make the disks work, not sure if this needs to be done for production/build as well. But either way, i have it working when i set NATIVEPHP_USER_HOME_PATH=/path/to/home in my .env file.

@flowan Thanks for your reply, I considered doing the same, but that would make the native disks quite useless, wouldn't you think ? And surely this can't be done for production as it would most likely include the username... i.e.: /Users/user.name/Documents

In my use case I want to read a specific folder that should be set in a preferences menu. The folder would likely reside under the User's Documents folder...

I need to check if the disk is configured when the app is built for production...

[stloc]

Test feature https://nativephp.com/docs/1/digging-deeper/files#storing-files-elsewhere failed :