Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When uploading files using the file_entity's own file overview, the directory is fixed at ''. It should be possible to set a custom directory for files uploaded, if not already specified by some other modules.
Comment | File | Size | Author |
---|---|---|---|
#32 | use-file_entity_default_file_directory-1997208-33.patch | 2.61 KB | joseph.olstad |
| |||
#31 | use-file_entity_default_file_directory-1997208-32.patch | 2.67 KB | joseph.olstad |
|
Comments
Comment #1
esbenvb CreditAttribution: esbenvb commentedThis patch provides a setting form in admin/config/media/file-system and reads the variable when building the destination path.
Please remember to pass the proper git attribution when porting the patch, as mentioned on http://drupal.org/user/989064
Comment #2
esbenvb CreditAttribution: esbenvb commentedHere is a patch for the current dev release.
Comment #3
aaron CreditAttribution: aaron commentedThis works as advertised.
Comment #4
Dave ReidI'm not 100% on this being useful compared to if we had a little more work put into upload destination options. I believe we either need to allow people to choose where their file is uploaded on the file/add page itself, or this needs to be exposed as an option in the file types.
Comment #5
Dave ReidI filed a new issue for the direction I would like to go in: #2000934: Allow selection of which folder a file is to on the file/add form.
Comment #6
esbenvb CreditAttribution: esbenvb commentedDave, there might be situations where you don't want users to choose the paths themselves, but you want the path of all uploaded files to comply with the overall file system structure. I.e. in our example we use tokens in the path for putting files into folders based on upload dates.
This is another relevant usecase where it makes very little sense to let the user specify a file path himself: http://drupal.org/node/1997272
Edit: An option for the user when uploading the file would be fine, but even then, it would be good to have some overruling control if you don't want the files spread all over /sites/default/files... Consider that feature as an addition to my patch, not an alternative.
Comment #7
Dave ReidI don't see why the use case in #6 isn't covered by https://drupal.org/project/fe_paths already.
Comment #8
gmclelland CreditAttribution: gmclelland commentedFYI.... In the meantime I was looking for something simple so I tried the patch in #2 and it no longer applies to the latest 2.x-dev
Comment #9
gmclelland CreditAttribution: gmclelland commentedHere is a reroll of #2 in case @Dave Reid changes his mind for something simple. ;-)
I'm not sure if this is missing the token popup dialog? That goes with "this field supports tokens."
Comment #10
gmclelland CreditAttribution: gmclelland commentedJust checked and the patch in #2 and #9 doesn't include the token dialog.
Comment #11
gmclelland CreditAttribution: gmclelland commentedHere is an untested reroll of #2 that should add the token browser.
Comment #12
gmclelland CreditAttribution: gmclelland commentedPatch in #11 didn't work. This patch includes a conditional check for the token module.
Comment #13
gmclelland CreditAttribution: gmclelland commentedWell I'm not sure why, but I can't get the link to show that say's something like "Browse the available tokens" to show up. I did test the patch on simplytest.me and it allowed me to upload a file to specified default directory.
I was trying to get the token dialog code from http://drupalcode.org/project/media.git/commitdiff/b350d22?hp=3f4c786536...
Comment #14
gmclelland CreditAttribution: gmclelland commentedReroll of #12 to work with the latest dev.
Comment #15
gmclelland CreditAttribution: gmclelland commentedHere is a new simple patch that makes any files uploaded at file/add use the file entity default directory. Right now all files uploaded to file/add go into the root of the files directory.
Comment #16
tsmulugeta CreditAttribution: tsmulugeta commentedWhen I tried running your patch it didn't work. I
(1) Went into the file entity folder,
(2) Uploaded your patch there,
(3) And then ran this command in the command line: $ git apply -v use-file_entity_default_file_directory-1997208.patch
I do have both Git and Drush installed on my server.
I got this message:
Please advise. Thanks!
Comment #17
markgifford CreditAttribution: markgifford commentedtsmulugeta: I assume you mean the patch in #15. There are a few patches in this issue. The patch is 10 months old, and the underlying code it patches has changed in the meantime, so it's now out of date. You'd need to reroll the patch against the current -dev branch, and then it should apply. For this specific patch, though, you might be better off just manually changing the code yourself because it only changes one line.
Again assuming you're using latest 2.0-beta1, the line you want is 494 of file_entity.pages.inc. It needs to be changed from
'file_directory' => '',
to
'file_directory' => variable_get('file_entity_default_file_directory', ''),
Comment #18
gmclelland CreditAttribution: gmclelland commentedHere is a patch that should work against the 2.x-dev.
Comment #19
colanUpdating title to reflect the fact that this doesn't actually allow users to choose a directory per file uploaded. That's #2000934: Allow selection of which folder a file is to on the file/add form.
Also, marked #2109673: Specifying upload path for /file/add as a duplicate.
Comment #20
colanThe last patch is attempting to grab data from a variable that was never set so the result will always be the root of the files directory. It looks like the code for setting the variable got lost after #14. It would need to be brought back.
In other news, I've got a preliminary patch for #2000934: Allow selection of which folder a file is to on the file/add form. Please review.
Comment #21
SocialNicheGuru CreditAttribution: SocialNicheGuru commentedif using http://drupal.org/project/fe_paths will the file_entity path be the appropriate fe_path based on file type?
Comment #22
sheldonkreger CreditAttribution: sheldonkreger commented@socialNicheGuru: Yes, FE Paths settings are respected on all upload areas, including the upload at /file/add, file attachment fields, wysiwyg buttons, etc.
Without FE Paths, I experience this bug only at file/add. All my file field config is respected, but there is no config for /file/add
Comment #23
WayneDyck CreditAttribution: WayneDyck commentedI just updated to version 7.x-2.1 and will still need to apply this patch again because files uploaded using /file/add continue to be saved at the root of the "files" directory. I am a little surprised this issue hasn't received more traction over the years since it was first reported.
Comment #24
joseph.olstad@WayneDyck , instead use the patch from #2000934: Allow selection of which folder a file is to on the file/add form
Comment #25
WayneDyck CreditAttribution: WayneDyck commented@joseph.olstad thanks, however, I don't want to provide users with a choice of where their uploaded file goes. I simply use something like,
[current-date:custom:Y]/[current-date:custom:m]/[current-date:custom:d]
set with tokens in the "File entity: Default file directory" and the file is saved in a date based directory.
If I give the users the ability to create and name directories it becomes a nightmare.
Comment #26
joseph.olstadyes agreed, keep using tokens if that's working for you.
if you have a patch for us, please share it.
or if you have the configuration steps for this please share it with us and we can add it to the documentation.
Thanks
Comment #27
joseph.olstadComment #28
joseph.olstadwhich patch are you using?
have you tested it with the latest release file_entity 7.x-2.4 ?
Comment #29
joseph.olstadnew patch for 7.x-2.x
Comment #30
joseph.olstadnew patch again, this one adds text description suggesting token config
[current-date:custom:Y]/[current-date:custom:m]/[current-date:custom:d]
Comment #31
joseph.olstadyet another one
Comment #32
joseph.olstadsmall change
Comment #33
WayneDyck CreditAttribution: WayneDyck commentedI'm using the changes defined in #14. I manually add them to each official release which comes out before I push the updated module into production. I am going to apply the modifications against file_entity 7.x-2.4 this afternoon.
Did you still need me to make a patch as it looks like you have one in #32.
Comment #34
joseph.olstadManually apply ? Ever try the patch command?
Patch 33 should do the job, let me know how it works for you.
Comment #35
WayneDyck CreditAttribution: WayneDyck commentedI wasn't patching the original source; just the downloaded release module. If you are not working with the checked out source the patch command will not work, correct?
I will try patch 33 and let you know. Thanks.
Comment #36
WayneDyck CreditAttribution: WayneDyck commentedPatch 33 works fantastic. I think it makes a lot of sense to have the configuration for the "Default file directory" as an option under "File settings". Nice.
Also like the, "Suggest using: [current-date:custom:Y]/[current-date:custom:m]/[current-date:custom:d]" as an suggested option. If you are on a site with a lot of daily uploads it will definitely keep the number of files per directory manageable.
Thanks for doing that.
Comment #37
WayneDyck CreditAttribution: WayneDyck commentedWhat needs to happen in order to get patch 33 committed? Do I need update the issue and mark it as "reviewed?"
Comment #38
joseph.olstadusually someone other than the patch writer will put in a review.
Ya, I've looked at it, looks pretty good but wasn't on my radar.
Comment #41
joseph.olstadToo bad that this was overlooked for 7.x-2.5 , however, there's always 7.x-2.6, tags are free.
Comment #42
joseph.olstadComment #43
WayneDyck CreditAttribution: WayneDyck commentedNo worries. In retrospect I should have moved it into "Reviewed..." after I applied it and verified it worked. Will be sure to do that for any future patches.
Thanks.
Comment #44
vchen CreditAttribution: vchen commentedThanks for getting this working! I have 7.x-2.6 installed and I can't get anything with [file:xxx] to work as a token in the Default file directory. [current-date:custom:Y] and other date tokens work just fine. I'd like to organize files by year/filetype.
It just makes the year folder and then a subfolder called "[file:type]" or whatever token I choose. It seems the treat the token as a literal string of text.
Comment #45
joseph.olstad@vchen please feel free to open a new issue for your new request to enhance this functionality, you can open a new issue, link it to this one, mark it as 'needs review' when you've got something to review.
Comment #46
fredcy CreditAttribution: fredcy commentedWe have been using the filefield_paths module for years to assign specific paths to uploaded files. This recent change to field_entity seems to conflict with filefield_paths.
Where we have file fields (attachments) associated with content types we used filefield_paths to set the "File path" setting to be "upload" for each type, causing uploaded attachments to be stored directly within the sites/default/files/upload directory. But after updating file_entity to version 7.x-2.6 (and not changing any config settings) such uploaded files are ending up in the sites/default/files/filefield_paths directory instead. I suspect that is because the "Temporary file location" config setting for filefield_paths (its only setting, in fact) has a value of "public://filefield_paths".
So this causing a problem for us because we don't want the uploaded files to end up in that "filefield_paths" directory. They should go into the "upload" directory as they have been.
Comment #47
fredcy CreditAttribution: fredcy commentedAbout the above -- nevermind. Uploaded files are actually ending up in our intended "upload" directory. I think in my earlier tests I must have uploaded the file attachment but not saved the content item itself. Doing that seems to leave the uploaded file in that temporary directory. Once I save the item the file attachment gets moved to the "upload" directory as we want. Sorry for the confusion.
Comment #48
joseph.olstadthanks for reviewing and reporting, good to know it's working out.