Submitted by dave on Tue, 2006-05-02 23:34.

I know I'm not the only one feeling limited by Drupal's current file
support. Here's a write-up of ways I think it could be improved.
Comments are welcome.

File Realms -

Currently, the only system-wide file settings are

• where uploaded file's are stored (all in a single directory)
• whether files are transferred by Drupal, or the web server

You must transfer files by Drupal if you need any sort of access
control. But this adds significant overhead to each file
transfer and is problematic for high traffic sites. In many
cases only some uploaded files require access control, so ideally
only those would be transferred by Drupal and the
rest would be transferred by apache.

I'd like to solve this by introducing File Realms. Instead of a
site-wide file configuration, the administrator creates any
number of File Realms. Each Realm has it's own configuration
consisting of

• Name - Like a View name, this is used in PHP code and naming hooks.
• Whether files are transferred by Drupal.
• Where to store - This is not simply the name of a directory,
  but a string which uses a strstr() substitution to define exactly
  where and how the saved file is named. A value might
  be "files/%name". Another example would
  be "/my/file/path/%nid/images/image1.%suffix". Let's say the
  user uploads "attachment.jpg". The former setting would save a
  file to files/attachment.jpg. The latter would save it to
  /my/file/path/42/images/image1.jpg (42 is node ID). Note how
  much flexibility this gives in where the files are stored.
• Permissions (read, write, execute, etc) - controls the
  operating system permissions of each file in this realm. Also
  for any directory that had to be created to save the file.
• Maximum disk space to be used by the Realm.

Creating a new File Realm will have several effects immediately
visible to an administrator.

• New permissions: 'view REALMNAME files', 'upload REALMNAME
  files'. (If files are transferred by Drupal for that Realm.)
• admin/settings/content-types/NODETYPE: here you find a
  fieldset 'REALMNAME Attachments' (enable or disable). Like what
  the upload module inserts into this form, but one setting per
  File Realm. Each node type may have attachment from any number
  of Realms.

APIs -

These give developers finer control over how node forms prompt
for attachments, how attachments are displayed, and which users
can download the attachments.

First, we do away with the hook_file_download mechanism. In its
place Drupal provides a callback similar to ?q=system/files, but
instead of calling hook_file_download to learn the proper
headers, it gets the headers from the database. It calls
hook_nodeapi with $op == 'file download' and only allows the
download if positive permission is returned. This sort of
permission check will make it easier to develop file products
where only those who have purchased a product may download the
file(s).

Provide an easy way to add a file field to a form. This allows
developers to prompt for specific files needed by a node. It
would look something like:


$form['filerealm']['image1'] = array('#type' => 'filerealm_file', '#realm' => 'REALMNAME', '#title' => t('your image'), ...);
 

So simply adding a field like this to a form will take care of
everything. No extra code to save uploads and such. Once the
node is loaded, file information can be found in
$node->filerealm['image1'] which can be used in node_view()
and other functions.

The REALMNAME may also be used in hooks to override default
behavior. For example, theme_attachments_REALMNAME() would
control how the attachments table is rendered.

Implementation

I would implement the features described here in a contrib module.
With the hopes that it might make it to core drupal if widely adopted.

The module would define a new node type 'file realm'. Creating
one of these nodes is how an administrator
defines a new file realm. Each of these nodes stores the
configuration described earlier.

(Side note: one of many reasons to store the realm information as
a node is to facilitate batch import of files. Each such node
could have a batch import form, which takes files from a
specified directory and updates the database to make them
attachments to the realm node itself (since you have to pick some
node to import them to). Files attached to realm nodes could
later be transfered to other nodes.)

The database structure would be virtually identical to the files
and file_revisions tables as they are in Drupal 4.7. With the addition
of a 'realm' column to store the realm name.
If such a column is added to Drupal's table
we would not need to create another.

Many implementation details would no doubt have to be figured
out. But this is the direction I would go.

login or register to post comments