Image folder discussion-- AGAIN

[jcc5018]

So, i have seen this posted a few times, and it does not appear you all plan on implementing it, but I would like to bring up a potential problem that you may want to keep in mind.

Although I am not an expert on LINUX , I do know many web sites are hosted on linux servers and I do believe that there is a cap of 32,000 sub directories within any given folder. So while your plugin may work for smaller websites, any photo sharing site such as social media, ecommerce, or even a photographers personal website, may run into issues when using your package if a lot of images are being stored.

I know the general solution is to create a custom path generator, but personally, I dont know how to go about that, and I think many others may be in the same boat. So my request is to consider a possible native folder management solution, or perhaps at minimum, some sort of extension people can install to rectify this for people who need it. Or docs with some sample modifications for people who arent as experienced in programming.

Additionally, as pointed out by the filamentPHP plugin that ties in with your package, your current system does not appear to allow users to connect a single image to multiple models, at least without a second row of data without all the same inputs for the file data.

This could easily be rectified by splitting the table as such:

Note: I added some image manager columns to the mediable table to account for that plugins method of making files reusable with the intention of a mapping solution in case a developer changes his mind about using the package, however the concept still stands.

If a user on a social media site wants to use one image for their profile picture for instance and then use it in a group picture or comment, or where ever, that user can select from preexisting photos and connect it to the relevant model instead of uploading the same image multiple times.

At minimum, a folder system based on collections would go a long way, but there may be a need to divide up larger apps with more than 32k given models such as users. So potentially some sort of system that divides up based on user names, or automatically creates a new folder directory after 32k records. or something of that nature if that linux restriction is actually an issue.
If every attached model had its own folder of connected images, that may help reduce the overall directory nodes. You would only have to manage how the model directories get sub divided. Which may be manageable with a folder or path column.

Just some thoughts. As it stands, I anticipate that I am going need to ditch your package or heavily modify it if my app comes anywhere close to its planned potential.

It wont take long to gather 32k users once my site is active, each with at least one profile picture, plus other models with their own media. Has your package been tested with 32k+ media folders on a linux server?

[jcc5018]

Something to consider...

As i said, I do believe the sub directory structure is limited to 32000 folders, but I do not think actual files are limited.

I am wondering if you reversed the structure so instead of media/1/conversions/etc, What if you instead had a media/original, media/conversions/ etc (2-3 directories) and the appropriate file name would match in each directory. Perhaps with prefixes that indicate owner, or model attachment,.

so in most cases the original folder may never get touched and could be archived, but the conversions folder, you would simply have to find the file name. any deletions would have to reference all relevant folders of course, but this would prevent any sub directory limitations

Though i would still recommend folders based on collections as well which would be doubtful to exceed 32k records.

media/{collection}/original | (conversions, etc), this would be helpful in distinguishing site files, vs user images for instance. If you did include collections, other folders could be made for each conversion type (thumbnail, profile, etc)

And i know a change like this would mess up a lot of people who use this package, so if it cant be automatically updated, perhaps a "medialibrary-folder edition" package could be created.