I am using File (Field) Paths 7.x-1.0-beta3 and have my Image field on my Basic Page content type configured to upload to the images/page directory in my files directory.

However, whenever I upload an image, it just goes into the root of the Files directory. I did have File Field Sources enabled, but have since disabled it, cleared cache, and restarted the server, and this problem is still happening. :(

EDIT: As an additional note for completeness, I also previously had the Media plugin enabled, but have also since disabled it since I thought maybe it was causing File (Field) Paths not to work. But, as noted above, even with Media and File Field Sources disabled, the issue still occurs.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

TJM’s picture

I'm having the same problem. The images are set to upload to images/galleries. However, they upload to default/files folder. Has someone found a solution to this? I'm using Drupal 7 with filefield_paths module 7.x-1.0-beta3. I tried the dev version with the same results.

krabbe’s picture

Same here. Using filefield_paths module 7.x-1.0-beta3, media 7.x-2.0-unstable7.

Deciphered’s picture

Status: Active » Postponed (maintainer needs more info)

Can I confirm that you are actually saying that it isn't working after you've save the node?

Just to be clear, File (Field) Paths doesn't move the file until the node has been saved as the Node tokens can't be known until the Node has been created.

dgtlmoon’s picture

Version: 7.x-1.0-beta3 » 7.x-1.x-dev
Status: Postponed (maintainer needs more info) » Active

I can confirm this one, I have a path set but the file is still going into the old path as defined by the field settings *before* I enabled this module

dgtlmoon’s picture

@Deciphered Might be some way to reword this on the front page of your project some how, tho it is clearly written at the bottom

'When you are creating or updating a node the full values for the Node tokens may not yet be known by Drupal, so the File (Field) Paths module will upload your files to a temporary path based on your filepath pattern ('files/[nid]') and then once you save the node and Drupal is provided with the Node tokens values the file will be moved to the appropriate location.'

I guess the ambiguity here is 'may', because the token for me atleast always knows what userID I am (my path is something like [current-user:uid])

so really one needs to

- disable filefield_paths , set the "file directory" to tmp/ or something
- enable filefield_paths, set your preferred location
- save the node and the file should be serving from the right location

Deciphered’s picture

@gtlmoon,

But you are saying that it does get moved to the correct place after you save the node, yes?

Yes the documentation does need updating as the documentation refers to the old way the module worked, but at the moment my concern is that this issues says that the file doesn't get moved at all, if that is no longer the case, that it does get moved correctly and it's purely a confusion over when the file gets moved I'm happy to change this issue to a documentation issue.

dgtlmoon’s picture

yes that's correct, only AFTER saving it gets moved to the right location, the location before saving is what ever was originally set in the directory/filepath settings before I enabled FFP

Yup, so I think just tidy the documentation is all that's required here

Deciphered’s picture

Component: Code » Documentation
Category: bug » task
Status: Active » Postponed

Marking this as a Documentation task, it will get resolved as soon as I can possibly do so, but at the moment I'm concentrating on getting all open bug reports for D7 dealt with with the intent of getting a stable release out ASAP.

I would be more than open to anyone working on potential documentation alternatives to clarify this issue.

dgtlmoon’s picture

I think just move the comment about it moving the file to real the location AFTER the entity is saved to the top of your project page somewhere

dgtlmoon’s picture

Issue summary: View changes

Added additional info

Morenoid’s picture

Issue summary: View changes

Hi all, the issue I faced was: even if FFP was configured to a token path, when uploading a file, the path after save was the default sites/default/files.
The path in file path settings was [node:author]/[node:title] in admin/structure/types/manage/[element-type]/fields/[file-field]

The fix i discovered almost by random: put a not-token folder name as first folder of you path (eg. 'content') as follows: folder-name/[node:author]/[node:title] or content/[node:author]/[node:title]

No path-auto charachter replacement is actually active in my settings.

Hope to be helpful (and not to be off-topic LOL).

luthien’s picture

I specified a simple path for a file field, to send it to folder1/folder2 and still it was uploaded to default/files root. What is the solution to fix it? if I can not specify the path, then the module does not makes sense. Thanks.

Update: I uploaded dev version of the module. Using tokens as part of the path worked out well after saving the node. If I specify any other regular directory, without tokens, it does not works.

GiorgosK’s picture

in my case it was media module dev from "2014-07-29" and/or media_browser_plus dev from "2014-07-16" which I was not using anymore and I disabled after that both the core "File directory" setting and the FFP setting worked

perhaps people seeing this weird behaviour should check these two modules for updates

s427’s picture

For what it's worth, I think I have the same problem (also with the media module) (I've explained it in details on drupal.stackexchange but I haven't received any answer for now) and I've been able to solve it simply by enabling the very intimidating "Active updating" option on the field settings (so in admin/structure/types/manage/[content-type]/fields/[field-name]).

So in short, when this option was disabled, the file was not saved in the intended location, even if I added the file after the node had been created (by editing an existing node).

With this option enabled, the file is immediately saved in the right folder.

So for now I'm just going to leave this option enabled.

Hope it helps someone.

Pere Orga’s picture

If you are experiencing issues with Media Browser Plus module, see #2358931: Files are always saved in root when Media Browse Plus module is enabled

Shiraz Dindar’s picture

confirming the same issue as #13 (media module dev), and same workaround -- enabling Active Updating.

dtarc’s picture

Component: Documentation » Code
Assigned: Unassigned » dtarc
Status: Postponed » Needs review
FileSize
2.38 KB

I think I have figured out the issue here.

On node save, FFP will possibly put the file in the FFP if either Active Updating is on, or the file is being uploaded for the first time (and has no path).

The bug here is that with Media Selector for the field widget, and Active Updating OFF, FFP does not recognize that it's a new file. So it leaves it in the files root dir.

The check to see whether the file path should be updated is in filefield_paths.inc

/**
 * Implements hook_filefield_paths_process_file().
 */
function filefield_paths_filefield_paths_process_file($type, $entity, $field, $instance, $langcode, &$items) {
  if (isset($instance['settings']['filefield_paths'])) {
    $settings = $instance['settings']['filefield_paths'];
    foreach ($items as &$file) {
      if (filefield_paths_uri_is_local($file['uri']) && ($file['timestamp'] == REQUEST_TIME || $settings['active_updating'])) {

        // OMMITTED: FileFIeld Paths moves the file to its proper directory here

      }
    }
  }
}

Filefield Paths knows that it needs to move new files into the proper path, but the way that it identifies new files is by the file's timestamp being the same as the page request. This works great with a regular file widget. However, the Media Selector widget doesn't work that way.

The Media Selector widget creates the file by ajax. So you submit the file by ajax, the file is creataed with fid, and time stamp, and then the widget refreshes in the form. Then when the form gets submitted, FFP checks the timestamp of the file, and since it's got an earlier timestamp than the entity form submit, the path moving code will not execute.

So Filefield Paths needs to figure out a new way to identify files. Unfortunately, in hook_entity_update, Filefield Paths gets an $entity object with all its filefields filled in. There's no way to tell what's new and what's not.

Here is a crude patch that allows FFP to be used with Media. It is patched on the latest dev snapshot of FFP, and works with the latest dev snapshots of Media and File Entity.

The patch works by implementing hook_entity_presave() and marking all filefield values that were populated in $entity->original (ie. pre-save). Then hook_entity_update(), those files are not moved to the new path. Only the new files, that weren't present in $entity->original, will be moved into their paths.

I'd think there must be a better way to figure out if a file is new...however I'm not sure what that is. I thought of checking usage for each file coming through, but that seems excessive on every entity_save().

This patch works less well for those NOT using media. When not using media, checking by the file timestamp ensures that a file being shared between two entities doesn't keep getting moved back and forth each time on gets saved. With this patch, a file that's already in the system that's being added to another filefield will have its path regenerated and the file moved. This might not matter to some.

I can adjust the patch if this is something that would be committed.

Shiraz Dindar’s picture

Good work dtarc!

Is there any chance of seeing that committed?

ergophobe’s picture

#16 works for me on a very complex setup - Panopoly, Organic Groups and Media

Great job dtarc

ergophobe’s picture

Category: Task » Bug report

I'm marking this a "bug" ("FFP doesn't work with Media") though it could be considered a feature request ("Make FFP work with Media"), but it's not really a Task

Tasks are for something that just needs to get done, where the parameters are well understood. Whitespace repairs, adding translation function support, fixing spelling errors etc are usually just 'tasks'.

https://www.drupal.org/node/73179

Somehow the tests are still not getting run on the patch.... might have to reupload the patch and change the status?

dtarc’s picture

Here is the patch uploaded again, let's see if tests run.

ergophobe, we are trying to integrate plupload into our stack and I have been following your comments in #951004: Allow selecting of multiple media items for a multi value media field in the same dialog. Is this the same project you have gotten Plupload integration working with? And it works with filefield paths as well?

ergophobe’s picture

dtarc, sorry this took so long. I needed to set up a test situation and run a test to answer your question for reasons I'll explain.

Yes, it's the same project. I couldn't give you a quick answer because I had changed Media Browser Plus (MBP) to also make changes on the file system which means that it, of course, overrides the FFP settings.

So I created a sandbox with FFP and MBP, but with MBP set to leave the file system alone.

Everything worked perfectly
- multi-upload using the patch referenced in your question using the "add files link"
- FFP correctly moved the files to the right folder
- MBP correctly shows the folder, and correctly does not move the file
- deleting the image from the last node it's attached to correctly removes it from the file system
- multi-upload using the "drag files" functionality works as designed
- I then uploaded two images that FFP says to put in the /media/galleries directory, but I selected "Documents" in MBP and they ended up in the /media/galleries folder, again as expected.

I have not tested yet what happens if you ask MBP to make changes on the file system, but I would expect that to cause problems.

In an ideal world, I would implement a hook_form_alter and set it up so that for a given content type, the MBP selector would default in such a way that it would effectively mirror the file structure by default unless the user actively changed it.

Basically, as far as I'm concerned with a few of these patches applied to FPP and Media when coupled with recent patches to Panels and CTools, I'd be very close to a completely unpatched setup.... which would be awesome.

From every test I've done, with this patch FPP is working in perfect harmony with Media, Media Browser Plus, Organic Groups and Panels.

ergophobe’s picture

I would implement a hook_form_alter and set it up so that for a given content type, the MBP selector would default

Turns out this is not as easy as you might think - since you're in the CTools modal, you can't just easily grab the node id or the URL that called the modal.

No big deal. Overall, it works great as is.

dtarc’s picture

That last patch was a dud. It called filefield_paths to move the paths around every entity save, making things run exactly how they would if "Active Updating" were turned on.

This patch will only move new files freshly saved to the node. I removed the timestamp check since it would be totally redundant. If a file is shared between two nodes that each implement a different path then it will likely ping pong back and forth as each one is resaved. Fortunately if a file is shared between two fields, and one of the fields does not configure filefield paths, just the settings from the first field are used and there is no ping pong back and forth as each entity is resaved.

berte’s picture

Tested patch from #23 on 7.x-1.0-beta4 and it seems to work.
Using the OpenOutreach distribution which includes the media module.

berte’s picture

After more testing, it happens that existing files are moved from one folder to another.
Here is an example:
1) Node1 contains image1 (storage: /nodes/node1/image1.jpg)
2) Create Node2 and browse the Library to re-use image1 and save.
Now image1 get moved from /nodes/node1/image1.jpg to /nodes/node2/image1.jpg

In my case, this behaviour is not desirable. I would have expected image1 to stay in its original location and node2 to reference it.

izus’s picture

Hi dtarc,
actually i faced the case with media module.
when using the media browser, the file gets saved, and then you can fill some other fields so that the file timestamp gets older than the REQUEST_TIME when you hit submit.
The second part of #23 was suffisant for me.
Thanks dtarc

izus’s picture

oups wrong patch
it's teh second part but without extra verifications

dtarc’s picture

Here's the patch from #23, with a fix for the use case described in #25.

Deciphered’s picture

Title: File Field Paths not working (not uploading to proper directory) » Support for Media
Category: Bug report » Feature request

Renaming issue to be reflective of what it became. In future though, please open a new issue.

Deciphered’s picture

Status: Needs review » Needs work

Patch no longer applies.

Deciphered’s picture

It's also worth noting that the major issue with Media is that another Entity could reference the same field with another File (Field) Paths configuration, which means the file will get continually moved around, which isn't an ideal situation.

Dave Reid’s picture

Yeah, re-using files in general is not really in line with the approach of File Field Paths.

Deciphered’s picture

So i've opted for a much simpler approach than the attached patch, which is simply to update the logic to this:

Process file if:

  • This is a new entity OR
  • 'Active updating' is set OR
  • file wasn't previously attached to the entity

That way it will work regardless of how the file was attached to the entity, be it Media, a regular file field or another method entirely.

I just need to finish the tests to ensure that the functionality persists.

dtarc’s picture

That's probably for the best. I'd say that the behaviour described in #25 is indeed not desirable, however that is a different issue than Media compatibility.

Deciphered’s picture

Status: Needs work » Fixed

Fix committed.

Please take into account that this is a significant logic change, and while it passes all previous tests and I can't necessarily see any potential issues it may have, it could have adverse effects. If anyone encounters any issues with this change, let me know ASAP.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.