Use the Drupal "files" Table for file records
| Project: | Web File Manager |
| Version: | 6.x-2.9-alpha2 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
WebFM currently manages it's own table for storing file information. While this is fine for data that WebFM needs to hold for files that isn't supported by Drupal core (such as ftitle, fdesc, fcreatedate, flang, fpublisher, etc.) not storing basic information such as fid, filesize, filemime, and filepath in the "files" table is working against Drupal core. It'd be much more Drupal-friendly if WebFM stored files in the files table, then you referenced the extra data from the webfm_file table by FID.
Some reasons why you should store files in the files table:
- Views integration for the files table is automatically available (though you'd still need to join over to the webfm_file table for extra data)
- Other modules expect to be able to find universal information about any content files in the files table.
- You can eliminate a lot of redundant code by using core functions that are available for saving into the files table, such as file_save_upload, file_set_status, and file_space_used.
- It prepares WebFM for Drupal 7, where the FileAPI is even more extensive and more powerful thanks to the file hooks... but only works with files in the files table.
- If you do this in Drupal 6, you can still leverage all the benefits of the Drupal 7 APIs by working with FileField (which includes a very, very similar API, as it was the prototype for Drupal 7) or by using the backport of the File API included in the hook_file.module.
- It would make integration with IMCE easier, which automatically puts files into the files table.
- And lastly, just because you're supposed to.
Now, with all that said. I understand why WebFM doesn't do it this way... basically because it always has. In Drupal 5, the "files" table was reserved exclusively for upload.module, other modules trying to use it would run into all kinds of trouble. But this all changed in Drupal 6 with the #115267: Simplify File Uploads, Centralize File Validation and Quotas, Fix File Previews.... path, when the files table was opened up for universal module use.
The reason I'd like to see this done is so that WebFM can share its files with other modules, such as allowing the WebFM file manger to be used with FileField Sources module (see #436396: support for webfm popup). But until WebFM uses the files table, it's an island all by itself that no other modules can integrate with, unless they lock themselves into WebFM's completely separate APIs. Considering the better alternatives that will be included directly in Drupal 7 (and already available in Drupal 6 contrib), building on WebFM as it is now seems like a dead end.
#1
subscribing, love to see this :)
#2
Thanks for your candid assessment. The module in fact started with version 4.7 (http://webfm4.vera-ikona.com/) and has filled a niche for file management that Drupal ignored (In fact, afaik, this post is the first time a 'core' developer has acknowledged the existence of the module). We had institutional clients at Web Networks who needed an intranet style document management tool and there was NOTHING out there in open source, so I built it. Six months previous to starting down that path I didn't even know html so it was a great way for me to learn the stack (I was an embedded RTOS developer). My hat is off to Oliver Zielke of Web who agreed to pay developers to build this module for the open source community.
That said, there were design decisions made in 2005 that I might not have made today. I agree in principle that code reinvention should be avoided however my caveat is file security which is the raison d'etre of the module. Having my own silo not only prevented WebFM users from monkeying with the files of other modules (webfm root CANNOT be the "File system path" set in admin/settings/file-system) but also prevents other modules from monkeying with private file data. If another contrib module can do what it pleases with a webfm file path then all bets are off that a client can keep documents private. Yes, I know all a contrib module needs to do is to query the webfm_file table to shatter my illusions, but there has been no compelling reason for other modules to do so up to this moment (call me a fanatic but I've never liked the Views module). In fact the only reason I haven't moved the files entirely out of webroot is due to my time constraints - I don't develop opensource sw for a living anymore. The only way I'll entertain the suggestion of joining to the files table is if I can avoid using file.inc which is based on file placement within webroot. Ostensibly the filepath of the files table would be a path to a webfm gateway which can guard access to an external file area.
I gotta run. To be continued...
#3
Core definitely has its limitations (one file system root) and downright irritations (like private files are all-or-nothing). Just as a potential idea, you can still use the files table to store these files because the filepath column contains the entire path, including the system files directory. So it's very possible to store files from the WebFM separate file directory in the files table, though you'd have to do hacks to get core to switch between file system roots. Something like $GLOBALS['conf']['file_system_path'] = 'webfm_root' could do the trick for temporarily switching the file system root (again, not sure if I'd do this, just thowing ideas out there).
#4
While in the past there was a specific reason for using our own file table in WebFM (circa 4.7 5.x - Files were strictly associated with nodes and not users) that limitation has since passed - but as discussed there are still some other limitations.
When the module was ported to 6.x it was a minimalist port that had one goal in mind: get the module to 'just work' in Drupal 6. At the time I was aware of changes to the file API and the table structure, but did not do a complete port. (Another example is changes in Drupal's core JS features in D6 that could/should be taken advantage of - but currently aren't).
Long story short it is worth the effort to get webfm off of its 'island' and take advantage of several changes available in D6+
#5
I think it's worth the change, it will allow us to use webfm instead of imce for file browsing for starters. I also like the possible integration with filefield sources.
#6
Subscribing to this thread :)
So nice to see WebFM recognised at last, I am more than happy to help with testing etc. too.
If we can get WebFM to function with the Drupal files table and then CCK, we'll be able to integrate the Search Files module without having to buld a bespoke driver for WebFM.
100% Win!
#7
I use webfm and I would love to see it. Subscribe
#8
If this would make views work, I'm all in. I don't mind testing it.
#9
Oh! This issue just spoilt my day. Was just evaluating this module for a new project and I had assumed it was using the core file table! I wish I had the budget to pay someone to do this!
#10
Maybe we could organise a "chipin", I would be happy to help fund this.
#11
I would be happy to give some of my time or to 'chipin' to get this module of its "island". It would provide added value when used with very useful CCK FileFields Sources module, and making fields available to Views module, plus many others.