Project:File (Field) Paths
Version:7.x-1.x-dev
Component:Code
Category:bug report
Priority:major
Assigned:Toshiro
Status:closed (fixed)

Issue Summary

Hi guys,

I'm trying to use the FileField Paths to organize all of my files but I have a problem. The module doesn't work well with the file path. Let me explain:

I create a new content type with an image field.
On this image field I set a path like test/images at File Path option
I check the option to use Private files upload destination

So, when I use this content type and upload an image, the system put that image on the root of Private files path (something like sites/default/files/private) and ignore the rest of the path, means sites/default/files/private/teste/images/

I don't know if this is a bug on this module or I'm making some mistake with the configurations because the image is stored but in a wrong place.

My system is a D7 up to date with the 7.x-1.x-dev FileField Paths module.

Thanks for any clue about it.

Comments

#1

Testing without the FileField Paths enabled the file and image fields working well in private way. So, I think that's a bug on this module.

Someone can confirm it?

Thank you!

#2

Status:active» postponed (maintainer needs more info)

Hi pmichelazzo,

I tested using you're usecase and it worked perfectly for me. When you say that the file is put in the root, are you referring to before or after the node is saved?

If before, this is covered by the FAQ, the file isn't moved until you save the entity is saved as the tokens being used may not be known until the entity is saved ([node:title] for example).

If after, I was not able to replicate those results, any more information you could provide on the issue would be extremely helpful, such as reproduction steps on a fresh D7 install, information regarding your server or even access to a sandbox server so that I can reproduce the issue and debug it.

Cheers,
Deciphered.

#3

I'm having the same issue, however, I'm not saving in private files. I cannot get it to save in the directory I specify in the File Path Settings. It keeps saving to the default/files location.

Basically after I completed the update, all of the File Path settings disappeared and when I went to read add them, even though they are specified, the files are not saving in the proper File Path location.

#4

I'm also having the same issue.

I keep getting this error: Warning: rmdir(/home/www/sites/default/files/public:) [function.rmdir]: No such file or directory in drupal_rmdir() (line 2332 of /home/www/includes/file.inc).

Any ideas??

#5

Status:postponed (maintainer needs more info)» needs work

Does anyone have any answers to fix this? I have 1000s of files I need to upload but I'm kinda stuck until this gets resolved.

#6

Status:needs work» postponed (maintainer needs more info)

krazykellie,

Please read comment number 2, I need more information so that I can reproduce and therefore solve the issue. If you want this issue fixed, help me reproduce it, either by providing pure information, or by giving me some form of access to a site where I can see and debug the issue.

Until then, this is postponed as I need more information.

Cheers,
Deciphered.

#7

Hi Deciphered,

I solve the problem in my localhost installation. Now it's working well. But I found a problem when I put the installation on the datacenter. Let me explain:

My public files are stored at sites/default/files/public
My private files are stored at sites/default/files/private
My TMP directory is /home/cmsplan1/public_html/intranet/tmp because I can't write at /tmp directory.

I create a content type with one image field. When I upload some image using this content type, Drupal put the file at sites/default/files/private BEFORE to press Save button. This is strange for me because I think that the right place is the tmp directory, but...

When I save the node, I can see the image but I receive an error message on the recent log messages report with "The specified file private://xxx.jpg could not be copied to private://content/images/xxx.jpg." and when I look the private directory the image still there and not was moved/copied to the right place that I configure like content/images on the content type field.

I check every permission on these directories, I changed it to 777 also and I check the .htaccess file inside the sites/default/files/private directory. For me, everything seems ok but I don't understand what's happen.

This is very strange because on the localhost everything it's fine but not on the datacenter and I don't have a strong error message on the watchdog log, just what I say here. Also, on the error log of my Apache, I don't have any clue about it.

Did you have any idea about what's happen?

Thank you

#8

Deciphered,

I'd be happy to help you solve this issue. I do not have a "sandbox" site or anything, I only have the working site. I do know that prior to this issue, I had no problems with files on my server or with permissions. I'm not sure where the break down happened. I'm happy to provide screenshots of whatever you need but since we've just met, I cannot provide admin access to our site for safety reasons. If you let me know what type of information you need, I can provide it.

#9

I'm seeing the same warning as #4 when saving an existing node with an image newly uploaded to an image field. The problem seems to occur in the function filefield_paths_filefield_paths_cleanup() in filefield_paths.inc:

<?php
if (drupal_rmdir("{$scheme}://" . implode('/', $paths)) == TRUE) {
?>

$paths also includes the scheme (without the // for some reason), so for "public" this is tacking "public:" at the end.

Warning: rmdir(/path/to/drupal/sites/all/files/ewre/public:) [function.rmdir]: No such file or directory in drupal_rmdir() (line 2333 of /path/to/drupal/includes/file.inc).

There is no directory "public:", and I'm not sure trying to delete the root files directory (ewre) is a good idea.

filefield_paths_filefield_paths_cleanup() seems to iterate through the path trying to remove each directory. I suspect the warning above may be due to the php warning settings and can be ignored, although it'd be nice to check for the directory first.

The link to the original topic is tenuous at best as the files seem to be saved in the correct locations.

#10

Status:postponed (maintainer needs more info)» active

Updated status.

#11

In filefield_paths.inc, should this line:

<?php
$paths
= explode('/', str_replace("{$scheme}://", '', dirname($file['filepath']['old'])));
?>

be:

<?php
$paths
= explode('/', dirname(str_replace("{$scheme}://", '', $file['filepath']['old'])));
?>

drupal_dirname() would also work I imagine. This still brings up an error when trying to delete the entire files directory.

#12

I have the same issue on my present work. A folder is created, but the files are stored outside the folder.

On a older installation everything works fine.

#13

Status:active» postponed (maintainer needs more info)

I still haven't been provided with reproducible steps or access to a sandbox site to see this issue in person... so I have to mark this issue as postponed yet again.

#14

Deciphered,

As I stated previously I do not have a sandbox but I'm happy to provide anything additional you need. All you need to do is tell me what you need.

#15

krazykellie,

As I said, what I need is reproducible steps to see the issue or access to a sandbox. Setting up a fresh sandbox site and reproducing the issue is the best thing you can offer me and is extremely easy, if you don't have a webserver you could use one of the many easy webservers (MAMP, XMAPP, etc) or one of the many Drupal stacks (Acuqia Drupal stack, etc), and then all you need to do is get the site setup and reproduce the issue and then provide me either with access or steps to do so myself.

Cheers,
Deciphered.

#16

Priority:normal» major
Assigned to:Anonymous» Toshiro

Same problem.

Steps:

  1. Install Drupal 7.12;
  2. Install Token 7.x-1.0-rc1 (2012-Jan-31), File(Field) Paths 7.x-1.0-beta3 (2012-Feb-08), PathAuto 7.x-1.0 (2011-Oct-31) modules and enable them;
  3. Create a new content type,add an image field in it and save it;
  4. In an image field settings set FILE (FIELD) PATH SETTINGS like [node:url:path]. All other settings by default;
  5. Go to Configuration->URL aliases->Patterns and set a pattern for your content type like category/[node:content-type:machine-name]/[node:nid] and save;
  6. Then go to Content->Add content->your content type and create a new content WITHOUT uploading an image;
  7. After content has been created, edit it and try to upload an image - but instead of uploading your image to the folder you set by token - file will be uploaded to the sites/default/files folder.

Makes me crazy!!! >_<

#17

I found something new about this bug.

First i installed just Token + PathAuto and in step 4 from my previous post in the path input of the Image field of my content type i entered "gallery" and saved it.

So when i uploaded my files on content editing page, Drupal created folder sites/default/files/gallery and stored my files there.

Next I turned on the File (Field) Paths module. And redid steps 4-5 from my previous post.

When i uploaded an image this time - it was uploaded to the sites/default/files/gallery folder again!!!

I guess - for some reason Drupal ignores the field for path that comes from File (Field) Paths module, and still uses value from the original core input of the Image field.

#18

Assigned to:Toshiro» Anonymous

My config: Drupal 7.12 & File (Field) Paths 7.x-1.0-beta3
I was scratching my head with similar issues than those listed before:

  1. Set up of the File (Field) Paths with a subdirectory "field/image/article/[node:nid]" of "sites/default/files" for the image field
  2. When adding an image to an article, the image lands in "sites/default/files", not the subdirectory so it seems there is a bug
  3. But when I saved the article, this was fixed and the image was moved to the right subfolder.

I should mention that it wasn't a new article, so there already was a [node:nid]. Nevertheless, you have to save for File (Field) Paths to do his work.
I hope it will help some people..

#19

Assigned to:Anonymous» Toshiro

MaitreKaio, u're right. I've checked this with a new article - and it does the same.

First file is copied to sites/default/files/ directory - and after u save content - to the directory provided by tokens in the field path settings. I think it works like that to have correct tokens if you haven't saved your content yet.

So first u upload all files - then save, and when node-id and other variables will be generated, files will be moved to the correct location.

Also I found an issue in the module's readme file.

Q. Why aren't my files in the correct folder?
A. When you are creating or updating an entity the full values for the tokens
may not yet be known by Drupal, so the File (Field) Paths module will upload
your files to the Fields old file path temporarily and then once you save the
entity and Drupal is provided with the tokens values the file will be moved
to the appropriate location.

I think this should be placed on the module page - somewhere in the module description, so that people could find this easy.

#20

Status:postponed (maintainer needs more info)» fixed

It saddens me that this is this yet again. It is stated both on the project page and the README (READ ME, please won't someone just READ ME).

Admittedly if I had more time and was paying more attention to this issue I'm sure I would have seen this a long time ago.

File (Field) Paths can only work after the Node/Entity has been saved as otherwise there is no guarantee the tokens that are being used have yet been prepared (Can't know the Node ID if the node hasn't yet been created).

Thanks for sorting this out though, and if you have thoughts on how best to make this dead obvious I'm always open to suggestions.

Cheers,
Deciphered.

#21

Damn trains... double post.

#22

For the record, #9 is fixed in the latest dev. Latest dev also solved #1384014: Warning: parse_url(private:///example.png) [function.parse-url]: Unable to parse URL in _filefield_paths_replace_path(). It may have been fixed in an earlier one but I was using the "recommended" release.

#23

Status:fixed» closed (fixed)

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

nobody click here