empty files folders for each page

[BernhardBaumrock]

Short description of the issue

It seems that ProcessWire creates an empty folder for every page that has a file (or image) field on it.

There is this topic in the forum that says this has been addressed several years ago, but testing a new module with 100k pages I realized that I have 100k empty folders in my installation! https://processwire.com/talk/topic/1585-module-clean-empty-directories-from-siteassetsfiles/

Expected behavior

The folder should be created only if a file is uploaded to that page. It should be removed when all files are deleted to keep /site/assets/files clean.

Steps to reproduce the issue

1. Install PW, choose default profile
2. Create a new page, template "basic-page" (having an "images" field)
3. There will be an empty folder /site/assets/files/#newpageid#

Setup/Environment

• ProcessWire version: 3.0.99
• PHP version: 7.1.6
• MySQL version: 5.7
• Fresh install with AOS + Tracy

[szabeszg]

I can confirm that empty folders still get created "sometimes". I have never been able to tell when and why, and I've been observing it ever since I use ProcessWire which is since 3.x very first dev versions.

[ethanbeyer]

In my experience, they're created whenever $pagefiles = new Pagefiles($page); is run (wire/modules/Fieldtype/FieldtypeFile.module is rife with these calls).

You could use a LazyCron hook to run the clean() method from Ryan's 2013 module: https://github.com/ryancramerdesign/PageCleanEmptyDirs, though it would probably make sense for a Pagefiles object not to be created/destroyed if the $input->post->field count is 0.

[ryancramerdesign]

If you've got a files or images field on the page, then it's going to create a directory for it, whether you've uploaded files to it or not. Likewise, if anything has asked for the path to where the page can store files via PagefilesManager, it'll make sure there's a directory where files can be stored. Though if you don't have any files field on a page, chances are there won't be a directory for it. What was changed (years ago) is that PW used to maintain directories even for pages that had no files fields, which it no longer does, unless something makes an API call asking for a location to store files for the page.

[BernhardBaumrock]

Thx @ryancramerdesign for clarification. Would it be very hard to have folders created only when a file is actually stored for that special page? And remove the folder when the last file is removed? Imagine situations where you have 100k pages with a file field and only one single page would have a file uploaded. That would mean having 99.999 empty folders which is really not the best way of dealing with such a scenario.

This is quite an issue here because copying files over (to the server or to a flash drive or whatsoever) takes ages because of the empty folders and is in fact totally useless. There would be an option to skip empty folders but still I think folders should only be created when they are really needed.

Thanks

[ryancramerdesign]

If there's any kind of files field on a page, then there needs to be an associated directory present as well. If that weren't the case, any code that deals with files (whether core or 3rd party, modules, etc.) would have to ask for the path for files, then check if it exists, and then create it manually if it doesn't. As it is now, when code asks for the path for files, that code can then assume it can write to that path. If that weren't the case, plenty of things would break. To avoid having directories created, avoid putting files fields on templates that don't need them. No directory will be created if the page doesn't have any files fields, unless some other code is asking for files access. It is okay to delete empty directories if you want to, but note that PW will re-create them so long as there is a files field present. So you'd want to remove files fields on templates where you don't need them before removing empty directories.

[BernhardBaumrock]

Ok, thx for the explanation! I still think that this is not the best way to handle files for pages, but I see that it seems to be quite an update... Maybe that could be an item for version 4.x ;)