[discussion] Ground-up rewrite of WebFM

The first three items are de rigueur, however as the inventor of the module with over three years of support (albeit fitful) you'd think an offline query might have been in order wrt a complete rewrite.

Abstracting the UI to a cloud or local backend sounds good - Andre and I talked about it in the past but were too busy to pursue. Taking the file handling outside of Drupal will require a clean break from file.inc. webfm_file.inc doesn't reference file.inc, however webfm.module still uses file_transfer(), file_directory_path(), file_check_directory(), file_save_upload(), file_move() and file_delete(). These calls will need to be abstracted. Not trivial overall.

The javascript is ad hoc and could use a framework (so far I've had a 'if it ain't broke...' attitude). I don't recommend jquery due to the heavy 'object' nature of the code. I think MooTools is a better fit though I haven't invested any time investigating. If I continue any relationship to the module it is in this area I'd be most interested.

One scheme that I saw elsewhere that I thought was a great security enhancement for local storage was base-64 encoding file content and adding a .php extension with a added die header at the start of the file. This way all files are made inherently non-executable. Not sure what latencies would be introduced by the encode/decode operations.

Another opportunity is the semantic web stuff whereby file content metadata should be in rdf. I cannot intelligently comment on this since I haven't looked much into that world.

One potential source of opposition to this are some who would rather see the module mesh closer with Drupal - reuse of the files table, leverage hooks to other modules, etc.

The users of the module (of which I am one) definitely get more than a say since they have contributed many essential patches over the past couple of years. My concern is keeping 2.x working and supported until a 3.x branch is ready.

jQuery is fantastic for what it was intended for - enriching presentation, however my javascript code does much more. A JQuery port would improve some cross browser issues and reduce the amount of code transferred at page load, however manipulating complex file and directory objects makes much more sense in an OO architecture. The bias at Drupal was for years against javascript (modules are supposed to degrade to php only functionality) and it figures they would pick a framework that is primarily just window dressing.

Hi Cameron,

thank you very much for your time and passion. I'm really glad to read that somebody's working on this module.
I think a PHP5 dependency shouldn't be the problem. The most hosting providers have switched to PHP5 already. And IMO it's not efficient to limit the development progress because of a minority group of PHP4 users.

You asked for input:
1. A must-have we REALLY urgently need is a multiple-file upload. At the moment it's frustrating that the core functionality is not given. Due to security reasons by far not every end user has ftp access but sometimes has to upload umpteen files to WebFM. I think I don't have to illustrate that it's a pain.
2. I think it would be great to have the possibility to create blocks wether of the whole WebFM repository or an instance (i.e. folder "xyz"). That would provide much more flexibility -> we could embed/print this blocks individually into QuickTabs, regions, nodes etc. with appropriate permissions.

Kind regards,
Stefan

I would like a lot to see this feature in the oficial code:

http://drupal.org/node/555528

With this improvement you are opening a lot of doors to the use of this module.

About PHP5, I don't think it will be a problem. The actual code works on PHP4 and when you release the version 3.x almost everybody will have the PHP updated

And, by the way, a lot of thanks for mantain this code :-)

I was wondering when this discussion was going to start...I've been waiting for this a long time :-)

Actually I oppose a the complete rewrite: It will take a long time to be done - the normal tree will hurt from this. Also the usual reason for a complete rewrite - chaotic code - is not a problem in webfm.
My suggestion is to gradually improve parts of webfm (small tasks) instead of taking on the whole thing at once: This will ensure quality because we can test whether the aims where actually reached and squash bugs faster as well.

These are my thoughts (no specific order):

User Interface - Refreh Look

Maybe we can rework this a little? There are a lot of file browsers out there - and I don't think there is a reason why webfm can't have a refreshed look.

User Interface - Remove Right Click Menu

My pet peeve - it would be nice to get rid of this. We could have a little icon (gearwheel) next to the file names that opens a dropdown list with the tasks. It would also be nice if one could define the default task through the settings. I would suspect "Attach to Node" to be the default, but usually it is "open file in new window". We could make it possible to (de)activate actions through the settings as well.

User Interface - Rework Meta Data Interface

An other thing which always bothered me is the MetaData dialogue: not very intuitive to use, options aren’t accessible from the outside and/or not needed. This should also somehow be connected to token.

Remove Index this directory

This button should be removed – why isn’t the directory automatically indexed or why do we need to index it? It is almost impossible to explain this reasonable to any user.

Views/Token integration

In order to allow users to work with webfm files across modules we should provide more tokens and views integration

wyswyig-api integration

To allow users to use webfm with there favorite wyswyig –editor we should support wyswyig –api for the editors supported with wyswyig –api in webfm core.

Rework the rights management.

There are lot of questions about this here - the main message appears to be the same: I don't understand. In my opinion the way rights management is current implemented is also a break within drupal: Usually you would expect it to be at admin/user/permissions. I have some more thoughts on this – if there is interest in this I would explain further.

Side notes:

Breaking away from Drupals file handling

I am sorry, but this doesn’t sound too good to me – we should be more oriented in facilitating drupals methods – only this way other modules can plugin into webfm files as well

base64

Sounds strange to me: If I would want to move away from webfm all my files would be broken. Also one would have to decrypt on the fly – this takes place in webserver memory.

I'm not an existing user, although I'm considering trying this out as I've got a client who's having difficulty with the document management I've set up using filefield, CCK etc.

I'd argue that WebFM would benefit from closer integration with the rest of Drupal. Currently, core and popular contributed modules can make up about 90% of a well integrated document management system. A ground-up system would be better off focusing on filling in the gaps with a set of smaller contributed modules and creating a recipe to bring the various modules into a unified solution, rather than rebuilding a separate all-in-one application. It may also be better off doing so from a Drupal 7 base, as that has fields, RDF etc. in core.

Some of these modules might include:

• Instead of abstracting file handling to the cloud just for WebFM, why not contribute a module that enables e.g. the entire files directory or various subdirectories to be stored in the cloud?
• A module that gives finer-grained user permissions for file manipulation, including per-user or per-role directory creation and access, and implements a revision system for files in specified directories.
• A browser module (possibly integrated with Views, and with file and image field editing in node edit screens) that integrates user permissions and directory access, RDF metadata entry and display, revisions handling, and file or image operations, including multiple upload, deletion, copying, moving etc. Ideally, when using the browser from Views rather than node editing, include a link to view/edit the node attached to each file or image. There are some potentially hairy issues around the idea of allowing multiple fields to point to the same content, but that doesn't need to be tackled if it's too complex. Having a joint file and image browser may also make it easier to find other developers to get involved.
• A separate module to add base-64/php-die protection to file storage. Not sure the encoding is a good idea in general though, for the reasons other people mention.

Hope that helps!

Hi Niels

I agree that a complete rewrite isn't necessary, however a proper abstraction of client and server sides would allow for alternative file stores. A proper client/server API wouldn't be a waste of time.

Wrt to some of your points:

• User Interface:
  The module always lacked proper themeing (I'm a systems programmer, not a UI designer). Drupal themes should propagate into the client side better.

  I have no issue with context menus other than the usual cross browser problems - a javascript framework would likely help solve this. Enabling/disabling the menu task list in the admin settings is a good suggestion.

  The metadata structure was built to satisfy the requirements of the original client of the module. It was never a meant to be a general solution but I didn't have the time and resources to properly implement a metadata layer. It definitely deserves rework. I'd be thrilled if a rdf person stepped forward to tackle this.

• Remove Index this directory:
  Not a clue what you are talking about. The module has no 'indexing' though it would be fantastic if a proper content search was integrated with the module. Currently the search is for file title only.
• Views/Token integration:
  I've always been suspicious of Views because of my concern for file security. Hopefully a views hook can be constructed that respects this.
• Rework the rights management:
  I'm not opposed to reviewing this but one must understand that file rights in the module are dictated by directory topology as much as by user id. It is similar to any file system whereby files and subdirectories inherit rights from parent directories. Of course this is a break from Drupal. Drupal doesn't have a filesystem other than the one it is encapsulated within by the server. WebFM uses a combination of the server filesystem and Drupal user security to define file rights.

  The current rights implementation is a loose approximation of the linux group-owner-world concept:

  • Group file rights are determined by a combination of directory topology (role root directory) and the file permissions set in the 'perm' column of the webfm_file table.
  • Owner rights are determined by the Drupal uid column of the webfm_file table. Owners have full rights for file operations except the for ability to move it outside of the group root directory or to remove it from the database. Only module admins can change the uid of a webfm_file record, move the file to a different role group or remove/add it to the database.
  • World rights are controlled by the 'WEBFM_FILE_ACCESS_PUBLIC_VIEW' bit in the 'perm' field of a webfm_file record (World users get no other right than read).

  This brings us to the 'perm' bitfield values near the top of webfm.module which is an approximation of the unix rwx:

  define('WEBFM_FILE_ACCESS_PUBLIC_VIEW', 1); //publicly viewable via webfm_send link
  define('WEBFM_FILE_ACCESS_ROLE_VIEW', 2);   //role can view/download file (owner/admin can always view)
  define('WEBFM_FILE_ACCESS_ROLE_ATTACH', 4); //role attach permitted (owner/admin can always attach)
  define('WEBFM_FILE_ACCESS_ROLE_FULL', 8);   //role modification of file permitted (owner/admin can always modify)
  

  These bits determine how the uid of a Drupal user affect file access. I'm open to debating these control bits and how they are applied. Perhaps a traditional rwx triad would be better.

• base64:
  Not so strange. Only real tests will determine how inefficient this scheme is - I suspect that packetization is more of a bottleneck. I'm not recommending this for a cloud scenario - they have their own file execution protections I'm sure.

Another point that I've made a few times in the past is in regards to file/directory contention. Php's System V IPC should be investigated as a way of preventing multiple users from operating on a file/directory simultaneously. For instance, if I attempt to access a file that has is being moved to another directory by the file owner or admin, there should be feedback that states that the file is locked by another user and that a refresh is required. Likewise an admin who wants to rename a directory while users are operating on files inside that directory might be denied access (I've actually never done tests on this). The stumbling block here is the recompile of php required for System V semaphore support since it isn't enabled by default. Administrators who want to use the module as a 'sharepoint' replacement will insist on this feature.

Wrt comment #7, breaking the module into multiple modules doesn't seem like a simplifying exercise. Integration is a good thing but sometimes it just isn't perfect - Civic crm is a case in point. A D7 guru should step in to comment on how changes to the file api can be leveraged by WebFM.

A missing feature that keeps us from using webfm for certain pages with dozens of files is a multi-attach and (and maybe a multi-href-insert).

Attaching 30 files one-by-one is nothing you would like to to because for every file you need to scroll back and forth if the list is too long.

And I still hope for http://drupal.org/node/285455 to get included.

Except from that, webfm has all I need ;-)

I am afraid Frank has a point: 1-3 are going to take a long time :-)

I think a useful feature would be an alternative way to attach files, that is having a 2-pane page with the list of the nodes on the left e webfm on the right. The files are attached by dragging the files from webfm to the right node in the left pane, more or less the same that now happens with folders...

I am not an expert of javascript: do you think such a feature is implementable?

I would like to thank robmilne for a great module and I am very glad this module looks like it will be supported in the future by cweagans.

I agree that #1-3 should be the priority and are not trivial.

I also share concerns expressed by Niels Hackius when he says "Actually I oppose a the complete rewrite: It will take a long time to be done - the normal tree will hurt from this... My suggestion is to gradually improve parts of webfm (small tasks) instead of taking on the whole thing at once: "

I would also like to mention that in the planning for this project by the time #1-3 are done Drupal 7 will likely be breathing down on us all. I am concerned if a complete rewrite is tackled that we will all be waiting until long after D7 is released before we have the rewrite of webfm for either D6 or D7.

Planning for the future of the product is great, but if it leaves the existing branch of the code high and dry without support on D6 and without a working port for D7 (and I think this is very likely to happen with a rewrite), the community of exiting users will really suffer.

Please be wise in considering how much you tackle at once, and include a useful port to D7 in the planning for early next year.

help~

webfm the file upload, file names will lead to problems in Chinese

webfm can add [Default permitted file extensions ]

Posted some thoughts over here: #604018: WebFM for Drupal 7 and changed my mind:

If we are going for D7 this module must be rewritten in huge parts.

Some thoughts about WebFM rewrite, from a user.

1) I only want my files on my server, nowhere else. As it is is fine.
2) Indexing is bothersome, but being able to upload to a directory via FTP and then having WebFM index things effortless is priceless.
3) I wish it were possible to download all files in a range of directories via zip. Maybe there could be a feature that would add files to a queue that could then be downloaded in a file manager. I know, pipedream.
4) The #1 request actually… it's difficult for users to drill down a tree and then get deposited back up to the top of the tree.

It's a great module though. Many, many thanks from my students and myself.

I like the look of this.
Any chance this could be connected to a hosted Sharepoint service ??

I'm building an Intranet for a firm that uses Sharepoint.
having the ability to include in nodes to the sharepoint server would be highly beneficial.

I'd like to echo the thanks and appreciation for those who have worked on this module! Great work! I look forward to the changes discussed.

@devondan - http://drupal.org/project/webfm_statistics is great for seeing who downloaded what...

My $0.02:

I seem to have a lot of download failures or partial downloads. I don't know if that could be something to do with the module, or if it is my host/ISP etc. If there would be anyway or tricks to help down loaders make sure they got the whole file it would be great.

I would also like to see Amazon s3 integration in such a way that the files can be protected behind registration and/or one time (emailed or displayed) links provided for the hard addressed s3 files.

The goals of your rewrite are mostly achieved by http://drupal.org/project/media already in D7, so maybe a better approach would be to work on a migration path from D6 WebFM to D7 Media module, getting WebFM plugins ported, etc.

D7 offers proper support for other file sources (S3, etc.) in core (pretty sure anyway), so at this point I don't think it's really worth trying to write all that again. If nothing else, you could use the Resource module from the D6 Media branch.

Media isn't ready for general use yet, but looks like it will be by the time D7 is usable.

SUBSCRIBE :O)

project file browser has download of directory as zip. I use webFM for upload and offer file browser for download. Both work together nicely.

Hi,
Changing to php5 is not a problem, my hosting provider runs php 5.1.9 and don't want to update for now, I hope it is anough.
I'd like to have the capability to define a default action when I make a left click to a file, attach to node will be great.
The counter should be visible not only into the metadata.
I really thank all authors and contributors to this module.

+100 on wysiwyg-api integration.

+100 on multi-attach.

Thanks for the right-click comment. Never occurred to me to look for anything other than cute little icons...

Is there a way to do plugins for the storage media, with the typical contribs directory? Might make for a more incremental approach than complete rewrite?

Thanks for this module, all. It's clean, rugged, simple, and easy to use. Please don't change that.

I remain quite interested in the feature discussed in http://drupal.org/node/394570

I'd love it if the webfm context menu actions could be performed on multiple files so I could delete or change permissions on many files at once.

Could we also have the status messages (such as "upload success") be customizable?

Hi Cameron (and everyone else who has worked on this module),

I think your idea for supporting multiple backends is a great one, and I'd like to suggest Box.net as one such backend. I work with the platform at Box, and such an integration could be achieved through our API. I'd be happy to provide any technical information you might need on this and be your point of contact should you need any help from our end. If you're interested or have any questions, feel free to email me at awillen@box.net.

Thanks,
Alex Willen

The easiest question to answer: Changing to php 5 only is not a problem.

I think the "rewrite vs. evolve" is a great question to ask of the user base and of yourselves. However, I think looking at the new, changed, or removed functionality proposed here first, then answering the question is the right order to go about things. Form (of change) follows function, yesno? D7 coming adds 1000x to the importance of getting this question right.

Webfm stepped in to fill some giant gaps in file handling present in 5.x that continued in 6.x. With D7 coming it looks like core, media, wysiwyg modules, etc. are finally addressing those gaps. I have yet to test the D7 way and modules enough to know whether they filled those gaps well or fully yet. So will webfm even be necessary in D7? Are there lessons learned in webfm that need to be taken to the devs of core, media, etc as good and bad examples? Should we be concentrating on an upgrade path out of webfm to "the D7 way" of dealing with files? We cannot separate these questions from the feature ideas already tossed around, as the answer to each affects the other, etc.

Assuming we as a community decide that we like the wheel we invented here in webfm, I propose the following feature and function ideas. I am sure these ideas are duplicates of what has already been said, but I am going to take the time to state them my way anyway. We are heavy users of web file manager on a few dozen production websites, and we've done lots of testing and tweaking to try things out, so most of these ideas come from actual workflow problems we have encountered in the past.

1. Multiple upload. Could be as simple as recognizing when a .zip, .tar.gz, or other supported file extensions are uploaded, and offer to extract to a new directory, current directory, and extract with x,y,z metadata set for all extracted files. However, being able to pick and choose specific files from the user's local machine would ultimately be less total time to get the job done most of the time. I have tried several of the flash based multiple uploaders available, and will not be using any of them on any production sites, period. If it can be done with js, java applet, or similar, fine, but no flash please.

2. Operations on multiple files. Several of our production sites already have 200-300 files per directory, and circa half a dozen role directories. Doing deletes on old revisions, changing owner/permissions/grants, bulk renames with a prefix or suffix, etc would all save us from "busywork". Yes, this can be done with manual SQL queries, multiple edits in phpmyadmin, etc etc etc, but the staff of several of our clients would be adept enough to handle this on their own (saving our time and their cost), if they had an appropriate multi-file operation gui.

3. Ownership and Grants. Convert the current "owner + role" system of permissions to one of owner + grants. See nodeaccess module, or the mysql idea of grants as both seem to work fairly well for controlling who can do what to what piece of data. Being able to grant a granted permission to a third user as well would be awesome.

4. Disconnect roies and permissions from physical directory tree. This might coincide with the "multiple backends" ideas being tossed around above. Bottom line is deciding what roles will end up where in a physical file tree _before_ you know how the users and different roles are going to be uploading, moving, using, sharing files is not helpful to developers nor users. Major pain to rearrange file structures when roles change, suborganizations or committees get started, etc. IF IF IF you keep the physical file and directory structure model, please integrate with the token module for mapping folder paths based on role, user, date, size, type, permission tokens, etc.

5. Discontinue use of the "right click context menu". This is the single biggest hassle we have had with web file manager. Still having problems with where this menu decides to show up in chrome on windows, chromium on linux, does not show up at all in opera on both, etc. Would rather see a column in the browser with an operations button, image, or text link, that uses jquery or superfish <ul> to menu expansion. See the nicemenus module for an example of "just works" cross browser menuing. Yes jquery is already deployed on basically all of our sites so hanging our UI on that would not slow our sites down one bit. In fact, it would be a great example of "one flexible framework reused intelligently / don't repeat yourself or anyone else" that drupal is all about, right?

6. Expose files as nodes. Yes, its a pandora's box, I know. The use case we have in mind goes something like this. User takes 30-50 photos of an event, would like it to turn into a gallery/slideshow/etc just by uploading the files, but will still be wysiwyg embedding or attaching one or two of those photos to other nodes throughout the site. WebFM is great at handling files, gallerix module is great at turning a zip into a gallery, others do some small part of that workflow. Exposing files as nodes (and therefore exposing them to views indirectly) means I can give my clients just one tool to manipulate files, and I can set up the display of those nodes, files, etc however they need automagically. Maybe this can be done by tying in closer to the core upload module and its hooks and methods instead of exposing as nodes, I don't know. Hooks into taxonomy for file metadata'ing would be great as well.

7. Inline filtering in the browswer and column show/hide. Think exposed filter in views, but for each shown column. Being able to show/hide file id, date, owner user, etc. would have saved us some time cleaning up a bad 5.x->6.x upgrade, and probably would be great for other use cases as well. Done well, this could support the multiple backends and disconnect from the "physical file directories" model mentioned above.

Last, a comment on RDF/semantic web features. I do not object to those being added in the future, with the following caveats. First, the existing rdf module sets are way too heavy, slow, inefficient for the benefits they provide. Any attempt to make webfm into a semantic web system needs to keep speed and simplicity at its forefront. Second, the rdf and semantic features need to not get in the way of how users are (unfortunately) comfortable with working with data: as a file with a name, a date, a type, etc. We are not going to train the windows explorer "model of the world" out of end users anytime soon. Third, if semantic web features forced us to use database storage for "files", we won't use it, as it would wreak havoc on our finely tuned backup and replication strategies.

Hope these ideas help (and please feel free to ask if my writing is unclear in any way). I know any of the above ideas would be a lot of coding time to implement... but I like that we are taking the time for "proper planning [that] prevents piss poor performance". Will be glad to test out whatever incremental or major rewrite changes come about from this...

Just wondering how the 6.x-2.12 release is coming along...seems like there hasn't been any activity since the module got a new maintainer.

Logging in for the first time in 2010 - looks like the current maintainer didn't have much more to say than the the previous two maintainers that I passed this module off to.

I've been asked to submit a patch to fix CKEditor support so a 2.12 release is forthcoming. I'll take a cursory look at other pending patches and might commit some of them if they don't take up too much of my time checking for consistency. My tone is reluctant, but as I've stated in other posts, life is short and I have too many other pursuits to keep my hands inside Drupal.

-rob

Sigh. I feel your reluctance Rob. If it can be said again, thanks so much for your time and talents so far.

It seems to me unless another pack of heros emerge to take WebFM to the next level it runs the risk of not being quite active/supported enough to fill its niche in production systems.

Realistically, I think higherform @#30 hits the prgamatic nail on the head...the future is D7 and file handling looks to be much closer to core. By the time *serious* structural and philosophical questions with the current WebFM are sorted through, the window will have closed and D6 installs will be creaking legacies.

Guess I need to start looking back at IMCE and forward to D7.

However I think so far we have been pretty good: Even if we didn't hear back from cweagans - there is great support from cgmonroe and rob. If rob likes I can try to co-maintain. However that would be only to push some patches through - I don't think I am going to be able to do anything "big".

I use Webfm for sharing files among a set of workers. I have been struggling to keep people interested in it for one main reason: there is no check-out, check-in. I migrated my site from another CMS a few years ago, and at that time, the other CMS had a very nice facility that assured that one worker could check out and work on a file, and then check it back in when done, and others could only read the file until it was checked in.. The admin could, of course, release a lock if needed.

I see no need for multiple file back ends, or for a major rewrite.

IMHO, becoming a full blown document management system is a little beyond the core scope of this project. Document management requires a bunch of features that a not really in line with WebFM. E.g., it would need ways that admins can override checkout (e.g. someone checks a file out and goes on vacation), track who made changes, keep old version around, and the like.

That said, I think it would be a good idea for WebFM to include an API / set of hooks or triggers that would allow a separate project to use implement something like this. E.g., be able to use Workflow or Rules to trigger a files r/w status, write log info, and the like.

Hi. I have just tried out WebFM for the first time as an image manager for CKEditor. I have used the FCKEditor for a long time, and am working on something new, and now FCK is CK, I thought it was time to look around at alternatives.

All I really need is what the FCK file browser had - make directories, up load files into them, put them into the editor. Auto generating thumbnails with links to original file, uploading multiple files and WebDAV would be nice, but in most cases we are adding one or two pictures to some text.

Being able to use a directory per role and a personal directory would be one thing I'd like.

If you are going to use the site theme for the interface, make sure it can be overridden with an alternative css file. Using the site backgrounds for a file management tool is often not a good idea - not with a fancy background anyway.

Anyway - my two cents. Just add that it is always easy to get frustrated with some code and get tempted to start again, but it is usually much more time consuming and difficult to re-write than you think.

don

Just to let you know, I applied for a scholarship for DrupalCon in Copenhagen and I hope to discuss some of webfms issues there. Especially keeping in mind a D7 upgrade path, finding a nice jquery replacement for the filebrowser and such "good" things.

I think the #1 issue should be cross-browser support. By this point in time, it really isn't acceptable to have a module only work as intended in one browser.

a.bond currently I am only aware of problems w/ Chromium. If you experience problems please open an issue.

Removed.

in google chrome (8.0.552.224) when using webFM as manager for attached files context menus thouse menus floats to much upward.

my solution to this is the following: in webfm.js update Drupal.mousePosition function

from

Drupal.mousePosition = function(e) {
return { x: e.clientX + document.documentElement.scrollLeft, y: e.clientY + document.documentElement.scrollTop };
};

to

Drupal.mousePosition = function(e) {
var st=document.documentElement.scrollTop || document.body.scrollTop;
return { x: e.clientX + document.documentElement.scrollLeft, y: e.clientY + st };
};

alexey.konkov, please take the time to search through the existing issue queue or file a new issue. this is not the place.

Subscribing.

PHP5 only? - Fine
Overkill? - For me, yes
Key Functionality?
- Drupal 7 support
- Database-blob based and not file based

I have a 6.x site that I want to upgrade to 7. I need WebFM but it isn't there. Bad news.

In the meantime, the file-based version has security issues for me. I use a shared hosting service and cannot control file access by roles. So, even though the restricted files are hard to find, they can be downloaded by unauthorized users if they know the URL. Very bad news.

I don't need any fancy stuff beyond this and am considering porting one of the other file managers rather than WebFM because of the security problem.

The files-based vs. blob-based approach should ideally be a configuration option.
Would it be practical to offer to use blob-based approach towards a DIFFERENT database than the web site is using, even on a remote/different server?
Having a way to avoid the main database growing enormously due to file attachments, both for database-size backup concerns and perhaps both performance and administration concerns.
If such concerns are addressed, I am much in favor of blob-based solution over files-based.
However, some of this may need adjustment as of how core handles files when saving nodes in the first place?

The files-based vs. blob-based approach should ideally be a configuration option.
Would it be practical to offer to use blob-based approach towards a DIFFERENT database than the web site is using, even on a remote/different server?

Having a way to avoid the main database growing enormously due to file attachments, both for database-size backup concerns and perhaps both performance and administration concerns.
If such concerns are addressed, I am much in favor of blob-based solution over files-based.

However, some of this may be dependent on how Drupal core handles files when saving nodes in the first place. I guess a blob-approach depends on changes to core?

subscribe

subscribe

Thank you for taking on the job.
PHP5 is not an issue.
Really need WebFM in D7 having made the upgrade. Old D6 functionality did the job.

hello I made some modifications for this module, i added a new column named "publish".
So if the file is checked for "Public Download" in that column it should write "yes" else "no".
But I`m not that good at js so I`m wondering how to get that variable that holds true/false or 1/0 for "Public Download".
this is what i`m trying to modify(beside the rest that I did, but this is where I`m stuck)
~ line 1550 just after displayColumns.owner.

if (Webfm.options.displayColumns.publish) {
		checks = (parseInt(Webfm.permKey[1], 10));
		elTd = Webfm.ce('td');
		if (Webfm.numColumns < 2) {
			elTd.colSpan = 2;
		}
		elTd.className = 'txt';
		elTd.appendChild(Webfm.ctn(checks ? "da" : "nu"));
		elTr.appendChild(elTd);
	}

I`ve attached a file just to know what I want to do.
I think this is better with published or not in a new column.

Thanks for the help
Xao

Folks - We were very happy users of WFM under Drupal 6. Back at the end of last year there was some discussion of a move to implement WFM in D7. We have two D7 sites that are crying out for the functionality WFM provides. Can anyone tell us if WFM will, indeed, be developed and released for D7 or, if not, if there's another way to get there. I know core provides some increased functionality with regard to file uploads, but we've not seen anything like the slick AJAX implementation of WFM anywhere.

The following thread had a few links with webfm alternatives. I don't think any of them gave the same functionality but they are close.

http://drupal.org/node/1088656

Hello,

I'm new in Drupal development but the module WebFm is very interesting.
I have made a lot of change tu use it on drupal 7 but it remains some problems.
Is there someone who can help me?

Thanks,

Id be willing to take a look at it and see how far i can get, whatever way is easiest to share the code works for me.

webfm for drupal7 ?

This module is very useful and it deserves to continue to live, but, maybe, the future of it, if any, is to find a sponsor.
What's about some kickstarter-like?

WebFM appears dead (tho still working on my site).

WebFM does something I can't find in any other file manager, Drupal or Wordpress. The files can reside outside the website's file structure, yet you can still create a link to them (https://website.org/webfm/filename.txt) and have the access controlled via the security model. Everything else I can find is either:
the files reside under /public_html , so anyone with the URL can read the file
or
the files reside above /public_html, but while you can manage the files there with security, you can't create a URL to them.

Does anyone know of another file manager that functions like the above, for either Drupal or Wordpress?

I think its time to shut this idea down. Drupal 9 is around the corner. WebFm was fun and usefull while it lasted.

A new module would be more useful - instead of trying to re-write webfm. Media is now part of core #2825215: Media initiative: Roadmap we have private files and file fields. All things that - on the 5 January 2007 (Drupal 4.7) - when rob started this initiative where still a pipe dream.

So thank you for your support, the good ideas and the fish.

Stay healthy

+1

In today's security environment, this would require a lot of effort to update to a safely usable module. Applications should manage their data (e.g. user uploaded files) but not their code.

Also, I think that the IMCE group of modules has pretty much caught up to what WebFM supplied.

That said, I did once think briefly about trying to make it a React based module. But then the real world set in and it got no farther than some research. :)