I'm feeling a bit like limiting file types by schemes is not something that our majority use case really cares about, and causes major problems with existing files, see #1979804: Files with a missing scheme cannot be edited.
If adding this functionality is possible via a separate contrib module, then I think we should rip this out. Limiting file types just based on mime types is the core functionality I think we should focus on.
Thoughts? Am I completely wrong? Tagging this as an alpha blocker as this is something that should be removed prior to alpha1.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1979832-file-type-remove-streams.patch | 15.35 KB | dave reid |
| #1 | 1979832-file-type-remove-streams.patch | 13.63 KB | dave reid |
Comments
Comment #1
dave reidLet's try this out.
Comment #3
dave reid#1: 1979832-file-type-remove-streams.patch queued for re-testing.
Comment #5
dave reidI think I've got the test failures fixed. I think we are able to assume that both public and private files are enabled all the time on tests, and the current tests made the assumption that files automatically are assigned private all the time and you don't get the scheme selection.
Comment #6
devin carlson commentedThe patch in #5 applied cleanly and removed all references to per filetype scheme restrictions.
After applying the patch I was still able to add new files and view, edit and delete existing files. I also upgraded two existing sites, one running unstable7 and one running the latest -dev, without encountering any problems.
Each site had a number of visible, writeable stream wrappers and a couple of custom media providers. I didn't have any issues there either, so marking RTBC.
Comment #7
dave reidThanks, I had tested this extensively as well, so committed #5 to 7.x-2.x.
http://drupalcode.org/project/file_entity.git/commit/e6f091e
Comment #8
rob c commentedHeh, already beat me to it. I can confirm #6, also upgraded a site that runs the latest dev 2.x, seems to work ok.