File system (D7)

Last updated on
6 October 2020

Now that the hook_file patch has been committed I'm trying to keep the files in core movement moving. Some of these have issues on d.o and others are still in the brainstorming phase. Feel free to add your own ideas or add comments to discuss the ones already here.

UI/Admin

#357403: Move user picture to managed files

#322287: Add file.module to provide UI for managing files Add a module to provide a UI for managing files.

#391330: File Field for Core Oh, sweet.

API Changes

#348201: Multiple load files

#334303: Handling overwriting of managed files (with unittests!)

#373502: Add function to delete unmanaged files recursively

#203204: Uploaded files have the permissions set to 600 Make it easier for contrib to get the permissions right when creating files and directories.

#515280: file_check_directory() should create recursively

#438414: hook_file_download() should pass $file objects rather than $filepath

#166759: Public/Private File Handling

#227232: Support PHP stream wrappers PHP allows users to implement their own stream wrappers. This makes it possible to access virtual or remote filesystems as if they were on the local disk using fopen(), unlink(), file_get_contents() etc. The files may be stored e.g. as real files on a central server, as virtual files in a database, on remote a storage service like Amazon S3.

#353458: hook_file_references() was not designed for a highly flexible field storage Scrap hook_file_references() and force modules to record usage with file_add_reference($file, $module_name, $table, $id) and release a usage with file_remove_reference($file, $module_name, $table, $id). These functions would store the usage data in the {file_usage} table that would have fields for: fid, module, table, id, and count. This would let us check usage by querying a table, give Views an easy way to join files to nodes, comments, users, etc, and make it easy to build links to places where a file is used.

Rework the file_validator_* functions to provide help messages. It'd be cool if, given no file but the parameters that will be used on the file, the validator functions would return a nicely formatted message suitable for telling the user what restrictions are placed on the file and any transformations that may occur.

#348993: Use exceptions to report file.inc failures Remove drupal_set_message() and form_set_error() calls from file.inc. It's really annoying that file_copy() reports errors via drupal_set_message(). Now that we're PHP5+ we've got exceptions that could be used to report errors back to the caller and the caller can either act on them or report them to the user.

Access control! Right now access to nodes is controlled by their associations to nodes. But when you're able to reuse files between nodes you run into the question of which files should the user be able to reference. We need to provide a framework for modules to ask "should this user be able to reference this file?"

{files} Schema Changes

#329301: Rename {files} to {file} and add unique key to the filepath column Having duplicate entries for a single file makes them much less useful. The problem will be figuring out how to let modules know that fids they'd referenced have changed. Perhaps we'd just set a variable with a mapping between new to old.

#366464: File table includes file_directory_path() Store file paths relative to Drupal's files directory. Currently we store file paths from Drupal's root and the default files directory is sites/default/files meaning that if you upload files and try to move the files directory you'll have to manually update the filepaths in the {files} table.

#33482: add 'module' column to files table If only so you know who to blame for crap in the files table.

Developer Experience

#380064: DX: Make file_scan_directory() use save property names as file_load()

#331171: Allow modules to alter the MIME extension mapping rather than setting a huge variable Module developers should be able to alter the MIME extension mapping by implementing a drupal_alter() hook rather than by setting a *huge* (performance-degrading) variable.

Add a file_save_from_url() function that starts an asynchronous download to fetch a remote file and add it to the files table. Run some validators and then call a callback function so the caller can process it... or perhaps they'd just see the hook_file_insert() call and we'd put something into the $file object so they'd know it was theirs.

Help improve this page

Page status: No known problems

You can: