Add file.module to provide UI for managing files

@drewish: Thank you for taking over this feature request.

Lovely ... We really could use the #242962: Add tableselect form element here.

Drewish- I'd like to integrate this with the sudo-proposed module here: http://groups.drupal.org/node/13898 I'm currently working on the spec and certainly don't want to duplicate effort, but do want to make it backwards compatible. Perhaps we can separate the file management API from the the GUI?

Gotcha, makes sense to me.

My ++good on this... It is a simple foundation and a new core module that will hopefully grow to provide additional functionality over time... A generic reading of the code looks good to me... I'll do some actual testing this evening.

.darrel.

This looks interesting! Subscribe.

I probably will not be able to review this thoroughly until next week.

See: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476

subscribe

I am worried about deleting files. Particularly in instances where the Drupal site is run on more than one server.

When we delete from the database we pretty much know that the data is gone as all of the servers would share a database.

When we delete files here they, unless I'm missing something, would be deleted from only one server. We need to provide a way, perhaps a hook, perhaps something in the database that tracks what needs to be done.

Other systems have pending operations table that contain items to be processed. Perhaps in Drupal this could be a cron function for multi homed installs. There are many ways to handle this, one being that each server registers itself, perhaps with uname or something so that it can track what actions have occurred elsewhere that it needs to match.

Any thoughts?

I agree they shouldn't share a files directory. That's why the other servers need to know to delete a file.

i think stewsnooze is not talking about multi-site but rather a 'multiple web server' setup for a single drupal site. in this case, the files dir is almost always shared using NFS. So deletes are a non issue.

@moshe do large sites really use nfs shares for the files directory? how does that perform?

Spoke to Moshe on IM about this so I remove my concern...

Could you summarize here for the benefit of others who might have the same concern?

Moshe was saying that most sites that use more than one physical server would use an nfs share for the files directory shared across the cluster. I can see how this would work. I don't think it would be fast but it would work.

I think a glamorous solution would be to make hooks available on disk operations as I believe the nfs thing is a single point of failure for your whole site.

These hooks could be used to contact the other servers in the cluster to get them to perform the actions.

I don't think those ideas need to cloud this issue.

Wordpress has a Media Library that went through some heavy usability testing lately. Have we looked at that? The usability reports should be available online.

This feature provides and administrative overview to files stored on the system. IT allows administrators to forcibly remove files, and get an overview of current file usage. It is meant to be an interface with the role as admin/content/node.

Initial pass:
- What?! No file.test?! FOR SHAME. ;) We should have some basic tests to ensure the interface is working.
- Most files are missing // $Id$ lines and /** @file */ blocks.
- file.module has one but it says * TODO: fill this out. There's also // TODO: provide some help. Basically, lots of TODOs here. :P It'd be nice to get those less TODO-y.
- I don't feel the permission description t('Manage user-uploaded files.') is descriptive enough to tell me what this is going to do. Maybe mention something about a files administrative interface?
- (minor) 'type' => MENU_CALLBACK needs a comma at the end.
- function file_admin_overview_form($form_state) { is missing PHPdoc.
- (critical) This admin panel does not respect private files access. To test, I enabled private file handling, File and Upload modules, created an unpublished article with a file attached, and a "file admin" role with "administer files" and "access administration pages" permissions. When I click on the file, I get access denied. When I go to admin/content/file, it is listed. This should not happen.

In IRC, you said that someone with 'administer files' perms should have access to see these since it's an admin panel, but a) if that is so, I should be able to see the file itself, and b) I'm not hot on coupling "access to admin panel" permissions with "bypass access restrictions" permissions. We split those in node module for good reason.

From file_admin_overview()...

 $edit = $_POST;

That doesn't seem safe. Can't you get that by passing in $form_state?

  if (empty($files)) {
    drupal_set_message(t('There do not appear to be any files to delete, or your selected file was deleted by another administrator.'));
    drupal_goto('admin/content/file');
  }

Should be $form_state['redirect'], not drupal_goto(), no?

UI review:
- This UI would benefit from some filters. This list is going to get LONG on most sites, and it would be nice to be able to filter it by name, size, what module it's associated with, or type. It would also be more consistent with node, comment, user, etc. admin pages.
- Why a separate page for disk usage? I can already sort the main table by size, and I can then delete really huge files while I'm at it.
- It would be cool to display images inline at the admin/content/file/X page.
- It would also be cool to display a little graphic next to them in the list to show what type of file they are at a glance.
- What does "Status: Permanent" mean? That sounds scary. Like I can't delete it.

I kind of stopped there, because I can tell this is not really ready for core committer review yet. In general, I'm in favour of the idea of this panel, though. But we need a bit more work to make it core-worthy.

May i know what are the procedures are there for creating the new project.

Now i successfully installed the drupal with the help of install manual.

But i dont know how to create the project on drupal.

where i would to create . what are the methods are there for creating projects.

I want immediately the response

so make it fast and you can inform on clear manner with the help of picture to create the project.

thank you

Murugan.G
India
Tamilnadu
Chennai

This is a bug issue, not a place for support. Please use the forums for general support.

Hmmm.... Most interesting...

Ah, here's that issue. I was already wondering where drewish got the inspiration for #353458: hook_file_references() was not designed for a highly flexible field storage. Subscribe.

subscribe

subscribing. I've been waiting for this. I think it really makes sense. If files are first class elements, they should get their own "interface" just as other elements. IMHO, there should even be a /file/$fid screen, just like with nodes.

Subscribe.

Where is this at at the moment? drewish are you still working on it? Where can we jump in and help out?

Not sure what the chance is of including Views Bulk Operations in core, but it would offer some nice extensibility. I've been using VBO for file management in d6, although right now only a developer can do this as you have to write code for whatever actions you want to be able to perform, as well as a file object loader function.

Moving to D8.

Subscribing. I guess this feature could also include an option to delete module folders on the server? Or should I make a separate issue for that?
Currently after having uninstalled a module, there is no web UI option to also delete the files of that module. Such an option would also be useful in the case where you need to replace one module version with another (normally the dev version).

@LarsKramer: no, that would be another option, outside the realm of the file system; the default stream wrappers can't touch files in the modules directories (or anywhere outside of where public:// or private:// is set). maybe you should create a feature request for the update component.

@aaron: Thanks for the clarification.

Added #1236364: Delete module after uninstall

BTW: Shouldn't "D7FileAPIWishlist" be changed to something else if this is now for D8?

good idea... :P

Closing as outdated. Please re-open if this is still relevant.