How important is the "files" table in drupal ?
birwel - April 26, 2009 - 12:25
I just wanted to know if the "files" table has an important role in module development.
I mean, if your module deals with file uploading, why should be useful to register the
uploaded files in this table?
I have seen that can be useful if you are dealing with temporary files, but, using permanent
files, should I register my files in this table ? IS there any advantadge ?
Any answer would be very appreciated.
Thanks!
The file's uid could be handy
The file's uid could be handy for ownership and the filesize for upload quotas. There is also filemime.
The core upload module uses a few functions which query the files table: an upload_file_download() hook function which gets the filemime and filesize, the file_space_used($uid) API function, and also an upload_total_space_used() function. But I guess you could handle your files in your own way if you don't mind much about interoperability with other file modules.
Thanks cog! anyway... as I
Thanks cog!
anyway... as I use my own upload system, I think I should query by myself the mime and filesize to make the proper insert in the database.
After reading some articles
After reading some articles over the network, I've realized that files table
has a very important role in sites migration, specially in a relocation of the files folder.
Anyway, the idea of a "centralized" files table, seems not totally consistent at
the moment in v6.x, as for example, when you create a new HTML content linking to
some internal images, you can use an uploader assistant (as IMCE) wich deals
directly with the files table, but inside your node content you'll get an
<img src='path/to/file'>wich breaks the purpose of all this.If you have to change your files path, will you have to parse all your node's HTML content
replacing every path inside it?
Maybe a solution could be to use references to files inside HTML code like
<img src='{fid}'>being fid the file id, and doing a pre-parsing before showing up the node ?I don't know if something like this is being applied in v7.x
There are a couple of filter
There are a couple of filter modules which somehow deal with the links in the content, such as http://drupal.org/project/pathfilter and http://drupal.org/project/pathologic
In PHP it is easier. You can just
print base_path() . file_directory_path() . '/' . $filename.The "files" table does not store the base path of the site. I don't know if it is possible to make it less intrusive. File paths must be stored somehow, otherwise how could they be identified, assigned to nodes, users etc.
Modules like IMCE are smart enough to insert the links correctly, but there are limitations to what they can do. The problem is that if you are using clean URLs the links *must* have absolute URL paths, beginning with a front slash and the site's base path (if there is one), like /devel/path/to/files/filename, which are unmovable to a different base path without editing all the links the content, as you noticed. Relative links won't work with clean URLs (because http://example.com/node/15 + path/to/file = /node/15/path/to/file).
This is not the fault of the files table, because it doesn't even contain the base path. It is the price for using clean URLs: You just can't move between different base paths without editing the links.