better file manager back end
Permalink
I think that Concrete5 could use a better file manager back end. Why can't some of these directories and extra files go into a database. All these iNodes cause me to run into roadblocks on my shared hosting account. I have heard of others, who have a few, or even several hosting accounts to spread out their concrete5 installation. Not only that, finding files manually becomes a big issue. I can't just download a few folders and have all my files there. What's the reason that the folder names, can't be integrated right into a single file name, that's the database helper file for each file? This would cut iNode usage by at least half! and cut down on server access by the same amount.
For now I'm simply using a manually controlled folder structure.
Regards, Rigel
For now I'm simply using a manually controlled folder structure.
Regards, Rigel
A few points:
1. I don't think the versioning happens quite like that. Files are versioned independently of pages. Pages typically point to "the current version". I can't think of a situation in which a specific version of a file is referenced. I could be wrong, though. (I think this will begin to cause issues when c5 starts getting used by large clients who need to store that sort of snapshot, but i digress...)
2. But, yeah... at the end of the day, a lot of files could *theoretically* be stored on your filesystem. Some sites might have 100, some might have 100,000. Imagine how many different copies of "homepage.jpg" there might be on that site. I think c5 made the right decision to have /xxxx/homepage.jpg and /yyyy/homepage.jpg rather than homepage-zzzz.jpg. (So that addresses why you won't ever have a easy-to-browse directory structure.)
Take that one step further, and while total inodes can be a problem on some servers, inodes per directory is a more pernicious problem. So you don't want /files/1/ to /files/100000/, which is why c5 has /files/xxxx/yyyy/zzzz. It's huge overkill for small sites, yes, and I wish there was a way to solve it, but it's surprisingly "future proof".
1. I don't think the versioning happens quite like that. Files are versioned independently of pages. Pages typically point to "the current version". I can't think of a situation in which a specific version of a file is referenced. I could be wrong, though. (I think this will begin to cause issues when c5 starts getting used by large clients who need to store that sort of snapshot, but i digress...)
2. But, yeah... at the end of the day, a lot of files could *theoretically* be stored on your filesystem. Some sites might have 100, some might have 100,000. Imagine how many different copies of "homepage.jpg" there might be on that site. I think c5 made the right decision to have /xxxx/homepage.jpg and /yyyy/homepage.jpg rather than homepage-zzzz.jpg. (So that addresses why you won't ever have a easy-to-browse directory structure.)
Take that one step further, and while total inodes can be a problem on some servers, inodes per directory is a more pernicious problem. So you don't want /files/1/ to /files/100000/, which is why c5 has /files/xxxx/yyyy/zzzz. It's huge overkill for small sites, yes, and I wish there was a way to solve it, but it's surprisingly "future proof".
Whenever a page is saved, a new version is created and that means that each asset on the page, including blocks, files and images, is also versioned. This allows you to revert back in time and grab the actual images that were used on that version of the page. I fully agree that there needs to be a way to properly house-clean this structure and delete unused versions of images.