Provide administrative UI for adding/removing file types

http://drupal.org/node/1037234 is related to this

davereid suggested an autocomplete which might work in place of the 300+ checkboxes. the autocomplete could be formed as 'Mimetype (ext)' to make it easier.

#1292334: map existing file types properly during install

#1292382: Make it possible to create any number of custom File Types

subscribe

File entity has switched to a 7.x-2.x branch and the 7.x-1.x branch is no longer used. Please make sure to update your Git clones.

I'm the author of apachesolr_media and file viewer.
The file_entity and media issues make developers confused now.
For my module I need setting per mime type. I think file_entity should provide settings for each mime type.
For display different files, per mime type settings are also necessary.

Maybe the bundles are the only thing to leave to media module now.

For example, a parser for each mime type to extract the text to make index.
catdoc for .doc file, xls2csv for .xls file, catppt for ppt file.
docx, pptx, xlsx, epub files are all zip files, but need separated settings to get the content.
I think for video or audio bundle, you can't really use one lib to get all the meta data out either.

Will settings for each type be storaged in file entity way or in media way (save in a table) in the future?

I'm working on OG based group file management. I realised that BUNDLEs should be configurable and shouldn't be linked to MIME system.

Downgrading this to major for now.

/**
* Determines the file type of a passed in file object.
*
* The file type is determined by extracting the 'first' part of the file's
* MIME type. For example, a PNG image with a MIME type of 'image/png' will
* have a file type of 'image'.
*
* @link http://www.iana.org/assignments/media-types/index.html IANA list of official MIME media types @endlink
*/
function file_get_type($file)

I think this way is not a good idea for bundles. It's better to allow user define bundles like node.

I'm setting this to postponed for now since the patch in #1292382: Make it possible to create any number of custom File Types will completely change the way file types works.

Its in:)

Yes please, now when #1292382: Make it possible to create any number of custom File Types is in, its time to get back to this so we can create new file types too. Currently its only possible to edit the default ones and that kinda limits the usefulness of that patch.

Simple patch, provides a way to add file types:)

This gets rid of a fatal error when editing a file type, pointed by Rob_C on IRC:)

Applies clean.

Status message
The file type robstest has been updated.

Nice! (Save on edit now also works indeed.)

Tested mime types, validation seems to work.

1 thing i can't seem to find, a delete button. Arg how can i get rid of this thing now! :)

Do we need to lock default file types?
Thats why i did not start adding a delete button..I think we should allow deletion of default types..
Putting to needs work for deletion

You can delete default content types & menus etc. so I don't see why not.

I think there should be a way to lock Media types, but only ones explicitly created by other modules or exported into code with something like features or similar. I agree that "default" types should be removable.

Though I think that functionality could be handled in a separate issue so it doesn't prevent this one from moving forward.

Thoughts?

#26: There was a similar discussion in #1043198: Convert view modes to ConfigEntity for view modes in D8 core. Probably worth a look.

Tested #22. Works great.

I agree that we need to allow delete operation. I also agree that we need to allow modules to create file types that are undeletable or somehow uneditable. We could take inspiration from node.module about this. Every node type has several arguments in node_type db:
- custom: indicated whether type was introduced by a module or created via UI. Types that are introduced by a module are not deletable.
- locked: indicates whether machine name changes are allowed via UI or not.
- disabled: indicated whether type is disabled or not (disabled types stay in DB, but are not displayed in UI).

Could we implement some of this features for file types also? It would definitely solve our problem of (dis)allowing delete operation.

stole some code from node content types deletion and voila:P
we might need a custom flag, so deletion can be prevented if provided by a module, but aye this should be another issue

Ah, just saw #28..yes we should provide this functionality..but also agree with #26..lets leave this for other issue, since this functionality is more urgent need i think.btw we need tests here

+++ b/file_entity.admin.incundefined
@@ -481,3 +521,37 @@ function file_entity_file_type_form_submit($form, &$form_state) {
+  $t_args = array('%name' => $form_state['values']['name']);

I get a Notice: Undefined index: name here.

There are no "delete" links on admin/structure/file-types. I think we should add them to achieve standard experience.

good catch! fixed PHP notice and added delete link in file-types overview admin page

+++ b/file_entity.admin.incundefined
@@ -385,6 +396,18 @@ function file_entity_file_type_form($form, &$form_state, $type) {
+  $form['type'] = array(
+    '#type' => 'machine_name',
+    '#default_value' => $type->type,
+    '#maxlength' => 255,
+    '#disabled' => (bool) $type->type,
+    '#machine_name' => array(
+      'exists' => 'file_type_load',
+    ),
+    '#description' => t('A unique machine-readable name for this file type. It must only contain lowercase letters, numbers, and underscores.'),
+  );

'#type' => 'machine_name' would be much sexier here :)

http://api.drupal.org/api/drupal/developer%21topics%21forms_api_referenc...

I noticed another thing. Default types are exported to code. When you delete them they stay there (they are only reverted to state reflected in code). I propose that we:
- Remove "Delete" button if we have unmodified type defined in code
- Change "Delete" button with "Revert" if we have type, that was exported, but later modified and saved to DB

I know that we planned to divide this in two issues, but now when I understand that we actually have types that are 100% saved in code, I do not see this feature without proper handling of those.

'#type' => 'machine_name' would be much sexier here :)

its already machine_name, although i have no clue, why js wont work

I noticed another thing. Default types are exported to code. When you delete them they stay there (they are only reverted to state reflected in code). I propose that we:
- Remove "Delete" button if we have unmodified type defined in code
- Change "Delete" button with "Revert" if we have type, that was exported, but later modified and saved to DB

Like image styles UI does...Well tbh, i would prefer removing file_entity's hook_file_default_types implementation and moving creation in the install hook..
That would allow two things:

- Make default types exportable through features
- No need implementing all this complex code:)

its already machine_name, although i have no clue, why js wont work

You most likely need to implement "#machine_name => source".

- Make default types exportable through features
- No need implementing all this complex code:)

I can agree with the first line, but this does not prevent us from implementing support for this. We still need to support hook_file_default_types() for other modules/features, which means that we need to implement that complex code.... :)

ha, yes source parameter defaults to name, while we have label:/ fixed that..
and, second point, yeap seems you are right..i will steal some code from image styles now:)

"Revert" functionality needs to be added.

This issue is related to the work here - #1901566: Resolve the 'allowed file types' field widget setting with the file_entity forms

At today's meeting we agreed that we can commit this for alpha1 and add revert functionality in alpha2.

#36: file_entity-ui_add_type-1260050-36.patch queued for re-testing.

Revert issue: #1934478: Allow user to revert file type to the configuration saved in code

Yay. I have been using this for a little while with no issues.

still needs tests

In order to delete/disable file types defined in code I think we have to add a disabled status- this suggests that we tackle the revert issue along side of this.

This is a rough patch which includes disable/enable/revert/delete functionality. As usual I'm not sure if this is the best approach but I think it gets us further along.

This looks great, however when I add a new file type and disable it, I do not get a link to enable it again, even though the status reads "disabled". Additionally, for UI, I think that we should push any disabled types below the enabled types, and grey them out.

This is a reroll with a fix for the enable link. I don't see an obvious css class for displaying a row as disabled- any suggestions?

Another reroll with the class that Aaron suggested in IRC

#50: 1260050.50.diff queued for re-testing.

Added code that moves disabled types to the bottom of the list.

This looks much better. However, when you add a new type, and then disable it, delete it, and recreate it, it will reappear disabled.

CToolS store disabled/enabled info in a variable, which is not updated on delete. This patch fixes it. I am not sure if there is any better way to do this via ctools_export API.

I also changed 'revert' link to 'delete' when file type does not have version in code. It seems much more understandable what link actually does.

I tested out the patch in #55.

I was able to successfully create a new file type via the UI and use it via a file field and everything worked as expected. I also allowed this file type to be added via the WYSIWYG and was able to add one there as well.

I then disabled the file type.

I also changed 'revert' link to 'delete' when file type does not have version in code. It seems much more understandable what link actually does.

When I tried to delete the file type, the delete link went to admin/structure/file-types/manage/X/revert which was confusing since I thought I was deleting. Also, on this confirmation form the title is "Are you sure you want to revert the file type X?" and the button is "Revert", not Delete. I clicked Revert anyways and was directed back to the file types list and my custom file type was deleted, but the status message is "The file type X has been reverted."

Could we have the delete link go to a delete confirmation instead of the revert? I anticipate how it currently works may still be confusing for site builders.

This is going to be a great addition once it's committed.

This fixes that issue. It should be good to go now.

Looks good to me.

thanks for the effort all, but i dont see any tests yet

Here we go. Let's see what test bot has to say about that... :)

Awesomeness!! thanks a lot for writing tests slashrsm:) i am gonna check and commit this when i find some time:)
thanks all!!

I got it first. Thanks so much for your hard work, everyone!

http://drupalcode.org/project/file_entity.git/commit/70081d0

Yay!

Yay! One step closer to alpha. Thank you all!

Awesome. Bucketload of karmapoints to everyone involved!

#1945090: File type UI fatals on php 5.2