When uploading file they are not uploaded and this error is given:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "file_validate_extensions" plugin does not exist
OK.
When ready I will review and merge it.
Please also provide updated info on the simlink handling for the README file.
### Symbolic links ###
Filebrowser only partially supports symbolic links. Symbolic links to directories *on the same storage* will work well. However, symbolic links to files will not work.
The code, at the moment, does not distinguish between a linked file or a linked directory. As soon as it detects a link it will assume it's a directory.
PHP functions like is_link() is_dir() etc. should be able to execute without an error in order to manage symbolic links. However, a lot of things (like permissions on webservers level) will influence this, making it tricky.
And I am not even talking about a symbolic link within a WSL2 system linking to a Windows file system.
There is a initiative to make FB fully compatible with symbolic links, so it might become available in a future release.
I have added above information to the README.
And closing this issue.
If anyone comes-up with a solution to fully support symbolic links I will follow-up on it.
The current version of Filebrowser works fine if the symbolic link links to a directory on the same linux storage.
The code, at the moment does not distinguish between a linked file or a linked directory. As soon as it detects a link it will assume it's a directory. As far as I know it is a bit of a problem trying to read the symbolic links since PHP is_link() is_dir() etc. should be able to execute without an error. A lot of things (like permissions on webservers level) will influence this, making it tricky.
And I am not even talking about a symbolic link within a WSL2 system linking to a Windows file system.
As I stand now, I am leaning into declaring Filebrowser to be *not* compatible with symbolic links.
If the fork produces a full solution we can put that into a new release.
OK, I see it.
The code mis-identifies the symbolic link as a folder and tries to treat it that way.
I will try to find time to fix this in coming days.
Please re-open if and as needed
Please re-open when and as needed
I can't recall why the lines are commented out. MR accepted thanks!
My preference would be to increase the size of the "path" column.
I thought 255 was already generous. Until now we didn't hit this limit. What size do you think is useful without increasing it too much?
For the paths that are too long (with respect to the new limit) I will display an error notifying that that file is not added to the directory listing. Is this workable?
I have changed the version to 3.1.x-dev since 3.0.1 is D9
Thanks Vlooi, fixed in dev
I get it now: This is due PHP >=8.2
I will come back with a patch shortly.
Can you give me the steps to reproduce this? I can not.
Thanks
Hi Tim,
I will have a stable release for 3.1.0 shortly. Isn't that a better solution for you?
I don't want to work the D10 issues on two different branches.
I am not able to replicate this.
Take a look at attached screenshot.
Drupal will handle this and I just checked it and it works file.
Can you have another look and provide more info?
The fields on the dir-listing nodes are not real fields. The are injected on the node-create or edit form to create a Filebrowser object. that was a design choice early on on the design of the module. That is why Populate module will not work.
It is definitely doable to make it work, but I will not be able to find time to work on it at this moment.
If anyone wants to work on it please feel free to reopen this.
Fixed in rc-2
OK, that's a compatibility issue with D10 that requires explicite access check. We fixed it several other places but missed this one.
I will fix this coming days.
Your request contains two parts:
1. Provide default configuration for folder path.
2. Accept token for the folder path.
These two will indeed facilitate programmatically creation of directory listings.
We can sure add a configuration for a default folder path.
Please refer to
https://www.drupal.org/project/filebrowser/issues/2941911 →
to read the discussion on using tokens in the folder path. We have to make sure that once created, the directory name does not change accidentally due to a unstable token.
I short time I have no time to work on this, but if you want to provide a patch, make sure to also include the update for the configuration in the install.yml file.
Please provide all work for D10 on Filebrowser 3.1.x
Hi,
3.1.0 dev should compatible with D10.
Did you ceck that out already?
Hello jmaerckaert,
The D10 development is by branch 3.1.0:
https://www.drupal.org/project/filebrowser/releases/3.1.x-dev →
Is this what you are looking for?
I will close this one, feel free to open it if and when needed.
If I remember well, that class was removed because it is not necessary.
But I will have to check further, I don't think that code was removed by accident.
On my system it working properly on a D10 install: